activemq-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Curt Jutzi (JIRA)" <>
Subject [jira] [Updated] (AMQ-5441) PersistanceAdapter returns all Durable Subscriptions - this does not scale at all when durable subscribers are used
Date Mon, 17 Nov 2014 17:55:33 GMT


Curt Jutzi updated AMQ-5441:

includes patches and JUnit test.. 
I did not include LevelDB patch

> PersistanceAdapter returns all Durable Subscriptions - this does not scale at all when
durable subscribers are used 
> --------------------------------------------------------------------------------------------------------------------
>                 Key: AMQ-5441
>                 URL:
>             Project: ActiveMQ
>          Issue Type: Bug
>          Components: Broker
>    Affects Versions: 5.11.0
>            Reporter: Curt Jutzi
>         Attachments:, 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,
>   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

View raw message