[
https://issues.apache.org/jira/browse/AMQ-2063?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13029833#comment-13029833
]
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: https://issues.apache.org/jira/browse/AMQ-2063
> 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: DefaultJDBCAdapter.java.diff,
> JDBCPersistenceAdapter.java.diff, PostgresqlJDBCAdapter.java.diff
>
>
> 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:
> http://www.nabble.com/JDBC-persistence-adapter-improvements-td21086330.html#a21086330
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
