[MAGNOLIA-3847] Deadlock in info.magnolia.module.exchangesimple.ReceiveFilter Created: 02/Oct/11  Updated: 25/Oct/13  Resolved: 27/Sep/13

Status: Closed
Project: Magnolia
Component/s: core
Affects Version/s: 4.4.5
Fix Version/s: None

Type: Bug Priority: Blocker
Reporter: Ronald Ten Berge Assignee: Daniel Lipp
Resolution: Cannot Reproduce Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

FreeBSD 7.2-RELEASE-p2 amd64


Attachments: Text File Deadlock.txt     Text File Deadlock2.txt    
Template:
Acceptance criteria:
Empty
Task DoD:
[ ]* Doc/release notes changes? Comment present?
[ ]* Downstream builds green?
[ ]* Solution information and context easily available?
[ ]* Tests
[ ]* FixVersion filled and not yet released
[ ]  Architecture Decision Record (ADR)
Bug DoR:
[ ]* Steps to reproduce, expected, and actual results filled
[ ]* Affected version filled
Date of First Response:

 Description   

During the activation of a large amount of content the activation log messages stopped and the website workspace became unreachable. I've created a thread dump and it seems to be a deadlock in the info.magnolia.module.exchangesimple.ReceiveFilter. Please see the attached thread dumps for more information.

I had to kill our production Tomcat server to get things running again, because the normal shutdown routine wasn't working.



 Comments   
Comment by Jan Haderka [ 10/Nov/11 ]

Hi Ronald,

sorry for late response. Somehow missed that issue previously.
Could you please provide few more data? The two attached dumps are about 30 minutes apart, does it mean you got the deadlock twice?
I've analyzed the first one and from what i see, there are multiple threads stuck in trying to render/refresh tree and only 3 threads stuck in ReceiveFilter.

  • http-8180-5 is stuck in JR code, trying to lock the content (write lock)
  • http-8180-10 is stuck in JR code, trying to retrieve the content (read lock)
  • http-8180-16 is stuck in JR code, trying to check whether content is locked or not (read lock)

During activation ReceiveFilter locks down whole branch of the tree that is being activated in order to make sure children are not activated at the same time as parent. This is to ensure proper deactivation and ordering of the child nodes.
What I need is the log from activation to see what content in what order was activated and also description from you to see what you did. Did you ran just one activation, activating some big tree or was it multiple activations of unrelated subtrees or did you actually start recursive activation and then attempted to activate some sub nodes from the same branch that was already being activated?

Thx,
Jan

Comment by Ronald Ten Berge [ 16/Nov/11 ]

Hi Jan,

No problem, the issue didn't occur again after this bug report. The activation log has been lost due to an reinstall, and I'm sorry that I can't provide you that information.

If I remember correctly, I started a recursive activation and then tried to activate a different tree recursivly.

Kind regards,

Ronald

Generated at Mon Feb 12 03:50:14 CET 2024 using Jira 9.4.2#940002-sha1:46d1a51de284217efdcb32434eab47a99af2938b.