axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
Subject [jira] Commented: (AXIS-1553) Socket time-outs introduced in 1.2beta3
Date Tue, 14 Sep 2004 15:19:38 GMT
The following comment has been added to this issue:

     Author: Nelson Minar
    Created: Tue, 14 Sep 2004 8:18 AM
If I may kibbitz here, the bug report is not about whether timeouts are a good idea or not.
The bug report says that a change in 1.2b3 makes it harder to configure the timeouts. That
seems like a pretty simple bug to me.

My two cents: default for Axis should be no timeout. That's the TCP standard behaviour. It
should be easy for both server and client to set a timeout if it needs one.
View this comment:

View the issue:

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
             Basic Architecture

   Reporter: Anand Natrajan

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

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

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,
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.


[exec] Testcase: testMyService took 279.665 sec
[exec]     Caused an ERROR
[exec] Read timed out
[exec] AxisFault
[exec]  faultCode:
[exec]  faultSubcode:
[exec]  faultString: Read timed out
[exec]  faultActor:
[exec]  faultNode:
[exec]  faultDetail:
[exec]     {}

[exec] Read timed out
[exec]     at
[exec]     at
[exec]     at
                                   [exec]     at
org.apache.xerces.parsers.AbstractSAXParser.endElement(Unknown Source)
[exec]     at
org.apache.xerces.impl.XMLNSDocumentScannerImpl.scanEndElement(Unknown Source)
[exec]     at
[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(
[exec]     at
[exec]     at org.apache.axis.SOAPPart.getAsSOAPEnvelope(
[exec]     at org.apache.axis.Message.getSOAPEnvelope(
[exec]     at
[exec]     at org.apache.axis.client.AxisClient.invoke(
[exec]     at org.apache.axis.client.Call.invokeEngine(
[exec]     at org.apache.axis.client.Call.invoke(
[exec]     at org.apache.axis.client.Call.invoke(
[exec]     at org.apache.axis.client.Call.invoke(
[exec]     at org.apache.axis.client.Call.invoke(
[exec]     at
[exec]     at
[exec]     at
[exec]     at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
[exec]     at
[exec]     at

This message is automatically generated by JIRA.

If you think it was sent incorrectly contact one of the administrators:

If you want more information on JIRA, or have a bug to report see:

View raw message