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
>