I use AbstractBlockingQueue because I want to write to a queue quickly
and not wait for messages to be written to a file before returning. The
queue gets emptied as time permits. If there are a lot of messages
written to the queue and it can not be emptied quickly enough the queue
starts to fill up. When the queue is full I use a 'put' to add to the
queue which is a blocking call and will not add to the queue until
something is removed (written to a file in this case).
One thing I was planning on doing is to make the queue size configurable
but really that can just delay the problem. Another is to take multiple
messages off the queue with each 'take' operation. This can help but if
there is a lot of traffic you will see things slow down until that queue
can be emptied.
As I mentioned this mechanism as been in Prelude for some time. Is this
a new test? Did it work in the Prelude release as the queue size is the
same.
I'm investigating if some other configuration property is causing
problems with removing things from the queue.
Carla
Richard Corsale wrote:
> 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>