axis-c-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Franz Fehringer <>
Subject Re: http transport/channel dysfunctional since last change
Date Mon, 08 Jan 2007 16:14:31 GMT
Hello Nadir,

Will you reintroduce your enhancements?
I am particulary interested because a colleague of mine told me about 
difficulties with

    * Nonrobust Axis connection handling (after connection goes down,
      Axis throws exceptions on further WS calls instead of reconnecting).
    * Axis not fully closing connections after successful WS call
      (increase in number of unused connections over time).

I have not verified this personally, but my colleague is rather capable.
Are problems in this field known?

Thanks and best regards


Nadir Amra schrieb:
> Franz,
> I reverted the transport changes to what it was, for now. 
> I believe the errors you are getting are some sort of bugs in the HTTP 
> transport parsing that existed prior to my changes but were masked due to 
> the current implementation of using a looping counter and ignoring 0-byte 
> reads errors.   My changes that has caused you problems was removing the 
> looping counter and throwing and exception whenever a read completes with 
> 0 length - an indication that the remote side has closed the connection. 
> My opinion was that if Axis was coming down requesting to read more data 
> when there is no more data available, then it must be a bug.  This is all 
> from the client side point of view. 
> Can you please test the changes. 
> I will pursue the bugs and fashion a complete fix.
> Nadir K. Amra
> Franz Fehringer <> wrote on 11/28/2006 04:48:57 AM:
>> I found out, that the problem shows up exactly when *both* 
>> "Proxy-Connection: close" *and* "Content-Length" are set.
>> Franz
>> Franz Fehringer schrieb:
>>> Hello Nadir,
>>> With your latest changes (i got the via svn up today) http 
>>> communication completely ceases to work.
>>> 1) If the server side does not close, the axis client waits forever.
>>> 2) If the server closes (this is for me the normal case; i get 
>>> Proxy-Connection: close in the response) the client faults with
>>>    HTTPTransportException: Input streaming error while reading from 
>>> channel. Remote side of socket has been closed.
>>> In fact both case should work, because
>>> 1) The server sends the complete message as announced with 
>>> Content-Length.
>>> 2) Closing of the server side is normal and not an error.
>>> Can you have a look at the problem and perhaps revert some of your 
>>> changes?
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

View raw message