There's been a lot of re-work on the FilePendingMessageCursor (and other areas that you touched here) since release 5.4.2 (which is about 2 yrs old). Do you have the possibility to check with a later version of the code to see if that's been fixed for you?
On Mon, Dec 17, 2012 at 6:36 AM, Tom Martinec <marti...@d3s.mff.cuni.cz>wrote: > Hello, > > I fixed the issue on my own. Here is the list of things I have done: > > 1 - On the line 219 of > > http://svn.apache.org/viewvc/activemq/tags/activemq-5.4.2/activemq-core/src/main/java/org/apache/activemq/broker/region/cursors/FilePendingMessageCursor.java?view=markup > I unlocked the messagesLock that was created in the queue. I have done > that, > because the writer thread waits for free space, but the consumers are > locked > waiting until the writer thread releases the lock. > > boolean spaceAvailable = waitForTempSpace(maxWaitTime); > > if (spaceAvailable) { > ByteSequence bs = getByteSequence(node.getMessage()); > getDiskList().addLast(node.getMessageId().toString(), > bs); > return true; > } > return false; > > protected boolean waitForTempSpace(long maxWaitTime) throws > InterruptedException { > if (cursorLock != null) { > cursorLock.writeLock().unlock(); > } > > boolean freeSpaceAvailable = > systemUsage.getTempUsage().waitForSpace(maxWaitTime); > > if (cursorLock != null) { > cursorLock.writeLock().lock(); > } > > return freeSpaceAvailable; > } > > 2 - The writer and consumer threads are also synchronized on the object of > the cursor. So the step 1) was not enough. IMHO only one of the > synchronized > primitive should be used. I decided to keep the RW lock that was created > inside the Queue class. By the way, the advantage of RW locks seemed to > never be used because of the second synchronization mechanism. This > basically required to remove the "synchronized" keywords from the cursors > and replace them by the RW lock from outside where the sync was still > needed. > > 3 - There was yet another deadlock looking behaviour. The > TempUsage.retrieveUsage() worked with full preallocated size of kahadb > storage, so the storage was always considered full. I extended the kahadb > interface to provide the count of free bytes in the PListStore and not just > its size. > > Since then the ActiveMQ has been be working fine with no deadlocks. Note, > that I use the ActiveMQ only in a simple Queuing scenario, so I could have > broken something else by this change. > > > > > -- > View this message in context: > http://activemq.2283324.n4.nabble.com/Activemq-5-4-2-hangs-when-the-temp-disk-usage-is-used-tp4660202p4660746.html > Sent from the ActiveMQ - User mailing list archive at Nabble.com. > -- *Christian Posta* http://www.christianposta.com/blog twitter: @christianposta
