[
https://issues.apache.org/jira/browse/AMQ-5125?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14054450#comment-14054450
]
Brian Davis commented on AMQ-5125:
----------------------------------
Awesome that this is getting fixed. Thank you James for fixing this. I
apologize if this is the wrong form for this, I am new to this type of
development. The other issue I noticed from my analysis is the GCPolling job
and the rollback job got scheduled to the same thread at the same time in the
hawtdispatcher. It just so happens that the GCPoll job got ran first. My
system had many dispatch threads available but all the jobs only went to the
one dispatch thread causing the deadlock. Could you tell me the reasoning this
is not a concern? I personally would like to understand this better. Thank
you.
Brian
> Broker and clients hang
> -----------------------
>
> Key: AMQ-5125
> URL: https://issues.apache.org/jira/browse/AMQ-5125
> Project: ActiveMQ
> Issue Type: Bug
> Affects Versions: 5.9.0, 5.10.0
> Environment: Windows 7, Linux
> JAVA_HOME=C:\Program Files\Java\jdk1.7.0_07
> ActiveMQ 5.9.0 with LevelDB storage adapter enabled
> Reporter: Albert Barmettler
> Priority: Blocker
> Fix For: 5.11.0
>
> Attachments:
> AMQ-5125_made_synchronization_in_LevelDBStore_use_private_lock.5.9.2.patch,
> Broker-threaddump-1396544622970.tdump,
> Clients-threaddump-1396544622970.tdump, VM.PNG, activemq.xml,
> broker-threads-blocked.tdump, src.zip
>
>
> JMS clients start to hang after a while in calls such as
> session.createObjectMessage(). Both the broker and the hanging clients can't
> be easily shut down when this happens - only forcefully applied kill's do the
> job.
> I'm using queues and transactional sessions. All clients (producers and
> consumers) are in the same Java VM. There is only one JMS connection between
> the application and the broker. Each client has its own session, but they all
> share the same connection.
> Normally, the data directory of the LevelDb contains only a few log files.
> But in my case, the number of log files is steadily increasing.
> Furthermore, I was able to track down the issue to following circumstance:
> The problem only occurs, when consumers do a rollback instead of a commit
> when they receive the message. The rollback / redelivery works as expected -
> the same message is received again after a previous rollback.
> As far as I can tell, the problem does not occur with KahaDb.
> I'll attach a test program that provokes the error. It sets up a few hundred
> queues, consumers and producers. The consumers just receive the message and
> commit the session, but they also do "random" rollbacks. It can be observed
> immediately that the number of files starts increasing in the data directory.
> After a few minutes, the clients hang - sometimes sooner, sometimes later.
> I'll also attach the config file for the broker.
> I am aware, that heavy rollbacking should not happen in normal operation. But
> from a long term stability perspective, this is a blocker for us.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
