Salut,
FredrikJ wrote:
> Hi. I am using the default Grizzly and Comet implementation provided in
> Glassfish 2.1. I have been testing some different usage scenarios lately
> and I am running into what seems like a concurrency problem in the
> implementation. The scenario is like this (some kind of pseudo-code
> below): *http-thread:* /int handlerId =
> cometContext.addCometHandler(handler); Worker work = new Worker(job,
> handlerId); workManager.scheduleWork(work);/ *work-thread (run method):*
> /Object result = doJob(); cometContext.notify(result, CometEvent.NOTIFY,
> handlerId);/ The Come Handler will react to notifications and send the
> job result to the response outputstream hold in the handler. During
> normal execution this works like a champ, work is hand-off to dedicated
> thread pools, depending on the type of work, and then reported back to
> the requester which perceives the whole event as a synchronous event,
> which is exactly what we want. The problem started to occur when I added
> fail-fast scenarios. If instead of executing the job, which will take
> some time since we at least will make a database lookup, we raise an
> exception due to some condition the service randomly fails to send a
> response. After some trial and error it seems that the problem is only
> caused when we call cometContext.notify(...) fast enough. Introducing an
> artificial delay before calling notify always seems to solve the issue.
> This leads me to the suspicion that the Comet-context is not updated
> atomically and have not propagated properly between memory barriers.
Can you try to synchronize your CometHandler onEvent to see if that help?
public synchronize void onEvent(...);
or do:
CometContext.setBlockingNotification(true);
My
> current work-around is to not use the notification but rather create my
> own CometEvent and then call onEvent(...) direct and synchronously from
> my worker thread. This fixes the notification problem and is workable
> for us since we are fine with executing the output writing on the worker
> thread pool. However, to me it indicates a concurrency problem in the
> Comet implementation and and such it might have other, more hard to
> detect, implications. Is this known/expected behavior?
No you see to have found an issue. A better alternative for you would
consist of writing your own NotificationHandler:
https://grizzly.dev.java.net/nonav/xref/com/sun/grizzly/comet/NotificationHandler.html
See for an example:
http://weblogs.java.net/blog/jfarcand/archive/2007/03/asynchronous_co.html
Mainly, you just do:
CometContext.setNotificationHandler(YourNotificationHandler)
Let me know how it goes.
Thanks!
-- Jeanfrancois
> ------------------------------------------------------------------------
> View this message in context: Grizzly & Comet concurrency issue
> <http://www.nabble.com/Grizzly---Comet-concurrency-issue-tp23197357p23197357.html>
> Sent from the Grizzly - Users mailing list archive
> <http://www.nabble.com/Grizzly---Users-f23249.html> at Nabble.com.