users@grizzly.java.net

Re: Problems with pipelining requests

From: Patrick Julien <pjulien_at_gmail.com>
Date: Tue, 16 Dec 2008 18:02:56 -0500

Yes, Glassfish. No comet.

On Tue, Dec 16, 2008 at 5:19 PM, Jeanfrancois Arcand
<Jeanfrancois.Arcand_at_sun.com> wrote:
> Hum that strange as I added read logs. Another try, hopefully that one
> works. You are using GF as it is right? No Comet?
>
>
>
> Patrick Julien wrote:
>>
>> Even with this drop, I do not see any bytes being printed in the log.
>>
>> On Tue, Dec 16, 2008 at 2:24 PM, Jeanfrancois Arcand
>> <Jeanfrancois.Arcand_at_sun.com> wrote:
>>>
>>> Oups again.
>>>
>>> Patrick Julien wrote:
>>>>
>>>> This does not seem to be printing out bytes, you sure I have the right
>>>> package? Or did the procedure change from the first one?
>>>>
>>>> On Tue, Dec 16, 2008 at 1:54 PM, Jeanfrancois Arcand
>>>> <Jeanfrancois.Arcand_at_sun.com> wrote:
>>>>>
>>>>> Salut,
>>>>>
>>>>> Patrick Julien wrote:
>>>>>>
>>>>>> OK, so here's the log, what's interesting here is that I can see that
>>>>>> there is an attempt to handle an OP_READ but that is followed
>>>>>> immediately by a socket close on the server.
>>>>>
>>>>> Looks like there was no bytes available to read. I'm attaching a new
>>>>> patch
>>>>> which will display the bytes read. maybe the client has trouble sending
>>>>> more
>>>>> data?
>>>>>
>>>>> A+
>>>>>
>>>>> -- jeanfrancoois
>>>>>
>>>>>
>>>>>> On Tue, Dec 16, 2008 at 11:56 AM, Jeanfrancois Arcand
>>>>>> <Jeanfrancois.Arcand_at_sun.com> wrote:
>>>>>>>
>>>>>>> My bad. Proper patch attached.
>>>>>>>
>>>>>>> -- Jeanfrancois
>>>>>>>
>>>>>>> Patrick Julien wrote:
>>>>>>>>
>>>>>>>> You sure about these instructions? This jar file only contains a
>>>>>>>> META-INF directory.
>>>>>>>>
>>>>>>>> On Tue, Dec 16, 2008 at 11:10 AM, Jeanfrancois Arcand
>>>>>>>> <Jeanfrancois.Arcand_at_sun.com> wrote:
>>>>>>>>>
>>>>>>>>> Salut,
>>>>>>>>>
>>>>>>>>> I'm attaching the patch which add more logging (let's start with
>>>>>>>>> that
>>>>>>>>> one).
>>>>>>>>> Just do:
>>>>>>>>>
>>>>>>>>> % cd ${glassfish.home}/lib
>>>>>>>>> % unzip grizzly-1.0...
>>>>>>>>> % cp appserv-rt.jar appserv-rt.jar.org
>>>>>>>>> % jar uvf appserv-rt.jar com
>>>>>>>>>
>>>>>>>>> restart and execute your test.
>>>>>>>>>
>>>>>>>>> A+
>>>>>>>>>
>>>>>>>>> -- Jeanfrancois
>>>>>>>>>
>>>>>>>>> Jeanfrancois Arcand wrote:
>>>>>>>>>>
>>>>>>>>>> Salut,
>>>>>>>>>>
>>>>>>>>>> Patrick Julien wrote:
>>>>>>>>>>>
>>>>>>>>>>> On Mon, Dec 15, 2008 at 3:32 PM, Jeanfrancois Arcand
>>>>>>>>>>> <Jeanfrancois.Arcand_at_sun.com> wrote:
>>>>>>>>>>>>
>>>>>>>>>>>> Patrick Julien wrote:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Add
>>>>>>>>>>>>>>> -Dcom.sun.enterprise.web.connector.grizzly.snoopEnabled=true
>>>>>>>>>>>>>>> and
>>>>>>>>>>>>>>> send
>>>>>>>>>>>>>>> the log here. But I doubt you will find http pipelining
>>>>>>>>>>>>>>> support
>>>>>>>>>>>>>>> with
>>>>>>>>>>>>>>> Tomcat
>>>>>>>>>>>>>>> (the parser code here is from them)...I think Jetty might
>>>>>>>>>>>>>>> work,
>>>>>>>>>>>>>>> but
>>>>>>>>>>>>>>> I'm
>>>>>>>>>>>>>>> clearly not sure....
>>>>>>>>>>>>>
>>>>>>>>>>>>> Wait a minute, that doesn't compute for me. Both glassfish and
>>>>>>>>>>>>> Tomcat
>>>>>>>>>>>>> documentation refer to pipelining via the
>>>>>>>>>>>>> "maxKeepAliveRequests"
>>>>>>>>>>>>> property.
>>>>>>>>>>>>>
>>>>>>>>>>>>> You can see it in the documentation of Tomcat here:
>>>>>>>>>>>>>
>>>>>>>>>>>>> http://tomcat.apache.org/tomcat-6.0-doc/config/http.html
>>>>>>>>>>>>>
>>>>>>>>>>>>> and for glassfish, here:
>>>>>>>>>>>>>
>>>>>>>>>>>>> http://docs.sun.com/app/docs/doc/820-4507/abhco?a=view
>>>>>>>>>>>>
>>>>>>>>>>>> OK...http pipelining is not what I means :-) Http pipelining
>>>>>>>>>>>> usually
>>>>>>>>>>>> refer
>>>>>>>>>>>> to the ability to sent multiple requests without waiting for the
>>>>>>>>>>>> response.
>>>>>>>>>>>> So you can send R1,R2,R3 in one chunk and then wait for un
>>>>>>>>>>>> ordered
>>>>>>>>>>>> response.
>>>>>>>>>>>> I was under the impression you were talking about that behavior.
>>>>>>>>>>>
>>>>>>>>>>> Yes, this is what I am talking about. Send 10 requests, then
>>>>>>>>>>> start
>>>>>>>>>>> accepting responses.
>>>>>>>>>>
>>>>>>>>>> OK then the links are not related.
>>>>>>>>>>
>>>>>>>>>>>> What you mean here based on the above link is the maximum number
>>>>>>>>>>>> of
>>>>>>>>>>>> requests
>>>>>>>>>>>> a client can do on an open connection. The client does R1, wait
>>>>>>>>>>>> for
>>>>>>>>>>>> Res1,
>>>>>>>>>>>> then Req2, wait for Req2, etc.
>>>>>>>>>>>
>>>>>>>>>>> No, I really mean sending multiple requests and getting back
>>>>>>>>>>> responses
>>>>>>>>>>> in one shot, if the documentation provided here means something
>>>>>>>>>>> different, than it most certainly fooled me.
>>>>>>>>>>>
>>>>>>>>>>>> Now I understand your issue. I think your request is invalid and
>>>>>>>>>>>> Grizzly
>>>>>>>>>>>> is
>>>>>>>>>>>> waiting for more bytes. Is the snippet you wrote previously
>>>>>>>>>>>> contains
>>>>>>>>>>>> the
>>>>>>>>>>>> entire request? I will try to reproduce the issue using that one
>>>>>>>>>>>> and
>>>>>>>>>>>> telnet.
>>>>>>>>>>>
>>>>>>>>>>> No, as I said before, I am getting 2 to 4 responses then nothing
>>>>>>>>>>> from
>>>>>>>>>>> the 10 requests. Just a long blocking read followed by a
>>>>>>>>>>> disconnect.
>>>>>>>>>>
>>>>>>>>>> Ok let me instrument a patch for you to see what happening. I hope
>>>>>>>>>> I
>>>>>>>>>> don't
>>>>>>>>>> have to drive to see the problem live (at least not today as I
>>>>>>>>>> will
>>>>>>>>>> need
>>>>>>>>>> a
>>>>>>>>>> boat :-)). Gives me 1 hour or so.
>>>>>>>>>>
>>>>>>>>>> A+
>>>>>>>>>>
>>>>>>>>>> -- Jeanfrancois
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>>> A+
>>>>>>>>>>>>
>>>>>>>>>>>> -- jeanfrancois
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> ---------------------------------------------------------------------
>>>>>>>>>>>>> To unsubscribe, e-mail: users-unsubscribe_at_grizzly.dev.java.net
>>>>>>>>>>>>> For additional commands, e-mail:
>>>>>>>>>>>>> users-help_at_grizzly.dev.java.net
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> ---------------------------------------------------------------------
>>>>>>>>>>>> To unsubscribe, e-mail: users-unsubscribe_at_grizzly.dev.java.net
>>>>>>>>>>>> For additional commands, e-mail: users-help_at_grizzly.dev.java.net
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> ---------------------------------------------------------------------
>>>>>>>>>> To unsubscribe, e-mail: users-unsubscribe_at_grizzly.dev.java.net
>>>>>>>>>> For additional commands, e-mail: users-help_at_grizzly.dev.java.net
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> ---------------------------------------------------------------------
>>>>>>>>> To unsubscribe, e-mail: users-unsubscribe_at_grizzly.dev.java.net
>>>>>>>>> For additional commands, e-mail: users-help_at_grizzly.dev.java.net
>>>>>>>>>
>>>>>>> ---------------------------------------------------------------------
>>>>>>> To unsubscribe, e-mail: users-unsubscribe_at_grizzly.dev.java.net
>>>>>>> For additional commands, e-mail: users-help_at_grizzly.dev.java.net
>>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> ------------------------------------------------------------------------
>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>> To unsubscribe, e-mail: users-unsubscribe_at_grizzly.dev.java.net
>>>>>> For additional commands, e-mail: users-help_at_grizzly.dev.java.net
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: users-unsubscribe_at_grizzly.dev.java.net
>>>>> For additional commands, e-mail: users-help_at_grizzly.dev.java.net
>>>>>
>>>>
>>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe_at_grizzly.dev.java.net
>>> For additional commands, e-mail: users-help_at_grizzly.dev.java.net
>>>
>>
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_grizzly.dev.java.net
> For additional commands, e-mail: users-help_at_grizzly.dev.java.net
>



-- 
http://www.spectrumdt.com
http://codepimps.org