Hi Diego, Nice to hear that you got it to work... and thanks for informing us about that.
Thanks, Ruwan On Wed, Oct 22, 2008 at 8:13 PM, Paloschi Diego E <[EMAIL PROTECTED]>wrote: > 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. > -- Ruwan Linton http://wso2.org - "Oxygenating the Web Services Platform" http://ruwansblog.blogspot.com/
