Hi John,
John C. Turnbull wrote:
> Hi Jeanfrancois,
>
> I have discovered that when the problem occurs, there is no interrupt
> detected so it would appear that the connection is still open (which
> correlates with the fact that there are no EOF exceptions at either end).
Just in case, are you inside a firewall or a proxy? Can it be the proxy
that close the connection (I suspect not).
>
> Hmm, so where do I go from here? The connection remains open but no data is
> getting through.
From your CometHandler, invoking the
HttpServletResponse.getWriter().write(...) succeed, right? I guess you
should install wireshark or ngrep to see if the bytes are sent properly.
This way we will know if the client or server has problems.
Thanks
-- Jeanfrancois
>
> Thanks,
>
> John
>
>> -----Original Message-----
>> From: Jeanfrancois.Arcand_at_Sun.COM [mailto:Jeanfrancois.Arcand_at_Sun.COM]
>> Sent: Wednesday, 23 January 2008 03:37
>> To: users_at_grizzly.dev.java.net
>> Subject: Re: Comet data into the bit bucket
>>
>> Hi John,
>>
>> John C. Turnbull wrote:
>>> Hi Jeanfrancois,
>>>
>>> Thanks for your reply. Comments inline.
>>>
>>>>> I have Comet working nicely between servlets and applets except for
>>>> one
>>>>> thing.
>>>> Great!
>>> [JCT] Yes, indeed. I am very happy with Grizzly Comet :-)
>>>
>>>> For some reason, if a connection is left idle for several
>>>>> minutes then the data sent from the servlet seems to disappear into
>>>> the
>>>>> ether somewhere.
>>>> Do you know how long exactly?
>>> [JCT] Not exactly but it's about 10 minutes.
>>>
>>>> Do you have a test case I can take a look at? Do you know if the
>>>> connection is still active (are you handling the
>>>> onInterrupt/onTerminate
>>>> method of the CometHandler)?
>>> [JCT] It is difficult to provide a test case at this stage but I can
>> say
>>> that I am not doing anything with onInterrupt or onTerminate yet as I
>> am not
>>> sure how these methods should be used. Is there documentation for
>> Comet
>>> somewhere? I mean something that gives a general outline of how
>> everything
>>> hangs together? It's a bit hit-or-miss for me at the moment and I am
>>> finding things out by experimentation.
>> That's the general problem with Grizzly...lack of documentations. The
>> only place I talk about it is here:
>>
>> http://weblogs.java.net/blog/jfarcand/archive/2006/07/the_grizzly_com.h
>> tml
>> https://grizzly.dev.java.net/nonav/xref/com/sun/grizzly/comet/CometHand
>> ler.html
>>
>> which is far from perfect. Mainly, the onInterrupt will be called by
>> Grizzly when the client close the connection or when the timeout
>> expires. The onTerminate will be called when you invoke
>> CometContext.notify(CometEvent.TERMINATE);
>>
>>>>> Any ideas what's actually happening here and where the data is
>> going?
>>>> Difficult to say. Are they any exceptions in the log (I guess not).
>> Do
>>>> you know if the bytes are sent over the network? A tool like
>> wireshark
>>>> or ngrep could help determining if the server or the client have
>>>> problem.
>>> [JCT] I haven't used a packet sniffer to analyse the network yet but
>> I do
>>> know that the server "believes" that the data has been transmitted as
>> the
>>> DataOutputStream#size() method is reporting an ever-increasing number
>> of
>>> transmitted bytes as the data is written and there are no exceptions.
>>>
>>> [JCT] So perhaps the problem has something to do with the fact that I
>> am not
>>> properly handling the interrupt or terminate events in the
>> CometHandler but
>>> I still don't know where the data is ending up. When I get a chance
>> I will
>>> do some sniffing around for packets and try to see exactly what is
>> going on.
>>> [JCT] But, as I said, this is the only outstanding issue I have with
>> my
>>> usage of Comet.
>> OK let's work on that :-) First thing to try is to output some trace
>> inside the onInterrupt to see if that method gets invoked.
>>
>> Thanks!
>>
>> -- Jeanfrancois
>>
>>> Thanks,
>>>
>>> -JCT
>>>
>>> ---------------------------------------------------------------------
>>> 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
>