users@grizzly.java.net

Re: Again: Problems with pipelining requests

From: Jeanfrancois Arcand <Jeanfrancois.Arcand_at_Sun.COM>
Date: Mon, 12 Jan 2009 10:30:42 -0500

Salut,

wintermute_at_tessierashpool.net wrote:
> Hi users_at_grizzly,
>
> like Patrick Julien in mid december, I'd like to point out that the
> current state of affairs with Grizzly HTTP pipelining is somewhat
> unsatisfactory.
>
> Jean Francois said, back then, that Grizzly simply doesn't support
> pipelining, and I've found a second post in which he states that, quote:
> "We aren't supporting HTTP pipelining as this is not mandatory, and
> messy to implement."
>
> The HTTP 1.1 spec is, however, quite clear about this (section 8.1.2.2):
>
> "A client that supports persistent connections MAY "pipeline" its
> requests (i.e., send multiple requests without waiting for each
> response). A server MUST send its responses to those requests in the
> same order that the requests were received."
>
> I'm sure the RFC would have said "A server MUST only send the response
> to the last of those requests and MAY send the others in between, and if
> so, MUST send them in the same order that the requests were received" --
> if that's what the intention was.
>
> Now, nobody likes specifications that force messy implementations, and I
> wouldn't insist on pipelining as a feature -- but the way it's handled
> right now should be considered a bug.

Can you file an issue here:

https://grizzly.dev.java.net/issues/

if you can attach a test case that demonstrate the issue you are having,
I'm all for producing a patch for GF 2.1 (release next week) and your
current GF version.


Being a practical person, I
> wouldn't mind all this if I could make Grizzly/Glassfish behave in a way
> that clients that do use pipelining can handle.
> IIS, which also doesn't support pipelining, seems to be able to do this,
> or is so common that clients just know that IIS is not fully
> implementing HTTP 1.1 there.
>
> Currently, when using a Glassfish-powered site (try txtr.com) with a
> client that has pipelining enabled (most Opera versions out there, for
> instance), things are just badly broken.

I would really like to see your server.log to understand what's exactly
broken.


>
> Is there a way to tell clients not to use pipelining that I'm not aware
> of? Or should this be fixed in Grizzly? (Maybe responding to the first
> request and then closing the connection when a second one comes in
> without the first one fully answered would be a hotfix -- better than
> quietly doing the wrong thing, anyway?)

Might be. But if we start working on the features, let's just implement
it properly without hack. Like I said, I can take a look if you can give
me an example. I did try opera (OS X) and I can't see anything wrong.

Thanks

-- Jeanfrancois


>
> Thanks for listening & have a nice weekend everybody,
>
> rv
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_grizzly.dev.java.net
> For additional commands, e-mail: users-help_at_grizzly.dev.java.net
>