The 500 status is an essential issue if you want to read SOAP Faults, since they are accompanied by a 500 status.
Prior to version 2.3, Apache SOAP provided no means for the client to specify whether Nagling would be enabled or disabled. When the ability to specify this was added, it was decided that the default (when the client did nothing) would be to duplicate the previous behavior, which was to leave Nagling enabled. While the Nagle algorithm might still be useful with HTTP on a very congested WAN, the use of reasonably sized buffers for the Java streams means it is very unlikely that having Nagle enabled is beneficial. Scott Nichol Do not send e-mail directly to this e-mail address, because it is filtered to accept only mail from specific mail lists. ----- Original Message ----- From: <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Tuesday, January 20, 2004 10:03 PM Subject: Memo: RE: HTTP 1.1 Persistent Connection > 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. > > Billy > > > > > > > > [EMAIL PROTECTED] (WJCarpenter) on 21 Jan 2004 05:07 > > To: [EMAIL PROTECTED] > cc: > > > > 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: > > http://marc.theaimsgroup.com/?l=soap-user&m=104447554215308&w=2 > > Here's some discussion of performance stuff: > > http://marc.theaimsgroup.com/?l=soap-dev&m=103230079704759&w=2 > > 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. > -- > [EMAIL PROTECTED] (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. > ********************************************************************** > >
