You are viewing a plain text version of this content. The canonical link for it is here.
Posted to java-user@axis.apache.org by Stadelmann Josef <jo...@axa-winterthur.ch> on 2010/06/09 17:03:12 UTC
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
RE: WCF 3.5 Client times out - caused by server ...
Posted by Andy Dysart <AD...@prospricing.com>.
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:josef.stadelmann@axa-winterthur.ch]
Sent: Tuesday, June 15, 2010 12:44 PM
To: java-user@axis.apache.org
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
AW: WCF 3.5 Client times out - caused by server ...
Posted by Stadelmann Josef <jo...@axa-winterthur.ch>.
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:josef.stadelmann@axa-winterthur.ch]
Gesendet: Mittwoch, 9. Juni 2010 17:03
An: axis-user@ws.apache.org
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