You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@activemq.apache.org by "Christopher L. Shannon (Jira)" <ji...@apache.org> on 2024/08/08 12:19:00 UTC

[jira] [Commented] (AMQ-9546) Potential direct buffer memory leak triggered by security scan

    [ https://issues.apache.org/jira/browse/AMQ-9546?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17871977#comment-17871977 ] 

Christopher L. Shannon commented on AMQ-9546:
---------------------------------------------

Most likely the issue is you need to just set {{maxFrameSize }}to prevent OOM {{issues}} as the scanning is not sending proper OpenWire packets.  See [https://activemq.apache.org/components/classic/documentation/configuring-wire-formats]

 

> 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.
> WARN  [Transport] Transport Connection to tcp://xxxx:yyyy failed: 
> Cannot reserve 1195725860 bytes of direct buffer memory 
> (allocated: 909477781, limit: 1073741824)
> tcp://xxxx:yyyy is our security scan software.
> We realize that the security scan software will trigger direct buffer memory leak from Active MQ.
> 1. we have internal metrics for direct buffer memory usage, it is clear that direct buffer usage will spike when scanning happened.
> 2. we have log as above to know that the scan did cause Active MQ 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 Active MQ.
> 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] 
>  
>     @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);
>         }
>     }



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscribe@activemq.apache.org
For additional commands, e-mail: issues-help@activemq.apache.org
For further information, visit: https://activemq.apache.org/contact