Mailing-List: contact issues-help@camel.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@camel.apache.org
Date: Sat, 3 Mar 2012 11:22:58 +0000 (UTC)
From: "Claus Ibsen (Updated) (JIRA)" <jira@apache.org>
To: issues@camel.apache.org
Message-ID: 
 <1524420483.17639.1330773778581.JavaMail.tomcat@hel.zones.apache.org>
In-Reply-To: 
 <709117740.12566.1330706277047.JavaMail.tomcat@hel.zones.apache.org>
Subject: [jira] [Updated] (CAMEL-5058) Bug: Unique Endpoints Leaking in
 DefaultInflightRepository
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


     [ https://issues.apache.org/jira/browse/CAMEL-5058?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Claus Ibsen updated CAMEL-5058:
-------------------------------

    Fix Version/s: 2.9.2
                   2.10.0
    
> Bug: Unique Endpoints Leaking in DefaultInflightRepository
> ----------------------------------------------------------
>
>                 Key: CAMEL-5058
>                 URL: https://issues.apache.org/jira/browse/CAMEL-5058
>             Project: Camel
>          Issue Type: Bug
>          Components: camel-core
>    Affects Versions: 2.9.0
>            Reporter: Zach Calvert
>            Assignee: Claus Ibsen
>             Fix For: 2.10.0, 2.9.2
>
>   Original Estimate: 24h
>  Remaining Estimate: 24h
>
> If you have an endpoint protocol which uses unique URIs you will leak Strings in the HashMap stored in the DefaultInflightRepository (org.apache.camel.impl.DefaultInflightRepository)
> It seems there is a reference counting scheme in place, but it doesn't do a remove until the "stop" method is called to shut the system down.  We are running XMPP endpoints, which use a protocol like xmpp://someaccount@domain/password?to=someOtherAccount
> When there are 10 million accounts, not all of which are active, but all of which may message at some time or another, no references are removed to the endpointCount.
> When the count becomes 0, the reference should be removed and the size method will still return the appropriate result.
> Please be careful in the implementation to synchronize on some object (perhaps the AtomicInteger) reflecting a read/write lock on the endpoint count modification.

--
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