1 person found this helpful
It's not a particularly weird problem, if the network changes after the request goes out, but the response hasn't come back yet, then this would be an expected error. There is no 'hand off' on the network that would allow the requested server to know the clients address has changed, so the response goes back to the 'old' address. We handled it by created class the wraps around our httpservice calls, and automatically handles these (and other 'routine' errors) errors, and as part of that handling resends the request for timeout, or other probably recoverable errors. It only calls the ResultHandler when a good result comes back.
Yes, the solution seems to be feasible, We started using timers arround the http service to request the server whenever there is a fault on the httpservice. it requests the server at the end of ther timer and it always returns fault with the same error as mentioned above.
Its wierd because, it would connect to the server for about 7 times in the process then would start failing from the 8th time.I've left the client in the timer loop for about a day, and at some point of time( dont know when it happend as the logs got overwritten) the client connected to the server, i'm hoping it has polled the server atleast 100 times before it got connected.
Message was edited by: saisri2k2
1 person found this helpful
I don't know what kind of device you are using, but have you checked to make sure that it isn't a general internet connectivity problem? When it fails, is there another 'generally available' http service or web site (say www.google.com with a 'text' response expected) you could hit to check basic internet connectivity. If as part of the change from wired to wireless and back, if the default route, or name servers change, it could take some time before the change actually registers with the application. I don't see this too often with my laptop, but I do notice some long connectivity delays on my Android phone when it switches from cellular to wifi (or back) network connections. Not every time, but enough to be annoying.
Yes it is annoying, i've tried by switching from the wifi to the wireless today in the morning
[FaultEvent fault=[RPC Fault faultString="Request timed out" faultCode="Client.Error.RequestTimeout" faultDetail="The request timeout for the sent message was reached without receiving a response from the server."] messageId="A9913DF4-F588-9AF1-B80D-68E5B3826199" type="fault" bubbles=false cancelable=true eventPhase=2]
the same error
body = (Object)#1
clientId = (null)
correlationId = "B86562A1-47F8-8745-52FE-68E58C5747C1"
destination = ""
extendedData = (null)
faultCode = "Client.Error.RequestTimeout"
faultDetail = "The request timeout for the sent message was reached without receiving a response from the server."
faultString = "Request timed out"
headers = (Object)#2
messageId = "A9913DF4-F588-9AF1-B80D-68E5B3826199"
rootCause = (null)
timestamp = 0
timeToLive = 0
Status code: 0
I guess Adobe team should help me, this is purely the platform issue, my client keeps on polling after the network is changed by throwing this fault event on the same httpservice.
Windows 7 PC,
Intel core i5 2.67GHz
64 bit OS
Bump! Adobe .. need your response!
You didn't say whether other internet connectivity works during the period when you're getting this error. If it doesn't, then the problem isn't Adobe's to fix - this would be expected behavior that you need to handle in fault event handler in your httpService.
My Internet works ok when this error occured, or else i would not be able to send these messages. I immediately checked the network after I got this error.
I've rarely used HTTPService but have you tried creating a new instance (& re-adding handlers) of the service when the fault handler fires? At least to see if that resolves the issue... Make sure you remove both event handlers from the old instance of course of you'll end up with other issues.