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
>>
>
>
>