On Dec 15, 2008, at 19:33 , Patrick Julien wrote:
> On Mon, Dec 15, 2008 at 1:06 PM, Jeanfrancois Arcand
> <Jeanfrancois.Arcand_at_sun.com> wrote:
>> Salut,
>
>
> <snip/>
>
>> Just to be sure, is it a regression? Grizzly 1.0 doesn't supports
>> HTTP
>> Pipelining so unless you read the body, grizzly will blocks waiting
>> for that
>> body to be read until the next request gets parsed.
>>
>> Comet could be used as that one support http pipelining, although I
>> suspect
>> we might have issues.
>>
>
> I'm not exactly sure what you're talking about here.
>
> Are you saying Grizzly 1.0 is the one found in Glassfish v2 ur2?
Oh, sorry. We didn't understand each other here.
It's just possible to use plain Grizzly as container for Jersey
(without Glassfish), and I thought by embedded Grizzly you meant that.
> I do read the body, I can see the chunked encoded gzip blocks. As I
> said, I can read usually read the first 2 to 4 responses then a long
> blocking read waiting for bytes from the client followed by a
> connection close.
May be it succeeded just until messages were read one by one without
intersections. But once server read a buffer, which contained let's
say 1.5 message - it may get confused.
> Or are you saying Grizzly in this Glassfish release doesn't support
> HTTP pipelining? Because it does respond to HTTP 1.1 requests versus
> setting 1.0 for the version. I had assume that because of this, it
> would support pipelining since it's a mandatory feature of HTTP 1.1.
As Jeanfrancois said, it could be supported via comet.
Jeanfrancois, can you pls. provide more details on that?
Thank you.
WBR,
Alexey.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_grizzly.dev.java.net
> For additional commands, e-mail: users-help_at_grizzly.dev.java.net
>