Hi All,
I've been looking and reproducing a comet context timeout issue for the
last while.
I'm pretty convinced for now its an issue on our side. We're running
basically a Cometd setup. Everything works nicely handshake's,
subscribes, connects and so forth.
Everything until that is the server instigates a push. We get an inbound
JMS message that eventually ends up calling:
cometContext.notify(thunderEvents);
This end up calling:
CometContext.notify(final E attachment,final int eventType)
This calls our custom notification handler which call the
PushDataHandler which is our custom component to push the data to the
connected clients.
Again works nicely.
Afterwards resets the idle timeouts.
Problem is everything gets dead locked when multiple clients come
online. We've seen when we built in message persistence for offline or
idling(graceful backoff) clients as we increase load. Many clients wait
non deterministic amounts of time before getting any form of a
response.
Blocking notifications don't see to do the trick since then Cometd fails
to work, handers are sometimes returned, sometimes not.
I'm wondering does this, reset mean blocked threads end up idling for an
indefinite period of time.
I'll look at putting some throttling logic within our notification
handler, but I think that a workaround.
Kind Regards,
James
On Mon, 2009-07-06 at 08:16 -0700, Czarek Zadorocki wrote:
> Salut!
>
> I'm using glassfish v2.1 b60e.
> The class file org/quartz/Scheduler.class is included in
> SampleComet.ear/lib/quartz-1.6.4.jar.
> No changes except following classpath-prefix addition have been made:
> <java-config
> classpath-prefix="d:/java/app-servers/glassfish-v2.1-b60e/glassfish/lib/ext/grizzly-framework-http-1.0.30-SNAPSHOT.jar"
>
> Thanks
> Czarek