Configuring multiple weighted targets causes service gateway to return 500's

Apr 3, 2014 at 4:56 PM
I had my service gateway working fine when I configured it from the console with only one target in the Application Role.

Now I want to try the AB testing scenario and I tried adding another target. Now I'm getting 500's when I hit my deployment.

I also tried having one Application Role target and then a path segment with multiple targets and had the same issue.

Here are the two json objects that aren't working
  1. {"Segment":"_default","Target":[{"Weight":1,"Redirect":""},{"Weight":1,"Redirect":""}],"Flights":[],"RequireAuthenticationBelow":[],"IsArrBaseTarget":true}
  2. {"Segment":"stuff","Target":[{"Weight":100,"Redirect":""},{"Weight":100,"Redirect":""}],"Flights":[],"RequireAuthenticationBelow":[],"IsArrBaseTarget":true}
I both cases if I delete either of the targets, it works correctly.

I've also noticed that there are no errors or exceptions in the WAD log for the service gateway. It only has messages that the "updated configuration has been applied."

Have I done something wrong?

Apr 3, 2014 at 9:39 PM
Hi Lou,

Your configuration looks good for enabling flighting.

To diagnose the fault, I would suggest pulling all other configuration out (other roles, security, etc.) in an attempt to isolate the underlying cause. If that doesn't identify the issue, then turn on Failed Request Tracing in the web.config, redeploy and pickup the FRT logs for all requests that return a 5xx status from the storage account where WAD will push them to. To enable FRT, insert the following into the Router project's web.config thusly:
                <add path="*">
                        <add provider="ASPNET" areas="Infrastructure,Module,Page,AppServices" verbosity="Verbose" />
                        <add provider="ISAPI Extension" verbosity="Verbose" />
                        <add provider="WWW Server" areas="Authentication,Security,Filter,StaticFile,CGI,Compression,Cache,RequestNotifications,Module,FastCGI,WebSocket" verbosity="Verbose" />
                    <failureDefinitions statusCodes="500-520" />
The FRT log will be very verbose, but should identify the point in the pipeline that is causing the failure. We can work back from there to fix the problem.