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
>
--
http://www.spectrumdt.com
http://codepimps.org