Improved available value

[Remy Maucherat <re...@apache.org>]

Hi,

I think I would be able to improve the handling of the available method 
(on the input stream) using a new action code. The processors will then 
query the various filters and their own buffer to see if there are bytes 
available somewhere, and the purpose would be to clear up the 
uncertainty which may occur on the first read (if the beginning of the 
entity body was sent along with the request header in a single packet). 
To be refined a little of course.

Rémy

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org

Re: Improved available value

[Filip Hanik - Dev Lists <de...@hanik.com>]

Remy Maucherat wrote:
> Filip Hanik - Dev Lists wrote:
>> Remy Maucherat wrote:
>>> Hi,
>>>
>>> I think I would be able to improve the handling of the available 
>>> method (on the input stream) using a new action code. The processors 
>>> will then query the various filters and their own buffer to see if 
>>> there are bytes available somewhere, and the purpose would be to 
>>> clear up the uncertainty which may occur on the first read (if the 
>>> beginning of the entity body was sent along with the request header 
>>> in a single packet). To be refined a little of course.
>> definitely a good idea, I imagine the method has to be implemented 
>> all the way down the chain to eventually return a correct value at 
>> the top of the request.
>
> So far, it adds a method a InputFilter, and a field on the Request. If 
> there's data somewhere, it will return the amount of bytes in that 
> buffer (the available on the input stream will then return 1, since 
> it's not possible to know the exact amount of bytes the servlet can 
> consume). I have no plans to query the socket (it would be more 
> expensive; it's also a task that is done very well in the poller).
got it, we need to document that the available() method should still 
only be called during an "event". If they call available() async 
followed by a read(), it's not gonna be fun when data comes in and the 
poller wakes up as well as the thread that was blocking on the read.

Filip
>
> Rémy
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: dev-help@tomcat.apache.org
>
>
>


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org

Re: Improved available value

[Filip Hanik - Dev Lists <de...@hanik.com>]

Remy Maucherat wrote:
> Filip Hanik - Dev Lists wrote:
>> Remy Maucherat wrote:
>>> Hi,
>>>
>>> I think I would be able to improve the handling of the available 
>>> method (on the input stream) using a new action code. The processors 
>>> will then query the various filters and their own buffer to see if 
>>> there are bytes available somewhere, and the purpose would be to 
>>> clear up the uncertainty which may occur on the first read (if the 
>>> beginning of the entity body was sent along with the request header 
>>> in a single packet). To be refined a little of course.
>> definitely a good idea, I imagine the method has to be implemented 
>> all the way down the chain to eventually return a correct value at 
>> the top of the request.
>
> So far, it adds a method a InputFilter, and a field on the Request. If 
> there's data somewhere, it will return the amount of bytes in that 
> buffer (the available on the input stream will then return 1, since 
> it's not possible to know the exact amount of bytes the servlet can 
> consume). I have no plans to query the socket (it would be more 
> expensive; it's also a task that is done very well in the poller).

ok, I thought about it some more and have a question if this will really 
work
lets say there is a GZIP filter or something like that,
a client sends some data, but not enough to actual unzip the content
in this case, available() would return 1, but there are no bytes for the 
app to read yet, as there isn't enough data to do an unzip
What will happen? Corrupted exception, the thread goes into a blocking read?

Filip

>
> Rémy
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: dev-help@tomcat.apache.org
>
>
>


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org

Re: Improved available value

[Remy Maucherat <re...@apache.org>]

Filip Hanik - Dev Lists wrote:
> Remy Maucherat wrote:
>> Hi,
>>
>> I think I would be able to improve the handling of the available 
>> method (on the input stream) using a new action code. The processors 
>> will then query the various filters and their own buffer to see if 
>> there are bytes available somewhere, and the purpose would be to clear 
>> up the uncertainty which may occur on the first read (if the beginning 
>> of the entity body was sent along with the request header in a single 
>> packet). To be refined a little of course.
> definitely a good idea, I imagine the method has to be implemented all 
> the way down the chain to eventually return a correct value at the top 
> of the request.

So far, it adds a method a InputFilter, and a field on the Request. If 
there's data somewhere, it will return the amount of bytes in that 
buffer (the available on the input stream will then return 1, since it's 
not possible to know the exact amount of bytes the servlet can consume). 
I have no plans to query the socket (it would be more expensive; it's 
also a task that is done very well in the poller).

Rémy

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org

Re: Improved available value

[Filip Hanik - Dev Lists <de...@hanik.com>]

Remy Maucherat wrote:
> Hi,
>
> I think I would be able to improve the handling of the available 
> method (on the input stream) using a new action code. The processors 
> will then query the various filters and their own buffer to see if 
> there are bytes available somewhere, and the purpose would be to clear 
> up the uncertainty which may occur on the first read (if the beginning 
> of the entity body was sent along with the request header in a single 
> packet). To be refined a little of course.
definitely a good idea, I imagine the method has to be implemented all 
the way down the chain to eventually return a correct value at the top 
of the request.

Filip
>
>
> Rémy
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: dev-help@tomcat.apache.org
>
>
>


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org