I just had and overcame this very same issue. What I did was rather than sending multipe responses per request I concatenated them into one string and parsed on the client. I presume this problem occurs when you try to preform multiple flushes?
Sent from my iPhone
On Mar 23, 2009, at 2:11 PM, Jeanfrancois Arcand <Jeanfrancois.Arcand_at_Sun.COM> wrote:
Salut,
gustav trede wrote:
so your overwhelming the log at info level from the onEvent method, all cometworker threads are waiting inside the logger.
Indeed! Adding Carla to the thread as she might now why:
CometWorker-7" daemon prio=6 tid=0x075c9400 nid=0x2198 waiting on condition [0x0fc8f000..0x0fc8fc68]
java.lang.Thread.State: WAITING (parking)
at sun.misc.Unsafe.park(Native Method)
- parking to wait for <0x1c8b3988> (a java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)
at java.util.concurrent.locks.LockSupport.park(LockSupport.java:158)
at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:1925)
at java.util.concurrent.ArrayBlockingQueue.put(ArrayBlockingQueue.java:252)
at com.sun.enterprise.server.logging.GFFileHandler.publish(GFFileHandler.java:509)
at java.util.logging.Logger.log(Logger.java:472)
at java.util.logging.Logger.doLog(Logger.java:494)
at java.util.logging.Logger.log(Logger.java:517)
at java.util.logging.Logger.info(Logger.java:1036)
at com.bcs.mm.model.EventSubscriber.onEvent(EventSubscriber.java:99)
at com.sun.grizzly.comet.concurrent.DefaultConcurrentCometHandler.EnQueueEvent(DefaultConcurrentCometHandler.java:152)
at com.sun.grizzly.comet.DefaultNotificationHandler.notify0(DefaultNotificationHandler.java:179)
at com.sun.grizzly.comet.DefaultNotificationHandler$2.run(DefaultNotificationHandler.java:142)
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:885)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:907)
at java.lang.Thread.run(Thread.java:619)
I don't think this is a bug in Grizzly IMO, but a problem with the logger in GlassFish (hence the micro benchmark we have in Grizzly cannot catch it).
Thanks!
-- Jeanfrancois
2009/3/23 felixx <dolaru_at_sympatico.ca <mailto:dolaru_at_sympatico.ca>>
File attached, thanks.
felixx wrote:
>
> GF V3 build 41, Win Vista, Java HotSpot(TM) Server VM (10.0-b19) for
> windows-x86 JRE (1.6.0_05-b13);
> Simple Comet test scenario: 100 java streaming clients connected
to the
> same Comet context, 1 event is posted to the context every second.
> Works fine for approx 50-60 seconds then the server hangs. Nothing is
> pushed to the clients anymore, no request is served on 8080 or 4848
> (tested via browser), the server is dead.
> Looks like a random/race condition.
>
>
http://www.nabble.com/file/p22664213/stack.txt stack.txt
--
View this message in context:
http://www.nabble.com/Grizzly-Comet-GF-V3-hangs-tp22663593p22664213.html
Sent from the Grizzly - Users mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe_at_grizzly.dev.java.net
<mailto:users-unsubscribe_at_grizzly.dev.java.net>
For additional commands, e-mail: users-help_at_grizzly.dev.java.net
<mailto:users-help_at_grizzly.dev.java.net>
--
regards
gustav trede
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe_at_grizzly.dev.java.net
For additional commands, e-mail: users-help_at_grizzly.dev.java.net