[
https://issues.apache.org/jira/browse/APLO-160?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13264961#comment-13264961
]
Hiram Chirino commented on APLO-160:
------------------------------------
Hi Lionel,
Several changes have recently been added which should help keep memory levels
down in large connection scenarios:
r1332222 Producers were holding on to large 64k buffers needlessly.
r1331585 keep it simple. copy all the subscribe headers.
r1331577 Deep copy the subscription id to avoid holding onto a large buffer.
r1331565 Use smarter buffer pooling in the StompCodec so that idle connections
don't hog memory resources.
r1331491 Don't initialize the read/write buffers until we know what size to
make them.
r1331470 Use the new transport aware interface of hawtdispatch to more reliably
figure out the read/write buffer sizes for the stomp codec.
Please try out a new nightly SNAPSHOT, you should see a much improved memory
profile.
> Apollo becoming unresponsive when stressed with 48k connections.
> ----------------------------------------------------------------
>
> Key: APLO-160
> URL: https://issues.apache.org/jira/browse/APLO-160
> Project: ActiveMQ Apollo
> Issue Type: Bug
> Environment: apollo-1.1-20120209.032648-24
> Reporter: Lionel Cons
> Assignee: Hiram Chirino
> Fix For: 1.3
>
> Attachments: apollo.dump
>
>
> While running a stress test against apollo-1.1-20120209.032648-24 (many
> concurrent TCP connections), the broker became unresponsive.
> It logged several times: java.lang.OutOfMemoryError: GC overhead limit
> exceeded
> It also logged other warnings, probably related:
> 2012-02-14 14:14:49,273 | WARN | handle failed | org.eclipse.jetty.io.nio |
> Apollo Task
> 2012-02-14 14:18:39,073 | WARN | Problem scavenging sessions |
> org.eclipse.jetty.server.session | HashSessionScavenger-0
> It could not be stopped either, I had to kill -9 it.
> What can be done to avoid these problems?
> FWIW, java has been started with -server -Xmx8192m -Xms4096m
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
