users@grizzly.java.net

(Comet) Re: Handle of the end of request

From: Jeanfrancois Arcand <Jeanfrancois.Arcand_at_Sun.COM>
Date: Mon, 07 Jul 2008 11:11:11 -0400

Salut,

(cross posting to users_at_grizzly as there might be interest).

Mimoun Laurent wrote:
> Hello all,
>
> about the comet and java nio architecture model, I read here :
> http://weblogs.java.net/blog/jfarcand/archive/2005/06/grizzly_an_http.html
> that one never cannot when the request has send all the data.

What I was trying to explain at that time (that was my first blog
ever...hum :-)) is with NIO, you are not guarantee to have all your
message's bytes when you do a socketChannel.read() operation.


>
> So the program has to make assumptions that lead to a "not null
> probability" to miss some request data.

Not miss, but you might have to register back your SelectionKey to the
Selector object so when the missing bytes arrive, you can red them.


Is now this probability value as
> small as, for exemple the probability that the data of a multipart
> request to contain the pseudo-random separator of the request parts ?

Yes that can be used. You can also try to parse the headers and as as
soon as you have found the content-length header, you can predict the
number of bytes you are looking at. Take a look at [1] for an example.

>
> Could you tell me more about this problem and how it is handle now in
> the glassfish architecture ?

In Grizzly (GlassFish sub project), we are using a Temporary Selector
trick[2] to make sure we are reading all the bytes when processing the
request.

Hope that help.

-- Jeanfrancois

[1]
https://grizzly.dev.java.net/nonav/xref/com/sun/grizzly/http/algorithms/ContentLengthAlgorithm.html
[2]
http://weblogs.java.net/blog/jfarcand/archive/2006/07/tricks_and_tips_4.html


>
> Thx
>
> Jreeman
>
>
>
> ------------------------------------------------------------------------
> Discutez gratuitement avec vos amis en vidéo ! Téléchargez Messenger,
> c'est gratuit ! <http://www.windowslive.fr/majmessenger.asp>