> After 40 minutes uptime, there are already 60 MB LinkedBlockingQueue
> $Node. The stacktrace is the following
>
> SelectorThread-80
> at sun.nio.ch.EPollArrayWrapper.epollWait(JIJI)I (Native Method)
> at sun.nio.ch.EPollArrayWrapper.poll(J)I (EPollArrayWrapper.java:215)
> at sun.nio.ch.EPollSelectorImpl.doSelect(J)I
> (EPollSelectorImpl.java:65)
> at sun.nio.ch.SelectorImpl.lockAndDoSelect(J)I (SelectorImpl.java:69)
> at sun.nio.ch.SelectorImpl.select(J)I (SelectorImpl.java:80)
> at
> com.sun.enterprise.web.connector.grizzly.SelectorThread.doSelect()V
> (SelectorThread.java:1410)
> at com.sun.enterprise.web.connector.grizzly.SelectorThread.startListener
> ()V (SelectorThread.java:1325)
> at com.sun.enterprise.web.connector.grizzly.SelectorThread.startEndpoint
> ()V (SelectorThread.java:1288)
> at com.sun.enterprise.web.connector.grizzly.SelectorThread.run()V
> (SelectorThread.java:1264)
> btw, we have cometSupport enabled on this SelectorThread, but the
> error appears on the admin-listener, too.
Is this stacktrace, where LinkedBlockingQueue$Nodes are getting
created? I guess, not :)
If you use comet - it looks like you don't either resume or cancel
comet tasks, so they keep growing, but for sure it's just a guess.
Can you pls. create a simple comet application, where you're able to
reproduce the leak?
Thanks.
WBR,
Alexey.
> [Message sent by forum member 'kimschneider']
>
> http://forums.java.net/jive/thread.jspa?messageID=394407
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_glassfish.dev.java.net
> For additional commands, e-mail: users-help_at_glassfish.dev.java.net
>