[
https://issues.apache.org/activemq/browse/AMQ-2063?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Hadrian Zbarcea updated AMQ-2063:
---------------------------------
Fix Version/s: 5.4.1
(was: 5.4.0)
> 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, PostgreSQL 8.3.4, java 1.6.0_05-b13
> Reporter: Eugene Strulyov
> Fix For: 5.4.1
>
> 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.
-
You can reply to this email to add a comment to the issue online.
