[jira] Commented: (AXIS-1553) Socket time-outs introduced in 1.2beta3

[ax...@ws.apache.org]

The following comment has been added to this issue:

     Author: Steve Loughran
    Created: Tue, 14 Sep 2004 2:17 AM
       Body:
You set the timeouts on a connection with Call.setProperty(	CONNECTION_TIMEOUT_PROPERTY , new Integer(timeout)) 

so can select a very long timeout, or 0 for no timeout. You are still vulnerable to things like proxy servers and other items out of scope. That often includes servlet engines and load balencing front ends, to think of it. 

As an aside, if it really takes a long time to build a request, you should consider whether you could devise a better API. For example, a caller could create a query and then either get a message back, or poll intermittently for results. It makes part of the service more complex (you need state, and perhaps cleanup code),  but scaling easier as you can handle more requests and appear responsive. (the endpoint adds all queries to a queue, one or more worker threads dispatches it). Your current design probably wont handle many callers, 




---------------------------------------------------------------------
View this comment:
  http://issues.apache.org/jira/browse/AXIS-1553?page=comments#action_53080

---------------------------------------------------------------------
View the issue:
  http://issues.apache.org/jira/browse/AXIS-1553

Here is an overview of the issue:
---------------------------------------------------------------------
        Key: AXIS-1553
    Summary: Socket time-outs introduced in 1.2beta3
       Type: Bug

     Status: Unassigned
   Priority: Critical

    Project: Axis
 Components: 
             Basic Architecture
   Versions:
             beta-3

   Assignee: 
   Reporter: Anand Natrajan

    Created: Mon, 13 Sep 2004 8:35 AM
    Updated: Tue, 14 Sep 2004 2:17 AM
Environment: Solaris/Linux

Description:
As part of the web services I am deploying, I have some methods that
take a while to complete (in truth, they return so much data that it
takes a while to accumulate all of that).

When I was deploying Axis 1.2beta2 on the server and client side,
everything worked well with whatever defaults Axis uses out of the
box.

When I changed over to Axis 1.2beta3 on the server and client side,
I started getting socket time-outs (see trace below). The errors are
not deterministic - when there's a failure, it's often one of these
long methods that fails, but it may be a different method each time.
When I revert to Axis 1.2beta2 the problem disappears.

On reading the source code for 1.2beta2 and 1.2beta3 and doing some
judicious diffs, the problem seems to be the following difference:

In 1.2b2, we had: org.apache.axis.encoding.DeserializationContextImpl:158
    EnvelopeBuilder builder = new EnvelopeBuilder(messageType,
getSOAPConstants());
In 1.2b3, we have: org.apache.axis.encoding.DeserializationContext:159
    EnvelopeBuilder builder = new EnvelopeBuilder(messageType, null);

Any ideas whether this change could be causing the problem? It looks
to my naive eyes that in 1.2beta3 we've stopped reading in SOAP
constants. Ergo, even if I change my web.xml to include a session
time-out snippet asking for 30-minute session time-outs, there's no
difference - I still get similar errors.

Anand

[exec] Testcase: testMyService took 279.665 sec
[exec]     Caused an ERROR
[exec] java.net.SocketTimeoutException: Read timed out
[exec] AxisFault
[exec]  faultCode:
{http://schemas.xmlsoap.org/soap/envelope/}Server.userException
[exec]  faultSubcode:
[exec]  faultString: java.net.SocketTimeoutException: Read timed out
[exec]  faultActor:
[exec]  faultNode:
[exec]  faultDetail:
[exec]     {http://xml.apache.org/axis/}hostname:palladium.abc.local

[exec] java.net.SocketTimeoutException: Read timed out
[exec]     at
org.apache.axis.message.SOAPFaultBuilder.createFault(SOAPFaultBuilder.java:221)
[exec]     at
org.apache.axis.message.SOAPFaultBuilder.endElement(SOAPFaultBuilder.java:128)
[exec]     at
org.apache.axis.encoding.DeserializationContext.endElement(DeserializationContext.java:1077)                                    [exec]     at
org.apache.xerces.parsers.AbstractSAXParser.endElement(Unknown Source)
[exec]     at
org.apache.xerces.impl.XMLNSDocumentScannerImpl.scanEndElement(Unknown Source)
[exec]     at
org.apache.xerces.impl.XMLDocumentFragmentScannerImpl$FragmentContentDispatcher.dispatch(Unknown Source)
[exec]     at
org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanDocument(Unknown Source)
[exec]     at org.apache.xerces.parsers.XML11Configuration.parse(Unknown Source)
[exec]     at org.apache.xerces.parsers.XML11Configuration.parse(Unknown Source)
[exec]     at org.apache.xerces.parsers.XMLParser.parse(Unknown Source)
[exec]     at org.apache.xerces.parsers.AbstractSAXParser.parse(Unknown Source)
[exec]     at javax.xml.parsers.SAXParser.parse(SAXParser.java:345)
[exec]     at
org.apache.axis.encoding.DeserializationContext.parse(DeserializationContext.java:225)
[exec]     at org.apache.axis.SOAPPart.getAsSOAPEnvelope(SOAPPart.java:645)
[exec]     at org.apache.axis.Message.getSOAPEnvelope(Message.java:424)
[exec]     at
org.apache.axis.handlers.soap.MustUnderstandChecker.invoke(MustUnderstandChecker.java:62)
[exec]     at org.apache.axis.client.AxisClient.invoke(AxisClient.java:173)
[exec]     at org.apache.axis.client.Call.invokeEngine(Call.java:2735)
[exec]     at org.apache.axis.client.Call.invoke(Call.java:2718)
[exec]     at org.apache.axis.client.Call.invoke(Call.java:2394)
[exec]     at org.apache.axis.client.Call.invoke(Call.java:2317)
[exec]     at org.apache.axis.client.Call.invoke(Call.java:1774)
[exec]     at
com.abc.ws.stubs.DataServicesWrapperSoapBindingStub.getOutputAttach(DataServicesWrapperSoapBindingStub.java:437)
[exec]     at
com.abc.ws.test.MyServiceTest.actual4WSDLTests(MyServiceTest.java:851)
[exec]     at
com.abc.ws.test.MyServiceTest.testMyService(MyServiceTest.java:242)
[exec]     at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
[exec]     at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
[exec]     at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)


---------------------------------------------------------------------
JIRA INFORMATION:
This message is automatically generated by JIRA.

If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa

If you want more information on JIRA, or have a bug to report see:
   http://www.atlassian.com/software/jira