DO NOT REPLY [Bug 18277] New: - Socket Timeouts for Axis Clients

[bu...@apache.org]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://nagoya.apache.org/bugzilla/show_bug.cgi?id=18277>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

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

Socket Timeouts for Axis Clients

           Summary: Socket Timeouts for Axis Clients
           Product: Axis
           Version: current (nightly)
          Platform: Other
        OS/Version: Other
            Status: NEW
          Severity: Normal
          Priority: Other
         Component: Basic Architecture
        AssignedTo: axis-dev@ws.apache.org
        ReportedBy: dims@yahoo.com


Note from "Jens Schumann" <je...@void.fm> on axis-dev@ mailing list.

=====================================================
Some broken load balancers in our network configuration caused hanging
connections calling WebServices using Axis Clients (1.1RC2). Since the
generated Axis Client Code does not set a default socket timeout the calling
thread was blocking forever, something which wasn't as obvious as it could
be. A default socket timeout would have been wonderful ;)

With the current client code I am unable to set the socket timeout directly,
so I need to alter the generated code to set a socket timeout for the
underlying HttpSender. You may argue easy to fix, but there is another
problem: The client code throws RemoteExceptions (and AxisFaults) only, so I
am unable to treat local and remote failures differently. Analyzing Axis
fault Strings isn't the best way to implement Exception handling.


I am somewhat short on time and thus being said I hope someone else might be
able to implement the following changes ;(.


1. Set default socket timeout for Axis Clients to 30 or 60 seconds.
2. Generate code which allows to set the socket timeout for the axis client
easily.
3. Add a local exception (IOException?) to the exposed web service
operations to allow better handling of local (socket) exceptions.


I think 1 & 2 should be easy to fix, but 3 will break backwards
compatibility.

Jens
=====================================================