We create Real Time Services and add them to Web Services. Web Services when called from Web Navigator - We get either of 2 Types of Error:
Time Out Error
Web Service returned error. Fault Code: “http://schemas.xmlsoap.org/soap/envelope/Sender” Fault String: "Web Service is unable to process the request to call real-time service: ‘RT_Service_Name’ using access server <access_server_name> . Error: Server sent back error: Process time out.
Both of these errors may indicate the time out scenario. However, when I provide same data and execute, it works fine. Hence, I do not think it is code related issue - If so, then it would be consistently throwing same error.
I think it is related to number of calls or so… Could anyone provide more light onto this?
Can you go through the realtime services and check for log information there? How many instances have been started, did you get a realtime message into the service even,…some clues so we can find the root cause.
With the provided information “processing timeout” I would assume the realtime message is sent into the realtime dataflow, processed there but no return is produced within a given timeframe. So either this timeframe is too thight - it is a property of the realtime service found in the Management Console -> Administration -> Realtime -> Servicename -> Configuration, or it really takes so long to produce the output for whatever reason.
So when you execute the dataflow in test mode, how long does it take to run the dataflow? There could be unexpected side effects, e.g. there is a lookup_ext() in cache_mode, loading the cache takes 5 minutes. But the cache is loaded once the first message is received, so if the timeout is less than 5 minutes it would fail at the first message always.
The other thing that concerns me a bit is your statement regarding the amount of messages. Aren’t you testing it with one message only at the moment? If that can’t be done, you might want to send a realtime message into the access server using the clienttest.exe utility.
Thanks for answering. We are using same default parameters (i.e. timeout and other parameters). Root Cause
The problem is when there are multiple transforms that have multiple outputs and the internal cache splitter would get stuck sometimes.
When this happens the whole real time dataflow just waits and hangs.
Resolution:[u]
Reduced the number of components. Also, it might be fixed in new version.