activemq-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "james strachan (JIRA)" <j...@apache.org>
Subject [jira] Resolved: (AMQ-932) Quickly broken client connections lead to memory leaks
Date Mon, 25 Sep 2006 11:23:23 GMT
     [ https://issues.apache.org/activemq/browse/AMQ-932?page=all ]

james strachan resolved AMQ-932.
--------------------------------

    Fix Version/s: 4.1
       Resolution: Fixed

Patch applied John with thanks - could you double check I've applied it correctly please?

> Quickly broken client connections lead to memory leaks
> ------------------------------------------------------
>
>                 Key: AMQ-932
>                 URL: https://issues.apache.org/activemq/browse/AMQ-932
>             Project: ActiveMQ
>          Issue Type: Bug
>          Components: Broker
>    Affects Versions: 4.0.2
>            Reporter: John Heitmann
>             Fix For: 4.1
>
>         Attachments: 73.diff
>
>
> Connections to the openwire port that are pathologically broken (for example any http
request) or that die in some other way extremely quickly will lead to memory losses of aout
64Kb each time. This happens because many services are stop()ed directly in the middle of
start(), and then never stopped for real, or stopped again but on an object tree with an inconsistent
state. This is usually also accompanied by the JMX message:
> WARN  ManagedTransportConnection     - Failed to unregister mbean: org.apache.activemq:BrokerName=localhost,Type=Connection,ConnectorName=default,Connection=25
> But that is a cosmetic symptom and not critical (and this has otherwise nothing to do
with JMX).
> My patch is a band-aid that is functional but I'm not very happy with it. The patch changes
some service logic so that if stop is called in the middle of start, the stop is instead queued
and called at the end of start. There will still be multiple stops, and you'll still see the
cosmetic JMX error from the second ineffectual stop, but the first stop cleans up correctly
so there are no leaks.
> I think there's probably a better solution, but it was tough to see what. I'd appreciate
better ideas. Possibly something involving moving the dangerous operations (wire format negotiation
etc) out of start?
> I am working on a unit test, but I can't promise I will have something to submit. I'm
having to play JVM games to detect the problem in a unit test and that might not fly for general
purpose use.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/activemq/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

Mime
View raw message