I can't give you a comprehensive answer, but re your "unknown timeout" - we've 
fought problems like this that ended up being caused by firewalls, routers, and 
load balancers that had timeouts configured in them.  A good tool to help 
understand where the timeout is occurring is Wireshark or other similar packet 
capture tools.  It takes a little knowledge about how TCP/IP works, but armed 
with that you can determine who is closing the connection (client or server), 
and by monitoring close to the client versus close to the server, determine if 
an intermediate party (e.g. firewall) is involved.

Based on your description of the problem it sounds like either a client 
configuration issue or some intermediate.  You would not typically get a 
timeout error message at the client because of a server (Tomcat or Axis2) 
setting in my experience.

-andy

From: Stadelmann Josef [mailto:[email protected]]
Sent: Tuesday, June 15, 2010 12:44 PM
To: [email protected]
Subject: AW: WCF 3.5 Client times out - caused by server ...

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

Reply via email to