Mike,
I'm not sure I understand ( not your mail - the "available" definition ).
Isn't availabe supposed to return how many bytes can be returned without a
read() on the "primary" source ( that would block ) ?
What you describe is slightly different - and I'm not sure it's a good
idea. In any case, I would prefer the second choice - have the protocol
return what it has in it's buffers ( if any ).
Of course, a big question is what is available :-) If the data has been
read by Apache but not yet sent to tomcat - is it available ? Probably so
( AFAIK this shouldn't happen - actual read from network is driven by a
tomcat request and no data is buffered on apache ). But that would be a
bit too complex even for 3.3 ( but may be implemented in a future ajp14 )
I don't think this would have any significant impact on code stability -
since you replace a method that returns 0 to something a bit more acurate,
and I see no problem with adding a patch to 3.3 ( 3.2 is quite close to
a release, it's up to Marc to decide ). But I'm a bit concerned about the
corectness of the result.
Costin
On Wed, 21 Mar 2001, Mike Anderson wrote:
> I noticed that this bug was marked RESOLVED/LATER and was wondering if there was any
>way to get this into 3.2.2 since that is the version that is closest to being
>released. I've already found 2 ways to fix this issue but am willing to abide by the
>groups decision and concentrate on getting this into the 3.3 release instead.
> The 2 ways to fix this are:
>
> 1. In BufferedServletInputStream, implement an available() method that returns
>limit - bytesRead or 0 whichever is greater. The limit class variable is set to the
>value of the Content-Length header and bytesRead is the number of bytes read since
>limit was set (see the attached diff1.txt). This is the easy fix but doesn't address
>the feature of available that says it will return the number of bytes that can be
>read "without blocking". Obviously, if there is a large amount of data, a read will
>most likely block at some point depending on how much is asked for, however this
>prevents a condition where one of the adapters returns 0 because a read hasn't
>actually been requested from the webserver.
>
> 2. Update BufferedServletInputStream to call reqA.available and then update the
>following files to provide this interface:
> Request.java
> RequestImpl.java
> HttpRequestAdapter.java
> Ajp12ConnectionHandler.java
> Ajp13ConnectorRequest.java
> JNIConnectionHandler.java
> MsgConnector.java
> TcpConnector.java
> Each of these classes would need to provide an appropriate available() method. I've
>also done the work on these files as well (see the attached diff2.txt) but noticed
>that since some of the protocols (particularly AJP13) actually have to request a read
>to fill their internal buffer, the adapter (i.e. Ajp13ConnectorRequest.java) will
>return a 0 if doRead is called and it exactly empties the internal buffer. Also the
>JNIRequestAdapter (in JNIConnectionHandler.java) makes a native call back into the
>webserver to do the reads and so available is implemented similar to #1 above; it
>just returns the max of contentLength - bytesRead or 0. This was because I'm not
>sure of a way to imp
>
> After testing both of these, implementation 1 is actually faster and more reliable.
>Typically if someone is calling available and they get back a 0, they would block the
>thread anyways and so it makes some sense to let it block on the read plus it gets
>around the issue of an adapter requiring one of it's read methods to be called to
>actually have something available.
>
> Any response positive or negative would be appreciated so that I know where to focus
>my energy (i.e. 3.2.2 or 3.3).
>
>
>
>
