Jetty Cometd 6.1.14 performance

[Nancy]

We’ve been doing performance/stress testing on Jetty’s cometd 6.1.14
for our project on Linux Box. We observed that when we test the
deliver feature of cometd - for eg - have 5000 HTTP bayeux clients
connecting/subscribing(on different box) to the Jetty cometd server
and the server delivering to these clients at 3000notification/second.
(Here, for performance testing- we deliver the same message to all the
clients on same channel) - the jvm on server side goes out of java
heap space after running for 20-24 hours.

The parameters we had:

In jetty.xml:
maxThreads: 500
maxIdleTime:2000000000
lowResourcesConnections:50000000000
lowResourcesMaxIdleTime:50000000000

In web.xml
timeout:12000000
maxInterval:100000000

We increased the maxIdleTime, lowResourcesConnections and
lowResourcesMaxIdleTime to support that many connections. We wanted to
know if this would be a right approach.

We faced the problem of clients disconnecting when we had default/
lower numbers for timeout and maxInterval. So we played around with it
little bit and increasing those params resolved the issue.

After this analysis - we are not able to figure out why the memory
goes out of bound or is it something related to huge numbers for the
params in jetty.xml and web.xml?

We ddebugged a little bit further by using Jprobe/Jmap/Memory
analyser - such tools to dig down to whats taking up the memory -seems
like it is caching the messages - and MessageImpl class has the
highest number of instances - is it a normal behavior? Is there a way
to get rid of caching the messages?

[Greg Wilkins]

Nancy,

I believe there was a memory leak in some aspects of the cometd
for 6.1.14. Can you try the 6.1.18 release?

Alternately, the cometd 1.0.beta9 release that will come out later
today should work on 6.1.14 and I don't believe will suffer
from the leak.

cheers