> Patrick Julien wrote:
>> On Mon, Dec 15, 2008 at 12:51 PM, Oleksiy Stashok
>> <Oleksiy.Stashok_at_sun.com> wrote:
>>> Hi Patrick,
>>>
>>> can you pls. try to reproduce the same issue with Java SE Sockets
>>> and send
>>> me the testcase?
>> I can, but if I would just know how to enable logging in the embedded
>> copy of grizzly, that would help too.
Jersey embedded Grizzly is different version than one, integrated to
GFv2. So, it may not help.
BTW, did you try the same usecase on the embedded Grizzly?
>>> One more question... By pipelining you mean, that you send 10 HTTP
>>> requests
>>> in a row and only then start to listen for responses?
>> Correct, as in HTTP 1.1 pipelining
>>> Did you try usual request-response strategy? Does it work?
>>>
>> Yes, it was like this before and yes it does. Furthermore, I can
>> correctly use the same connection for multiple requests just as long
>> as I read the response before sending another request, I currently
>> have no need to close the socket at all.
>
> Just to be sure, is it a regression? Grizzly 1.0 doesn't supports
> HTTP Pipelining so unless you read the body, grizzly will blocks
> waiting for that body to be read until the next request gets parsed.
I agree it's not the issue I originally thought about.
And if Grizzly 1.0 doesn't support pipelining, it means GFv2 doesn't
support it either.
> Comet could be used as that one support http pipelining, although I
> suspect we might have issues.
Agree.
WBR,
Alexey.
>
>
> A+
>
> -- Jeanfrancois
>
>
>>> Thanks.
>>>
>>> WBR,
>>> Alexey.
>>>
>>>> Yep, the connection stays idle for about 30 seconds before it dies.
>>>>
>>>> On Mon, Dec 15, 2008 at 12:25 PM, Patrick Julien
>>>> <pjulien_at_gmail.com>
>>>> wrote:
>>>>> I am using a full distribution of Glassfish v2 ur2.
>>>>>
>>>>> I haven't timed the connection to see if it's some 30 seconds or
>>>>> not.
>>>>> All I know is that traffic on this connection completely stops. I
>>>>> will time it now.
>>>>>
>>>>> On Mon, Dec 15, 2008 at 12:21 PM, Oleksiy Stashok
>>>>> <Oleksiy.Stashok_at_sun.com> wrote:
>>>>>> Hi Patrick,
>>>>>>
>>>>>> can you pls. provide more details on the server part.
>>>>>> Are you using Glassfish, or standalone Grizzly with Jersey.
>>>>>> If it's Glassfish, which version it is?
>>>>>>
>>>>>> Looks like this is the same issue we fixed recently [1].
>>>>>> Connection got
>>>>>> closed after 30 seconds, because by mistake it was counted as
>>>>>> idle.
>>>>>> Please provide the details, and I'm sure we'll solve that fast.
>>>>>>
>>>>>> Thanks.
>>>>>>
>>>>>> WBR,
>>>>>> Alexey.
>>>>>>
>>>>>> [1] http://www.nabble.com/Need-help-on-ARP-usage-td20789925.html
>>>>>>
>>>>>>> My mobile application consumes REST services from Glassfish/
>>>>>>> Jersey.
>>>>>>>
>>>>>>> In order to optimize bandwidth and minimize wait times for the
>>>>>>> user, I
>>>>>>> have been progressively implementing HTTP 1.1 support in Java
>>>>>>> ME using
>>>>>>> only a SocketConnection. So far, I have gotten gzip encoding
>>>>>>> and a
>>>>>>> persistent connection to work.
>>>>>>>
>>>>>>> However, I am unable to reliably pipeline requests. I am
>>>>>>> unsure what
>>>>>>> I am doing wrong here but it seems after 2 to 4 responses, the
>>>>>>> connection is closed on the server. My main problem however
>>>>>>> is that
>>>>>>> Glassfish/Grizzly log absolutely nothing about what is going on.
>>>>>>>
>>>>>>> The sequence usually is this:
>>>>>>>
>>>>>>> 1. Send 10 requests
>>>>>>> 2. Read back and process between 2-4 responses
>>>>>>> 3. Long blocking read
>>>>>>> 4. Read times out/connection closed
>>>>>>> 5. Glassfish log file has nothing in it
>>>>>>>
>>>>>>> My question is this: Is there some obscure option here that I
>>>>>>> could
>>>>>>> turn on that could provide insight into this problem? If I
>>>>>>> could see
>>>>>>> the traffic that Grizzly is generating and the reason why it's
>>>>>>> closing
>>>>>>> the connection, this would be of great value to me. Setting log
>>>>>>> levels to FINEST in the glassfish consoles produces nothing of
>>>>>>> value
>>>>>>> either.
>>>>>>>
>>>>>>> thank you,
>>>>>>>
>>>>>>> --
>>>>>>> http://www.spectrumdt.com
>>>>>>> http://codepimps.org
>>>>>>>
>>>>>>> ---------------------------------------------------------------------
>>>>>>> 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
>>>>>
>>>>
>>>>
>>>> --
>>>> http://www.spectrumdt.com
>>>> http://codepimps.org
>>>>
>>>> ---------------------------------------------------------------------
>>>> 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
>