1

I'm writing a standalone application that implements a Web Service, for which the Endpoint is published using the embedded Sun HttpServer. I have an odd issue with this, where in a specific deployment situation, there is an apparent delay between the server processing /sending the reply and the client receiving the reply.

Let me give a few scenarios:

Case 1) Working: server is running inside Eclipse, which uses OpenJDK 1.6.0_23 as runtime. Client is implemented with axis (not axis2!) and is running on Solaris x86 inside JBoss (must admit I don't know the exact Java version used, but I suspect a Java 5 version).

Case 2) Working: server is running on Solaris x86 with java 1.6.0_26, client is running inside Eclipse with OpenJDK 1.6.0_23.

Case 3) Not working: server is running on Solaris x86 with java 1.6.0_26, client is on Solaris x86 with axis on Solaris x86 (again, suspect it's Java 5, not 6).

I'm wondering if I could be suffering from the following Java bug, which is fixed in 1.6.0_30 (assuming that OpenJDK 1.6.0_xx does not suffer the same bug)?

http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7068416

But if that's the case, then why would case 2 work? Can the client somehow control the TCP_NODELAY on the server side?

On the exact delays that i have observed: I have 2 web services, published on different contexts. Eg 2 different WSDLs. The client has (obviously) separate (axis 1) bindings for each service. For one service, I see a consistent delay of exactly 150 seconds, for the other service the delay is consistently 300 seconds. Do these values ring a bell to anybody?

Maarten

Edit I am now leaning towards the cause and solution in Eclipse Generated Web Service Client Extremely Slow. Can't test at the moment as I'm sitting in a hotel room without access to the system.

Community
  • 1
  • 1
Maarten Boekhold
  • 867
  • 11
  • 21
  • Let me add the following: when I say "the server processing/sending the reply", I am talking about returning from the method implementing the @WebMethod. I've inserted a SOAPHandler into my code that prints out the outgoing SOAP reply, and that's how I am measuring the time between my server application "sending" the response, and the client "receiving" the response. – Maarten Boekhold Dec 18 '11 at 18:15

1 Answers1

0

OK, managed to solve this, by telling Axis to use the CommonsHttpSender instead of the default HttpSender. Since the relevant application already had the prerequisite jars for that inside its WEB-INF/lib directory, that wasn't such a big deal.

To make Axis (1.4) use the CommonsHttpSender, create a "client-config.wsdd" file in the following location (note: this was the non-obvious part that caused me quite a few headaches):

MY.ear/MY.war/WEB-INF/classes/org/apache/axis/client/client-config.wsdd

with the following contents:

<?xml version="1.0" encoding="UTF-8"?> 
<deployment 
    name="commonsHTTPConfig" 
    xmlns="http://xml.apache.org/axis/wsdd/" 
    xmlns:java="http://xml.apache.org/axis/wsdd/providers/java">

   <!-- use CommonsHTTPSender instead of the default HTTPSender -->
  <transport name="http" pivot="java:org.apache.axis.transport.http.CommonsHTTPSender" />  

  <transport name="local" pivot = "java:org.apache.axis.transport.local.LocalSender" /> 
  <transport name="java" pivot="java:org.apache.axis.transport.java.JavaSender" /> 
</deployment>

Restart your application. After this change, Axis will use HTTP/1.1 to make web service calls, which seems to be all that was needed to correct this annoying delay. Seems that there is something in the HTTP protocol specs (or perhaps Axis' implementation) that doesn't like a HTTP/1.1 response to a HTTP/1.0 request.

Maarten

Maarten Boekhold
  • 867
  • 11
  • 21