Hi Ruwan, With regards to my initial post, I have realised that our client was not including setUseSeparateListener(true) as one of its Options properly. This has now been included and, the client now truly uses separate channel for request/response. Having fixed that, we still have problems within the ESB. i.e: The client sends request to ESB and receives back a 202 accepted response. But, we also get a 'TransportUtils - Did not find RequestResponseTransport cannot set response written' debug message (?). The ESB receives the request from the client and forwards it to the service. But, after a minute exactly, the ESB gets a 'ERROR_CODE = 00000, ERROR_MESSAGE = Connection timeout' log message.
So, when the service actually sends the response back to the ESB, the ESB logs a message 'ERROR AxisEngine The endpoint reference (EPR) for the Operation not found is http:...' Below is the synapse.xml used: <definitions xmlns="http://ws.apache.org/ns/synapse";> <log level="full"/> <sequence name="alt_endpoint"> <send> <endpoint> <address uri="http://localhost:8081/ws-wp82/services/WP82Service"; optimize="mtom"> <enableAddressing separateListener="true"/> </address> </endpoint> </send> </sequence> <in> <!-- establish which web service we are calling --> <switch source="get-property('To')"> <case regex=".*WP82Service.*"> <!-- add a SOAP header to preserve the SOAP request's original 'To' --> <header name="esb:orig-to" value="http://192.168.16:8081/ws-wp82/services/WP82Service"; xmlns:prime="http://esb.qinetiq.com"/> <sequence key="alt_endpoint"/> </case> </switch> <drop/> </in> <out> <property name="enableMTOM" value="true" scope="axis2"/> <send/> </out> </definitions > Thanx for any pointers on this. Regards, Diego. Assuming that you are using the asynchronous communication over http using WS-Addressing in between client and ESB as well as ESB and web service there should not be any timeouts, because the back channel of the http request will be after the request being sent and the client/ESB waits for the response over a different channel. Is there any possibility of attaching the synapse configuration that you are using? In which case I can have a look at the synapse.xml and find any issues in the configuration. You do not need to increase the socket.timeout if you are using separate channel to receive the response. Thanks, Ruwan Hi Asanka, Thanks for the quick reply. I should have given more details on our client settings but, it is currently configured to receive responses on a separate transport channel (asynchronous) and it has WS-addressing enabled (WS-addressing is enabled in our client, synapse ESB and web service). The transports used from client to ESB to web service and back are all regular http (no https). Also, there are no firewalls or anything like that along the way as we are testing on a test-rig!) The reason we are looking for a configuration problem within the ESB is simply because when the client calls the web service directly, no HttpClient connection loss occurs after 60 secs (no matter how long the response takes). Regards, Diego. > We are using a Synapse ESB (1.2) to mediate web service calls to a web > service. In testing, we have an Axis2 client whose requests are sent > to our Synapse ESB which, then forwards the request to the web > service. The web service itself can take a long time (10mins+) to send > a response back. The problem we have is that the client's http > connection to the ESB is closed after 60 seconds and re-tries to send > the request up to four times before giving up. > This is the default behavior of the Axis2 client side, which uses HttpClient > If our client sends the request to the web service directly, the > client happily waits 10mins+ for a response to come back. > Irrespective of the fact that this works or not, I would very strongly suggest that waiting on a open socket for a synchronous reply for 10 minutes+ does not look like a good approach.. what you should ideally use is WS-Addressing, and receive the reply on a new channel. With http/s and real life situations, an http/s connection does not live this long, and many intermediate nodes may disconnect the connection during such a long period of inactvity The information contained in this E-Mail and any subsequent correspondence is private and is intended solely for the intended recipient(s). The information in this communication may be confidential and/or legally privileged. Nothing in this e-mail is intended to conclude a contract on behalf of QinetiQ or make QinetiQ subject to any other legally binding commitments, unless the e-mail contains an express statement to the contrary or incorporates a formal Purchase Order. For those other than the recipient any disclosure, copying, distribution, or any action taken or omitted to be taken in reliance on such information is prohibited and may be unlawful. Emails and other electronic communication with QinetiQ may be monitored and recorded for business purposes including security, audit and archival purposes. Any response to this email indicates consent to this. Telephone calls to QinetiQ may be monitored or recorded for quality control, security and other business purposes. QinetiQ Limited Registered in England & Wales: Company Number:3796233 Registered office: 85 Buckingham Gate, London SW1E 6PD, United Kingdom Trading address: Cody Technology Park, Cody Building, Ively Road, Farnborough, Hampshire, GU14 0LX, United Kingdom http://www.qinetiq.com/home/notices/legal.html
