activemq-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Arnaud BRAND (JIRA)" <>
Subject [jira] [Commented] (AMQ-2063) JDBC persistence adapter improvements
Date Fri, 06 May 2011 08:37:03 GMT


Arnaud BRAND commented on AMQ-2063:

Point 1: I would rather setup proper indexes or table partitioning than using loops. 
This code probably doesn't scale very well when there's a large number of queues.

Point 2 seems to be fixed at least since 5.5.0   
line 916: s.setMaxRows(Math.max(maxReturned * 2, maxRows));
And maxRows can be set in the XML.

Point 3 fix removes the call to cleanup() if cleanupPeriod=0.

> JDBC persistence adapter improvements
> -------------------------------------
>                 Key: AMQ-2063
>                 URL:
>             Project: ActiveMQ
>          Issue Type: Improvement
>          Components: Message Store
>    Affects Versions: 5.3.0
>         Environment: RHEL 5, Linux 2.6.18, PostgreSQL 8.3.4, java 1.6.0_05-b13
>            Reporter: Eugene Strulyov
>             Fix For: 5.6.0
>         Attachments:,,
> Hi all,
> I made the following improvements to the JDBC persistence adapter:
> 1. Implemented PostgresqlJDBCAdapter.doDeleteOldMessages() method that is at least three
orders of magnitude faster than the default implementation. The same optimization may apply
to other databases so you may want to consider moving it to DefaultJDBCAdapter.
> 2. Changed DefaultJDBCAdapter.doRecoverNextMessages() to always process at least 1000
messages at a time. This results in a huge performance improvement. However, this implementation
is a hack (see comment). Somebody may want to look into why maxReturned gets set to 1 on the
third call to doRecoverNextMessages(). I was able to consistently reproduce this behaviour.
> 3. Fixed JDBCPersistenceAdapter so that it does not double-call cleanup() [once in the
main thread, once in the worker thread], and also so that it does not hang ActiveMQ initialization
when there are lots of pending messages.
> Performance is now limited by repeated calls to JDBCTopicMessageStore.acknowledge().
This causes an update for every single message (updates last_acked_id in activemq_acks table).
I don't know enough about ActiveMQ architecture to optimize this, but perhaps someone should
look into this. For example, if it only did this update after processing a batch of messages
(say 1000 at a time), it would be a lot faster. The current implementation keeps incrementing
last_acked_id, once per delivered message.
> Diffs attached.
> Eugene 
> Here is original post on the developer forum:

This message is automatically generated by JIRA.
For more information on JIRA, see:

View raw message