Hi Ruwan, The problem has now been resolved and, it wasn't a Synapse ESB issue after all.
After taking a closer look at the web service itself, I have realized that the messageReceiver for the IN_OUT MEP operation was using the default RawXMLINOutMessageReceiver class which is synchronous. I have changed it to use RawXMLINOutAsyncMessageReceiver class (in Axis version 1.3) which is indeed asynchronous. I was always under the impression that no modifications were necessary at the service end if a client wishes to make calls to it asynchronously, but this doesn't seem to be the case? Thanks again for your help and time! Regards, Diego. -----Original Message----- From: Ruwan Linton [mailto:[EMAIL PROTECTED] Sent: 22 October 2008 12:46 To: [email protected] Subject: Re: client http connection to synapse ESB closed four times every 60 seconds Hi Diego, Can you inspect the message going from synapse to the web service using a TCPMon tool and attach the request being sent to the service and what you see on the back channel. Ideally you should be seeing a 202 Accepted from service to synapse. Thanks, Ruwan On Wed, Oct 22, 2008 at 4:23 PM, Paloschi Diego E <[EMAIL PROTECTED]>wrote: > 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 > -- Ruwan Linton http://wso2.org - "Oxygenating the Web Services Platform" http://ruwansblog.blogspot.com/ The QinetiQ e-mail privacy policy and company information is detailed elsewhere in the body of this email.
