[
https://issues.apache.org/jira/browse/AMQ-2063?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gary Tully resolved AMQ-2063.
-----------------------------
Resolution: Fixed
Assignee: Gary Tully
thanks for the contribution. Most of the suggestions have found there way onto
trunk but the last bit on conditional cleanup was missing.
Added in http://svn.apache.org/viewvc?rev=1101109&view=rev
It would be great if you could verify the current default persistence adapter
implementation on PostgreSQL to see if you get comparable performance to your
solution. The table scan for the sub select was the biggest problem I think.
The queries are now simpler and priority is alternated.
> 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
> Assignee: Gary Tully
> 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
