Hi Patrick,
can you pls. try to reproduce the same issue with Java SE Sockets and
send me the testcase?
One more question... By pipelining you mean, that you send 10 HTTP
requests in a row and only then start to listen for responses?
Did you try usual request-response strategy? Does it work?
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
>