users@grizzly.java.net

Re: Problems with pipelining requests

From: Patrick Julien <pjulien_at_gmail.com>
Date: Mon, 15 Dec 2008 13:02:31 -0500

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.


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

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



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