Error executing external web request: java.net.SocketTimeoutException: Read timed out

[kurtsanders]

My webCore piston is intermittently receiving the following error message from a WebCore HTTP GET request, “Error executing external web request: java.net.SocketTimeoutException: Read timed out” in the log console. However, the piston is not getting any resultant information in the reserved system variables $httpStatusOK or $httpStatusCode results.

1. Can anyone explain why these WebCore reserved system variables are not being set when a socket timeout is triggered or is there another means to trap this socket timeout?
2. Can one set a longer socket timeout for a WebCore HTTP web request?

[ipaterson]

The timeout error means that the request was cancelled for taking too long to respond. Any response that is received (i.e. doesn’t time out) will have a status code >= 100 so you can use the 0 code to identify that the request timed out.

[kurtsanders]

The timeout error means that the request was cancelled for taking too long to respond. Any response that is received (i.e. doesn’t time out) will have a status code >= 100 so you can use the 0 code to identify that the request timed out.

Ok, I did not realize that ‘0’ meant could be used to indicate a timeout. Why doesn’t WebCore return the error that the log shows?

I’m guessing that one cannot currently define/extend the ‘default timeout’ value for the WebCore http get request since the web server may have received the first GET and be under load, and sending subsequent requests from WebCore is not desirable for duplication issues.

[ipaterson]

Seems that ST does not allow modification of the 10 second timeout. I don’t think there is any precedent for exposing a Java error in a system variable but in this specific case it would be useful to have a guaranteed way to identify a timeout, I think the correct way to do that would be with $httpStatusCode or a different system variable set to a specific known value (like -1) that explicitly means “timeout.”

[kurtsanders]

Seems that ST does not allow modification of the 10 second timeout. I don’t think there is any precedent for exposing a Java error in a system variable but in this specific case it would be useful to have a guaranteed way to identify a timeout, I think the correct way to do that would be with $httpStatusCode or a different system variable set to a specific known value (like -1) that explicitly means “timeout.”

Agreed, depending on the same value (0) of a system status variable like $httpstatusOK (0) before the GET and after (0) does not assure one that there was a timeout condition that was intercepted.

I thought, perhaps, that the socket timeout was coming from webCore where the GET is being constructed and executed. If so, it could be exposed to the client GUI so one can set a value greater than the default of 10 seconds for the these conditions where the webs server cannot respond before 10 seconds.

[ipaterson]

Agreed, depending on the same value (0) of a system status variable like $httpstatusOK (0) before the GET and after (0) does not assure one that there was a timeout condition that was intercepted.

Great point. Since there may be some people currently relying on that zero value I would be in favor of adding a different variable or mechanism to check for whatever specifics we can provide on an error.

[devedsmith]

Im getting this too with my Lifx piston…

[devedsmith]

Bump… any solutions to this yet? We get this error and the piston fails to fire on the first attempt. It always fires on the second attempt.