What does "request routing failed with status -1 (undefined)" mean?

[Anon Anon]

The assertion routes to a host which requires NTLM auth. It's a GET operation to retrieve a JPG. I've attached the error log is attached, but here's an excerpt of what I'm trying to decipher -

 

2015-01-23T15:55:55.074+1100 WARNING 472 com.l7tech.server.MessageProcessor: 3016: Request routing failed with status -1 (Undefined)

2015-01-23T15:55:55.074+1100 WARNING 472 com.l7tech.server.message: Message was not processed: Undefined (-1)

2015-01-23T15:55:55.088+1100 SEVERE  472 com.l7tech.server.SoapMessageProcessingServlet: not a post

Attachment(s)

Error.txt.zip   1 KB 1 version

[Stephen Hughes]

The error states that there is a problem due to the fact that a post is being attempted but it not intended. This can occur if the HTTP routing assertion is set to use the HTTP Method of the inbound request which is a post or manually set to post. If it is using the HTTP method of the inbound request, then you will need to ensure that the method is set to GET.

[Anon Anon]

Keep in mind that Stephen's explanation is what is indicated by the other log messages associated with this "Undefined (-1)" event.  Generically a neg-one error appears to indicate that an unhandled exception has occurred in the underlying java code of the assertion in question.  To determine the cause of the error you need to look at the other messages associated with the event and in my experience the solution requires changing the settings of the assertion in question.

[fliaa01]

Hi Sumanjay,

 

Benjamin's explanation of the general nature of "undefined (-1)" is correct  The Gateway assertions handle some errors explicitly (and generates specific error messages for them), but any other error will be surfaced as an "undefined (-1)".  While this error code is not very helpful in diagnosing a specific problem, it will normally be surrounded by other errors that should help with diagnosis, and can help with overall policy troubleshooting.  It will certainly indicate that something is wrong with either the service policy, or the message that is being handled, or both.

 

In your error case, Stephen's analysis looks to be correct.

[Derek Orr]

Hello

 

The routing failure can be looked at with the following variable…

 

${httpRouting.reasonCode}

 

The errors associated with this failure is highlighted:

 

 

Returns one of the following reason codes when the HTTP routing fails:

 

   

•   -1 (Host Not Found): The Server referenced in the URL (for example, nonexistentServer.l7tech.com) cannot be reached. This code can be returned if either the host does not exist or the host is simply down.

 

   

•   -2 (Bad URL): The URL is incorrect. This could be caused by an incorrect character such as "#".

 

   

•   -3 (Connection timeout): An initial message was sent to the URL but no response was received before the connection timeout expired. The connection timeout value is defined in the assertion properties.

 

   

•   -4 (Read timeout): One of packets being received from the URL took longer than the read timeout value to be received. The read timeout value is defined in the assertion properties.

 

   

•   -5 (Undefined): An unknown type of error has occurred.

 

Tip: When the HTTP routing succeeds, this variable returns the  HTTP status, which is often the same as ${response.http.status}<file:///C:\Program%20Files%20%28x86%29\Layer%207%20Technologies\Layer%207%20Policy%20Manager%208.2.00\help\Content\Context_Variables_.htm?SearchType=Stem&Highlight=routing%7Crouting%7Crouting%7Crouting%7Crouting%7Crouting%7Crouting%7Crouting#$%7Bresponse.http.status%7D>.

 

 

So if you wanted to build out error handling towards this, you can do so using the this variable and associate the error to a proper error message back to the client.

 

 

Thanks,

 

Derek Orr

 

CA Technologies |885 West Georgia Street Ste 500 | Vancouver, BC V6C 3G1

Office: 1-778-328-5285 | Mobile: [phone] | [e-mail]

 

<mailto:>[CA]

 

<http://www.ca.com/us/default.aspx>[Twitter]<http://twitter.com/CAInc>[LinkedIn]<http://www.linkedin.com/company/1372?goback=.cps_1244823420724_1>[Facebook]<https://www.facebook.com/CATechnologies>[YouTube]<http://www.youtube.com/user/catechnologies>[Google]<https://plus.google.com/CATechnologies>[Slideshare]<http://www.slideshare.net/cainc>

[Anon Anon]

Thanks everyone. The primary route was configured as a GET and the incoming request was set to be a GET too, so this was a puzzler. It turned out to be a bug in my request generator (CocoaRestClient, for the curious) which has been lodged with the maintainers of the application.