Salut,
Jussi Kuosa wrote:
>
> Hello Jean-Fracois,
> we're experiencing the same issues as Czarek after we moved to v2.1-b60e
> cluster running on windows 2003 R2 standard edition servers (due to the
> comet selector spin problem...).
OK that one is now fixed with grizzly-1.0.30-SNAPSHOT:
http://download.java.net/maven/2/com/sun/grizzly/grizzly-framework-http/1.0.30-SNAPSHOT/
You just need to reference the jar in domain.xml:
<java-config
classpath-prefix="grizzly-framework-http-1.0.30-SNAPSHOT.jar" .../>
>
> I created a simple web app with a test servlet that uses comet for sending
> down the response in two parts (onInitialize and onTerminate/onInterrupt)
> based on the CometServlet example in GF source package. Loading that with
> httperf gave no problems :-/
>
> However, on our production system our native clients (C++ and Python) are
> occasionally experiencing very long lockups (thousands of seconds, if
> timeout is disabled), as bayeux CONNECTs are not properly terminated when
> there is nothing to send. We also frequently call onEvent from a JMS
> onMessage handler that in turn is our cluster event distribution mechanism.
>
> The CONNECT request is sent to the server in two TCP segments and both are
> acknowledged, so from TCP/IP point of view everything should be ok. Adding
> logging to the onTerminate and onInterrupt handlers reveled that they are
> not called at all when the clients lock up (or start receiving timeouts -
> currently 3*advice).
>
>> Thanks I will take a look. Yes I recall we have added better support for
>> onTerminate.
>
> I will happily test if you have a patch available and provide more details
> if needed.
Thanks. I clearly can't reproduce the issue. Can you try 1.0.30 and let
me know?
Thanks!
-- jeanfrancois
>
> Best regards,
>
> Jussi Kuosa
>