??,?: Vote on timeout issues (was RE: read timeout)

[James Liao <No...@21cn.com>]

I agree with Dug, I vote for 2+3. 
Axis 1.1 just make all my applications can't work.








bleck!  talk about loaded choices!
I vote for 3:  go back to Axis 1.0 behaviour
(actually, 2 should be done anyway!)
-Dug


Eric.D.Friedman@wellsfargo.com on 07/14/2003 12:28:03 PM

Please respond to axis-dev@ws.apache.org

To:    axis-dev@ws.apache.org
cc:
Subject:    Vote on timeout issues (was RE: read timeout)


Since I'd like to see this thread end soon, I propose that we vote on the
following:

1. Leave the timeout at 60 seconds;  There is no way to please everyone
with
a single value, as this is a *deployment* concern, so let's just leave it
at
60 and move onto the real problem, which is:

2. Make the timeout configurable per-transport, as a deployment concern,
without requiring that people write code.  It should be possible for
clients
that talk to multiple web services providers to have different timeouts for
those providers based on the different SLAs.

Eric

-----Original Message-----
From: Doug Davis [mailto:dug@us.ibm.com]
Sent: Monday, July 14, 2003 9:21 AM
To: axis-dev@ws.apache.org
Subject: RE: read timeout







Tom,
  The attitude I was referring to was post-1.0 and I usually only pop up
like this when Axis' behavior changes (read into that: breaks my product) -
so IMO changing it so I can get 1.0 behavior back is justified.  But that's
ok - I'm used to having to having my own version of Axis....   :-)
So... if you're ok with it, increase it to 5 hours and be done with it -
but I still would like to know why Axis believe it knows better than a
normal socket connection at what the "default" timeout should be.
-Dug


Tom Jordahl <to...@macromedia.com> on 07/14/2003 12:09:24 PM

Please respond to axis-dev@ws.apache.org

To:    "'axis-dev@ws.apache.org'" <ax...@ws.apache.org>
cc:
Subject:    RE: read timeout


Dug wrote:
> I've been told several times from axis-dev'ers that all changes made
> were necessary because it was just wrong in the past - and if
> breaks current users - (pardon my french) screw 'em (backwards
> compatibility isn't even considered).

In fairness, most of this attitude was during the pre-1.0 development
cycle, when Axis did not have a stake in the ground *at all*.

With 1.1 and beyond, I believe everyone is very much in agreement that we
can not change public APIs that affect backwards compatibility.

Now fixing broken *behaviors* to be correct is goodness and I don't believe
you are saying that.

What we have is a disagreement about whether this behavior is broken by
timing out at all by default.

I would consider increasing the timeout, but I am against reversing the
change to default to no timeout.

--
Tom Jordahl
Macromedia Server Development

-----Original Message-----
From: Doug Davis [mailto:dug@us.ibm.com]
Sent: Monday, July 14, 2003 11:17 AM
To: axis-dev@ws.apache.org
Subject: RE: read timeout






I can't help but laugh.  I agree with you that its annoying when products
keep changing stuff that people use - but when looking at the history of
Axis, "change" is Axis' middle name  :-)    I've been told several times
from axis-dev'ers that all changes made were necessary because it was just
wrong in the past - and if breaks current users - (pardon my french) screw
'em (backwards compatibility isn't even considered).  Well, in the big list
of changes that go into Axis this doesn't break APIs it just makes life
easier for Axis developers/users - to me its an easy choice.  "stuck
with..." is such a relative phrase :-)

To the others who responded saying that "zero" is just wrong  ;-)   I see
the problems you've described as perfect reasons why the APIs need to be
defined to allow you to change it - and if the client hangs because the
client never got back a response and the socket is still open then (imo) it
should be the responsibility of the client application to set an
appropriate timeout.  Having axis guess at what the appropriate default
should be is just inviting the pains 'some' of us are seeing.  One way I
look at it is this - why would Axis' default timeout be any less than the
normal socket.read() or HTTPURLConnection timeout?  (those are zero aren't
they? not sure)

-Dug


"Kellogg, Richard" <RK...@MICROS.COM> on 07/14/2003 10:58:10 AM

Please respond to axis-dev@ws.apache.org

