activemq-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Hiram Chirino (JIRA)" <>
Subject [jira] [Commented] (APLO-160) Apollo becoming unresponsive when stressed with 48k connections.
Date Wed, 02 May 2012 15:38:48 GMT


Hiram Chirino commented on APLO-160:

Hi Lionel,

Regarding the connection timeout issues: How's the CPU usage looking on the box?  If it's
near the max, some folks might actually consider that a feature.  They would rather have new
connections timeout rather than allowing the connection so that clients can have an option
of switching to another box which is less heavily loaded.

But yeah APLO-163 is still on the roadmap :)
> Apollo becoming unresponsive when stressed with 48k connections.
> ----------------------------------------------------------------
>                 Key: APLO-160
>                 URL:
>             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 | | 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:!default.jspa
For more information on JIRA, see:


View raw message