|
| Re: [CDO] Deadlock/Memory leak on multiple concurrent transactions? [message #898274 is a reply to message #897503] |
Thu, 26 July 2012 06:06   |
|
Hi Per,
Sorry for my late reply, it's busy here these days. I've already been working on your test case and I'll continue to
play with it later today. My main observation is that the size of the outOfSequenceInvalidations map gets smaller when
you sleep longer before the final assertion. Maybe that helps a little with your own investigations.
Cheers
/Eike
----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper
Am 24.07.2012 12:22, schrieb Per Sterner:
> Hello,
>
> I am still searching for our memory leak problems. I got my focus on the map 'outOfSequenceInvalidations' of 'CDOSessionImpl' because it was growing in my situation.
>
> I wrote a little test for 'InvalidationTest.java', sometimes the test hangs(?) (threaddump-1343122085409.tdump), and sometimes the map has the size 7,44,5,... at the end of the test.
>
> The test spawns 20 Threads and every thread does 10 transactions. (testcase_InvalidationTest.txt)
>
> (For the test I used CDO 4.1 master)
>
> Regards,
>
> Per Sterner
Cheers
/Eike
----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper
|
|
|
|
|
| Re: [CDO] Deadlock/Memory leak on multiple concurrent transactions? [message #910758 is a reply to message #910735] |
Mon, 10 September 2012 10:48 |
|
Am 10.09.2012 11:55, schrieb Christian Mohr:
> Well i tried to run Per's Test with variable amount of thread, transactions and longer "sleep" times as Eike suggested:
>
> 20 Threads/10 Transactions: Only 50% of the tests finish at all. All other just run into a deadlock somewhere (not
> able to pinpoint the deadlock yet).
If you run in debug mode then suspend the deadlocked thread and inspect the list of Java monitor locks it's holding and
it's waiting for. Then suspend the threads it's waiting for and look for monitors they're waiting for. It can be time
consuming but finally you should find a cycle if it's really a deadlock.
If you still don't find it you can send me the test case (attach it to a bugzilla). It would be handy to extend
AbstractCDOTest and use only the test models we're supplying with the tests feature.
> All finished tests had remaining "outOfSequenceInvalidations". Changing the second sleep made no change at all. The
> Map size was between 1 to 67 (even with 15 seconds sleeping). There where also many "modify historical revision" errors.
The latter must be expected if you don't use explicit locking.
>
> 2 Threads/10 Transactions: Same Problem, but the finishing rate increased and some Tests even finish without
> "outOfSequenceInvalidations".
>
>
> 1 Thread/100 Transactions: no errors
>
> Sofar i think, that the doDeactivate-Method of View/Transaction is sometimes called before
> "sendInvalidationNotifications" and "sendDeltaNotifications" (nullpointer in these 2 methods, for example
> "getModifiableObjects()" or "options()" return null). Maybe this timing-problem leads to the deadlock. At least i hope
> so :).
Yes, the deactivation of the view/transaction can lead to arbitrary effects in the asynchronous notification handling
but all of them should lead to no problems.
Cheers
/Eike
----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper
Cheers
/Eike
----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper
|
|
|
|
| Re: [CDO] Deadlock/Memory leak on multiple concurrent transactions? [message #911287 is a reply to message #910810] |
Tue, 11 September 2012 09:52 |
 Per Sterner
Messages: 91
Registered: October 2011 |
Member |
|
|
Hi,
(Christian and me are working together here). We just looked into the situation and we have come to the conclusion (the screenshot):
1. Thread 1 Starts a transaction, holds id=84
2. Thread 2 Starts a transaction and holds a lock on id=85
3. Thread 2 is processing
4. Thread 1 is ready and starts the invalidation (CDOSession.outofsequence lock)
5. Thread 1 wants the lock for id=85 (for the other view, setLastUpdateTime is called, this is synchronized with the view itself, which is currently locked through step 2.)
6. Thread 2 wants the lock for (CDOSession.outofsequence lock)
The step 5. blocks, because 'invalidateOrdered' is called directly and not through the invalidation runner.
I have to admit, I have no idea, how the semantic from the invalidation process should be synchronized...
If the 'invalidateOrdered' is always scheduled in the runner, the deadlock does not appear, but this would perhaps result in other problems?
Regards,
Per Sterner
[Updated on: Tue, 11 September 2012 10:00] Report message to a moderator |
|
|
Powered by
FUDForum. Page generated in 0.03698 seconds
] 
Search
Help
Register
Login
Home
.