camel-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Claus Ibsen (Commented) (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (CAMEL-5058) Bug: Unique Endpoints Leaking in DefaultInflightRepository
Date Sat, 03 Mar 2012 11:22:58 GMT

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

Claus Ibsen commented on CAMEL-5058:
------------------------------------

The inflight registry should be route based instead of endpoint, as that is what the graceful
shutdown really needs. 
So instead of being endpoint based, we can switch to be route id, based instead.

Can you post some more details about your use-case, I wonder why you get so many unique endpoints
in the registry, as its consumer based. Are you adding a lot of new routes or the likes?
                
> 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
>             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

        

Mime
View raw message