It seems to me that no one likes to burn it's fingers with time-outs of the sort I am asking for?
The situation is as it is. My .NET WCF 3.5 client times out when the axis2 web service is busy for more than 60000 milliseconds, Maybe it's a timeout in Apache Jakarta Tomcat Maybe it's a timeout in Axis2 or its HTTP-Transport (because I use that one) Maybe it's just an yet unknown timeout which makes me head sick. Axis2/Java is a huge servlet, as such a servlet has to work, such work can take time, and now comes the question: Which time-out feature in Apache Tomcat / JK, API, Connectors, triggers first, is responsible and a) can close things like sockets, b) can take away resources belonging to a clients request which may hold resources on the server for the duration of the back-end-work, c) which then creates an impact as given below, that is to say, the WCF Client cries that there was a time out, and times out. Or is Tomcat not the bad guy, but the Axis2-huge-servlet itself or it's transport? In this case - which time-out shall I massage in axis2.xml or the like, or in any other property file, which avoids that sockets on which a request is pending time-out A pointer and overview about all potential time-outs may help to cure this problem. Any clue or hint is very appreciated. Josef Von: Stadelmann Josef [mailto:[email protected]] Gesendet: Mittwoch, 9. Juni 2010 17:03 An: [email protected] Betreff: WCF 3.5 Client times out - caused by server ... Dear Apache Axis2 Community, dear axis2 experts I am struggling with a Microsoft Windows Communication Foundation (WCF) 3.5 Web Service Client; All works fine to an Axis2-1.4 /Java Web Service Engine, to my Spezpla Web Service; This is further an integration via WSIT from HP to our OpenVMS Legacy Server held in C and PASCAL with Oracle DB (out of process). That's mostly OK but What bothers me today is the fact that up on long lasting work performed by the Axis2 based web service server, ( > 1 Minute) the WCF 3.5 client times out. And now - surprise surprise find below what the expert from Microsoft says: ++>> MS expert talking: After talking with some of our devs on this issue, I think I was mistaken in saying it is the SendTimeout you were hitting. What you really need to set is the ReceiveTimeout on the Service side binding. Here's why: When using TCP, the communication is session full. In general, when the Client creates a channel to the Service, it uses up some Service side resources. The Service has a ReceiveTimeout on the binding to configure how long to allow the Client to keep a channel open to the Service. The ReceiveTimeout doesn't have anything to do with a receive action duration. Further, the Client doesn't know what the ReceiveTimeout is on the Service, so when it faults because of ReceiveTimeout being exceeded, all it can tell you is what the local timeouts were. Just in case this timeout was caused by something local to the Client, the exception gives you what the SendTimeout was. So, to have a NetTcp Service allow a Client to keep a channel open for longer than 10 minutes, you need to increase the ReceiveTimeout on the Service side's binding. HTH, -James <++ End MS Expert 1. I like to thank James for this explanation, I was seeking on the wrong side of the pond. 2. Now - it seems that I need to adjust something at the server side to get what James is talking about, 3. without knowing what I have to look for, I need your help. 4. Any thoughts are welcome in this regard; 5. ups - we are using Axis2-1.2 on a OpenVMS machine but have seen equal behavior with AXIS2-1.5.1 on the same machine 6. and we use long lasting sessions via scope=soapsession ++> So, to have a NetTcp Service allow a Client to keep a channel open for longer than 10 minutes, you need to increase the ReceiveTimeout on the Service side's binding. <++ How can I do that on a Axis2 Java web service using SOAP/XML and HTTP Transport protocols? Josef Stadelmann @axa-winterthur.ch
