ws-soap-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
Subject Memo: RE: HTTP 1.1 Persistent Connection
Date Wed, 21 Jan 2004 03:03:06 GMT
Thanks a lot (and also for Scott on the suggestion on NoTcpDelay). I will
try the setNoTcpDelay first (as it's much simpler) and see if there is any
help. If situation does not improve, I will try the HTTPClient solution.

Meanwhile, I have two questions (actually for Scott):

(1) I know that the TCP delay and Nagle algorithm is to protect network
congestion by large number of small packets. It is useful for application
like telnet. However, it looks like in an HTTP request/response model where
the packet is not small, Nagle algorithm will likely cause performance
degrade. Is there any reason why Apache SOAP has TCP delay enabled (and not
disabled) by default?
(2) As an alternative, I am thinking of writing a transport to use Sun
provided HttpUrlConnection as it handles the persistent connection for me.
I searched the archive and see one reason of not using it in Apache SOAP is
that we can't access the data stream if a 500 error occurs. Apart from
this, is there any other reason for it? As we primarily use SOAP/HTTP as a
transport media for XML message, the 500 issue is not that important to us.


bill-soap@carpenter.ORG (WJCarpenter) on 21 Jan 2004 05:07

 Our Ref:                    Your Ref:                                           

Subject:    RE: HTTP 1.1 Persistent Connection

bk> I knew that Apache SOAP only support HTTP 1.0 and I've searched
bk> through the archive of this mailing list and don't see anyone
bk> doing HTTP 1.1. Is it very diffcult to do? We are not HTTP expert
bk> but we do want to know if it is possible to do it.

I don't know about the server side, but here is info on how to get
this going for Apache SOAP client:

Here's some discussion of performance stuff:

In addition, the TcpNoDelay factor (that Scott mentions in another
email in this thread) is worth looking into.  It affects latency per
connnection but doesn't affect overall throughput (it's pure
I/O-blocked delay).  You will know it underlies your problem if you
are seeing R/T times that are remarkably and consistently like 200ms.
bill@carpenter.ORG (WJCarpenter)    PGP 0x91865119
38 95 1B 69 C9 C6 3D 25    73 46 32 04 69 D6 ED F3

This message originated from the Internet. Its originator may or may not
be who they claim to be and the information contained in the message
and any attachments may or may not be accurate.

The Hongkong and Shanghai Banking Corporation Limited
whose registered address is 1 Queen's Road Central, Hong Kong

This E-mail is confidential. It may also be legally privileged.
If you are not the addressee you may not copy, forward, disclose
or use any part of it. If you have received this message in error,
please delete it and all copies from your system and notify the
sender immediately by return E-mail.

Internet communications cannot be guaranteed to be timely,
secure, error or virus-free. The sender does not accept liability
for any errors or omissions.

View raw message