[
https://jira.jboss.org/jira/browse/JBCACHE-1420?page=com.atlassian.jira.p...
]
Manik Surtani commented on JBCACHE-1420:
----------------------------------------
Thanks for spotting this, I have added a unit test and have included a patch in branch
2.2.X. This will be in 2.2.1.GA.
Re: the init logic, yes it is insane, and once we (eventually) drop support for optimistic
and pessimistic locking we'll be able to un-wire and simplify it. Don't expect
this till circa 3.2.0 though.
LockForChildInsertRemove flag not set for root node
---------------------------------------------------
Key: JBCACHE-1420
URL:
https://jira.jboss.org/jira/browse/JBCACHE-1420
Project: JBoss Cache
Issue Type: Bug
Security Level: Public(Everyone can see)
Affects Versions: 2.2.0.GA
Reporter: Krzysztof Sobolewski
Assignee: Manik Surtani
The lockForChildInsertRemove flag gets propagated to all nodes but the root. The root
node is being constructed at least four times, three of which properly extract this flag
from Configuration object; the remaining one doesn't because it receives null
Configuration (it's the first one created). The thing is that the object returned as
the root node to the application is the only one with this flag uninitialized.
At this point I saw the stack trace and gave up all hopes of penetrating the
initialization logic :)
Usually this is no big deal, but I have a test that can reliably blow up in 10 seconds on
average (on an old, UP laptop) because of that :) and it scares me...
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira