JDBC persistence adapter improvements
-------------------------------------
Key: AMQ-2063
URL: https://issues.apache.org/activemq/browse/AMQ-2063
Project: ActiveMQ
Issue Type: Improvement
Components: Message Store
Affects Versions: 5.3.0
Environment: RHEL 5, Linux 2.6.18, java 1.6.0_05-b13
Reporter: Eugene Strulyov
Fix For: 5.3.0
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.
-
You can reply to this email to add a comment to the issue online.