To:    <ax...@ws.apache.org>
cc:
Subject:    RE: read timeout


I actually tend to agree with Doug.  A timeout of zero would have been
preferable but we have already shipped Axis 1.1.  Therefore we are stuck
with the timeout of 60 seconds.  I personally hate it when products keep
changing their minds on things like this.

My vote is to leave it at 60 seconds.

Rick


-----Original Message-----
From: Doug Davis [mailto:dug@us.ibm.com]
Sent: Monday, July 14, 2003 10:53 AM
To: axis-dev@ws.apache.org
Subject: RE: read timeout







As you indicated, the value you pick will never make everyone happy. The
best you can hope for is to make sure that there are sufficient APIs such
that people who use the DIIs, stubbies or whatever can get access to that
setting easily.  Personally, I think Axis should default to "0" (no
timeout) because by default I would want the system to be as
lenient/tolerant as possible - and if someone is running in an environment
that requires stricter controls they can set it as such - picking any value
other than zero give preference to whatever machine/environment the axis
developer who wrote that line of code happens to be using at that moment.
-Dug


Tom Jordahl <to...@macromedia.com> on 07/14/2003 10:35:55 AM

Please respond to axis-dev@ws.apache.org

To:    "'axis-dev@ws.apache.org'" <ax...@ws.apache.org>
cc:
Subject:    RE: read timeout



For the record, I hard coded this default and it wasn't a mistake. :-)  I
asked for feedback at the time the change was made and I believe I got
consensus that 60 seconds was reasonable.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=18277

What would be a better default?  2 minutes?  5 minutes?  10 minutes? (ack!)

Speaking as someone who embeds Axis in a multi-threaded, request serving,
application server, 60 second timeouts are about all we would tolerate
unless the user asks for longer.  I understand that my use case may be
different from non-user interactive, 'background' processing.

--
Tom Jordahl
Macromedia Server Development

-----Original Message-----
From: Doug Davis [mailto:dug@us.ibm.com]
Sent: Saturday, July 12, 2003 12:39 AM
To: axis-dev@ws.apache.org
Subject: Re: read timeout






Yup - as soon as I sent my note I noticed it in MessageContext too.  I
agree, it sure seems like a mistake to me.
-Dug


Thomas Sandholm <sa...@mcs.anl.gov> on 07/12/2003 12:31:03 AM

Please respond to axis-dev@ws.apache.org

To:    axis-dev@ws.apache.org, axis-dev@ws.apache.org
cc:
Subject:    Re: read timeout


Yes for some reason a 60sec socket read timeout is hardcoded in the
MessageContext class. I think this is a mistake personally, and it has
caused our users a lot of problems too. The default timeout should at least

be configurable without having to change the timeout property on every stub

you are calling as the FAQ
http://nagoya.apache.org/wiki/apachewiki.cgi?AxisProjectPages/JavaTimeout
explains.
We ended up writing a handler that allows you to set a system property to
change the default timeout.
/Thomas
At 08:51 PM 7/11/2003 -0600, Doug Davis wrote:





>Since Axis 1.1 rc2 something changed that is causing my requests that take
>a long time (over say 3 minutes) to complete to timeout with:
>java.io.InterruptedIOException: Read timed out
>         at java.net.SocketInputStream.socketRead(Native Method)
>         at java.net.SocketInputStream.read(SocketInputStream.java:113)
>         at java.io.BufferedInputStream.fill(BufferedInputStream.java:202)
>         at java.io.BufferedInputStream.read(BufferedInputStream.java:220)
>         at
>org.apache.axis.transport.http.HTTPSender.readHeadersFromSocket(HTTPS
>ender.java:506)
>         at
>org.apache.axis.transport.http.HTTPSender.invoke(HTTPSender.java:127)
>
>         at
>com.ibm.wstk.axis.handlers.WSTKHTTPSender.invoke(WSTKHTTPSender.java:
>37)
>         at
>org.apache.axis.strategies.InvocationStrategy.visit(InvocationStrateg...
>
>In rc2 the client would wait forever, or at least long enough for me to
>never have noticed a problem, but now my client requests timeout after
>about 2 minutes.  In looking thru the code I don't see anything obvious
>that's changed - does anyone know of anything that was changed that might
>cause this new behavior?
>
>-Dug