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

Timothy Bish resolved AMQ-5441.
-------------------------------
       Resolution: Fixed
    Fix Version/s: 5.12.0
         Assignee: Timothy Bish

This has been fixed by not having the incoming connect attempts dip into the 
store but instead use the data already available in the broker memory to lookup 
and recover previous subscriptions.  

> PersistanceAdapter returns all Durable Subscriptions - this does not scale at 
> all when durable subscribers are used 
> --------------------------------------------------------------------------------------------------------------------
>
>                 Key: AMQ-5441
>                 URL: https://issues.apache.org/jira/browse/AMQ-5441
>             Project: ActiveMQ
>          Issue Type: Bug
>          Components: Broker
>    Affects Versions: 5.11.0
>            Reporter: Curt Jutzi
>            Assignee: Timothy Bish
>             Fix For: 5.12.0
>
>         Attachments: Junit_PersistanceAdapterIssue_IntelCjutzi.java, 
> apache-activemq_activemq-broker_Memory.patch, 
> apache-activemq_activemq-broker_PersistenceAdapter.patch, 
> apache-activemq_activemq-broker_PersistenceAdapterSupport.patch, 
> apache-activemq_activemq-jdbc-store_DefaultJDBCAdapter.patch, 
> apache-activemq_activemq-jdbc-store_JDBCAdapter.patch, 
> apache-activemq_activemq-jdbc-store_Statements.patch, 
> apache-activemq_activemq-store_KahaDBPersistenceAdapter.patch
>
>   Original Estimate: 48h
>  Remaining Estimate: 48h
>
> In the PersistenceAdapter for the broker, you'll see the call 
> getDestinations() which is used (At least in MQTT) on each connect to see if 
> the connecting client has any subscriptions.   The issue is that 
> getDesitinations() returns all durable subscriptions.  We have an environment 
> which has status / state which are retained, as well, each client supports 10 
> durable subscriptions.  With 10 K client connections this implies a dip into 
> the DB which will return 80 bytes for each DESTINATION in the data base * 10K 
> or 8 Meg on each connect.   This needs to be filtered in the DB query since 
> you are not looking for other clientids.  All PersistenceAdaptors implemented 
> have this issue. 
> I have modified the all the DB adaptors to support a new method called 
> getDestinations(String client_id).  I have also modified the JDBC query to 
> support a query which is specific to a given client-id and does not need to 
> loop through all (thousands of ) connections filtering the client_id in the 
> code.. 
> (see PersistenceAdapterSupport.listSubscriptions()).. 
>  
> I've also attached a JUnit test which demos the issue using derbyDb.. 



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Reply via email to