[
https://issues.apache.org/jira/browse/AMQ-9546?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Christopher L. Shannon closed AMQ-9546.
---------------------------------------
Resolution: Not A Problem
256 megs is still a huge amount of memory considering that setting is the max
size allowed for all open wire packets. Normally that setting would be used to
set a maximum message size and as you can imagine it would not take many
messages of that size to run out of memory. In your case it looks like the
security scanner is just sending misformed data that Openwire trying to parse
and its getting size values that are very large and creating large buffers for
those packets so it wouldn't take much to blow memory if you are allowing the
creation of 256 meg buffers.
> Potential direct buffer memory leak triggered by security scan
> --------------------------------------------------------------
>
> Key: AMQ-9546
> URL: https://issues.apache.org/jira/browse/AMQ-9546
> Project: ActiveMQ Classic
> Issue Type: Bug
> Components: Broker
> Affects Versions: 5.18.3
> Environment: Linux version 4.12.14-122.216-default
> (gcc version 4.8.5 (SUSE Linux) )
> Tomcat: 9.0.86
> ActiveMQ: 5.18.3
> Reporter: Eddie Wu
> Priority: Major
>
> We encountered following WARN log from Active MQ 5.18.3. which is embed in
> Tomcat 9.0.86.
> {noformat}
> WARN [Transport] Transport Connection to tcp://xxxx:yyyy failed: Cannot
> reserve 1195725860 bytes of direct buffer memory (allocated: 909477781,
> limit: 1073741824){noformat}
> {{tcp://xxxx:yyyy}} is our security scan software.
> We realize that the security scan software will trigger direct buffer memory
> leak from ActiveMQ.
> # We have internal metrics for direct buffer memory usage. It is clear that
> direct buffer usage will spike when scanning happened.
> # We have log as above to know that the scan did cause ActiveMQ to allocate
> huge direct buffer memory.
> Even though the leak is NOT triggered by usual business code, I think it is
> still worth to fix.
> Anyway it is a potential memory leak bug inside ActiveMQ.
> I have not get call stack yet. but since the code using direct buffer is NOT
> that much, maybe you can review the code to figure out the root cause of
> memory leak.
> Let me know if you need more details.
> --just for your information, per our initial check, the log above was from
> code below.
> [https://github.com/apache/activemq/blob/74086d70bcf2db9ef98e3699c1bf1eb5910c2baa/activemq-broker/src/main/java/org/apache/activemq/broker/TransportConnection.java#L1188]
>
> {code:java}
> @Override
> public String toString() {
> return "Transport Connection to: " + transport.getRemoteAddress();
> }
> public void serviceTransportException(IOException e) {
> if (!stopping.get() && status.get() != PENDING_STOP) {
> transportException.set(e);
> if (TRANSPORTLOG.isDebugEnabled()) {
> TRANSPORTLOG.debug("{} failed: {}", this, e.getMessage(), e);
> } else if (TRANSPORTLOG.isWarnEnabled() && !suppressed(e)) {
> if (connector.isDisplayStackTrace()) {
> TRANSPORTLOG.warn("{} failed", this, e);
> } else {
> TRANSPORTLOG.warn("{} failed: {}", this, e.getMessage());
> }
> }
> stopAsync(e);
> }
> }{code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
For further information, visit: https://activemq.apache.org/contact
