8:33 a.m.
ClassCastException in ReadCommittedNode.markForUpdate()
-------------------------------------------------------
Key: JBCACHE-1519
URL: https://jira.jboss.org/jira/browse/JBCACHE-1519
Project: JBoss Cache
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: Locking, Transactions
Affects Versions: 3.1.0.GA
Reporter: Krzysztof Sobolewski
Assignee: Manik Surtani
Attachments: ClassCastExceptionTest.java
The exception is deterministic (test case is attached) and even easy to reproduce.
Prerequisites:
- isolation level READ_COMMITTED
- lockParentForChildInsertRemove == true
- transactions (not sure about this one)
The test attached most probably isn't minimal, but it's small enough (it's
almost exactly what my application does). The test adds a small tree in one transaction
then in another transaction removes it and adds again, and it does both of those in a
loop. The exception is in the *second* iteration.
The exception occurs because the line 121 of ReadCommittedNode expects the backup of node
to be NodeReference, but somehow it's an UnversionedNode instead. This node is
retrieved from the data container, where the child is being added as an UnversionedNode by
MVCCNodeHelper line 338. When lockParentForChildInsertRemove is false this fragment is
never executed and there is no exception.
--
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
8:33 a.m.
New subject: [JBoss JIRA] Updated: (JBCACHE-1519) ClassCastException in ReadCommittedNode.markForUpdate()
[
https://jira.jboss.org/jira/browse/JBCACHE-1519?page=com.atlassian.jira.p...
]
Krzysztof Sobolewski updated JBCACHE-1519:
------------------------------------------
Attachment: ClassCastExceptionTest.java
The test case.
ClassCastException in ReadCommittedNode.markForUpdate()
-------------------------------------------------------
Key: JBCACHE-1519
URL: https://jira.jboss.org/jira/browse/JBCACHE-1519
Project: JBoss Cache
Issue Type: Bug
Security Level: Public(Everyone can see)
Components: Locking, Transactions
Affects Versions: 3.1.0.GA
Reporter: Krzysztof Sobolewski
Assignee: Manik Surtani
Attachments: ClassCastExceptionTest.java
The exception is deterministic (test case is attached) and even easy to reproduce.
Prerequisites:
- isolation level READ_COMMITTED
- lockParentForChildInsertRemove == true
- transactions (not sure about this one)
The test attached most probably isn't minimal, but it's small enough (it's
almost exactly what my application does). The test adds a small tree in one transaction
then in another transaction removes it and adds again, and it does both of those in a
loop. The exception is in the *second* iteration.
The exception occurs because the line 121 of ReadCommittedNode expects the backup of node
to be NodeReference, but somehow it's an UnversionedNode instead. This node is
retrieved from the data container, where the child is being added as an UnversionedNode by
MVCCNodeHelper line 338. When lockParentForChildInsertRemove is false this fragment is
never executed and there is no exception.
--
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
12:40 p.m.
New subject: [JBoss JIRA] Commented: (JBCACHE-1519) ClassCastException in ReadCommittedNode.markForUpdate()
[
https://jira.jboss.org/jira/browse/JBCACHE-1519?page=com.atlassian.jira.p...
]
Galder Zamarreno commented on JBCACHE-1519:
-------------------------------------------
Thanks for attaching the test case, this is precisely the same stuff I saw in PCACHE-82
java.lang.ClassCastException: org.jboss.cache.UnversionedNode cannot be cast to
org.jboss.cache.mvcc.NodeReference
at org.jboss.cache.mvcc.ReadCommittedNode.markForUpdate(ReadCommittedNode.java:121)
at org.jboss.cache.mvcc.MVCCNodeHelper.wrapAndPutInContext(MVCCNodeHelper.java:424)
at
org.jboss.cache.mvcc.MVCCNodeHelper.wrapNodesRecursivelyForRemoval(MVCCNodeHelper.java:329)
at
org.jboss.cache.interceptors.MVCCLockingInterceptor.handleRemoveNodeCommand(MVCCLockingInterceptor.java:116)
at
org.jboss.cache.interceptors.base.PrePostProcessingCommandInterceptor.visitRemoveNodeCommand(PrePostProcessingCommandInterceptor.java:126)
at
org.jboss.cache.commands.write.RemoveNodeCommand.acceptVisitor(RemoveNodeCommand.java:125)
at
org.jboss.cache.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:116)
at
org.jboss.cache.interceptors.base.CommandInterceptor.handleDefault(CommandInterceptor.java:131)
at
org.jboss.cache.commands.AbstractVisitor.visitRemoveNodeCommand(AbstractVisitor.java:75)
at
org.jboss.cache.commands.write.RemoveNodeCommand.acceptVisitor(RemoveNodeCommand.java:125)
at
org.jboss.cache.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:116)
at
org.jboss.cache.interceptors.TxInterceptor.attachGtxAndPassUpChain(TxInterceptor.java:301)
at org.jboss.cache.interceptors.TxInterceptor.handleDefault(TxInterceptor.java:283)
at
org.jboss.cache.commands.AbstractVisitor.visitRemoveNodeCommand(AbstractVisitor.java:75)
at
org.jboss.cache.commands.write.RemoveNodeCommand.acceptVisitor(RemoveNodeCommand.java:125)
at
org.jboss.cache.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:116)
at
org.jboss.cache.interceptors.base.CommandInterceptor.handleDefault(CommandInterceptor.java:131)
at
org.jboss.cache.commands.AbstractVisitor.visitRemoveNodeCommand(AbstractVisitor.java:75)
at
org.jboss.cache.commands.write.RemoveNodeCommand.acceptVisitor(RemoveNodeCommand.java:125)
at
org.jboss.cache.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:116)
at
org.jboss.cache.interceptors.InvocationContextInterceptor.handleAll(InvocationContextInterceptor.java:178)
at
org.jboss.cache.interceptors.InvocationContextInterceptor.visitRemoveNodeCommand(InvocationContextInterceptor.java:88)
at
org.jboss.cache.commands.write.RemoveNodeCommand.acceptVisitor(RemoveNodeCommand.java:125)
at org.jboss.cache.interceptors.InterceptorChain.invoke(InterceptorChain.java:287)
at
org.jboss.cache.invocation.CacheInvocationDelegate.removeNode(CacheInvocationDelegate.java:478)
at
org.jboss.cache.api.mvcc.ClassCastExceptionTest.remove(ClassCastExceptionTest.java:81)
at
org.jboss.cache.api.mvcc.ClassCastExceptionTest.testTest(ClassCastExceptionTest.java:62)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:616)
at org.testng.internal.MethodHelper.invokeMethod(MethodHelper.java:607)
at org.testng.internal.Invoker.invokeMethod(Invoker.java:517)
at org.testng.internal.Invoker.invokeTestMethod(Invoker.java:669)
at org.testng.internal.Invoker.invokeTestMethods(Invoker.java:956)
at org.testng.internal.TestMethodWorker.invokeTestMethods(TestMethodWorker.java:126)
at org.testng.internal.TestMethodWorker.run(TestMethodWorker.java:110)
at org.testng.TestRunner.runWorkers(TestRunner.java:759)
at org.testng.TestRunner.privateRun(TestRunner.java:592)
at org.testng.TestRunner.run(TestRunner.java:486)
at org.testng.SuiteRunner.runTest(SuiteRunner.java:332)
at org.testng.SuiteRunner.runSequentially(SuiteRunner.java:327)
at org.testng.SuiteRunner.privateRun(SuiteRunner.java:299)
at org.testng.SuiteRunner.run(SuiteRunner.java:204)
at org.testng.TestNG.createAndRunSuiteRunners(TestNG.java:877)
at org.testng.TestNG.runSuitesLocally(TestNG.java:842)
at org.testng.TestNG.run(TestNG.java:751)
at org.testng.remote.RemoteTestNG.run(RemoteTestNG.java:73)
at org.testng.remote.RemoteTestNG.main(RemoteTestNG.java:124)
ClassCastException in ReadCommittedNode.markForUpdate()
-------------------------------------------------------
Key: JBCACHE-1519
URL: https://jira.jboss.org/jira/browse/JBCACHE-1519
Project: JBoss Cache
Issue Type: Bug
Security Level: Public(Everyone can see)
Components: Locking, Transactions
Affects Versions: 3.1.0.GA
Reporter: Krzysztof Sobolewski
Assignee: Manik Surtani
Attachments: ClassCastExceptionTest.java
The exception is deterministic (test case is attached) and even easy to reproduce.
Prerequisites:
- isolation level READ_COMMITTED
- lockParentForChildInsertRemove == true
- transactions (not sure about this one)
The test attached most probably isn't minimal, but it's small enough (it's
almost exactly what my application does). The test adds a small tree in one transaction
then in another transaction removes it and adds again, and it does both of those in a
loop. The exception is in the *second* iteration.
The exception occurs because the line 121 of ReadCommittedNode expects the backup of node
to be NodeReference, but somehow it's an UnversionedNode instead. This node is
retrieved from the data container, where the child is being added as an UnversionedNode by
MVCCNodeHelper line 338. When lockParentForChildInsertRemove is false this fragment is
never executed and there is no exception.
--
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
12:42 p.m.
New subject: [JBoss JIRA] Commented: (JBCACHE-1519) ClassCastException in ReadCommittedNode.markForUpdate()
[
https://jira.jboss.org/jira/browse/JBCACHE-1519?page=com.atlassian.jira.p...
]
Galder Zamarreno commented on JBCACHE-1519:
-------------------------------------------
Let's focus on this one rather than PCACHE-82 cos this is a much simpler test.
See discussion in http://lists.jboss.org/pipermail/jbosscache-dev/2009-July/002681.html
Jason replied to me privately with this info:
"Step 4 sounds like the bug. I would try and create a simple core cache test case
which
does a node remove and create in the same tx."
ClassCastException in ReadCommittedNode.markForUpdate()
-------------------------------------------------------
Key: JBCACHE-1519
URL: https://jira.jboss.org/jira/browse/JBCACHE-1519
Project: JBoss Cache
Issue Type: Bug
Security Level: Public(Everyone can see)
Components: Locking, Transactions
Affects Versions: 3.1.0.GA
Reporter: Krzysztof Sobolewski
Assignee: Manik Surtani
Attachments: ClassCastExceptionTest.java
The exception is deterministic (test case is attached) and even easy to reproduce.
Prerequisites:
- isolation level READ_COMMITTED
- lockParentForChildInsertRemove == true
- transactions (not sure about this one)
The test attached most probably isn't minimal, but it's small enough (it's
almost exactly what my application does). The test adds a small tree in one transaction
then in another transaction removes it and adds again, and it does both of those in a
loop. The exception is in the *second* iteration.
The exception occurs because the line 121 of ReadCommittedNode expects the backup of node
to be NodeReference, but somehow it's an UnversionedNode instead. This node is
retrieved from the data container, where the child is being added as an UnversionedNode by
MVCCNodeHelper line 338. When lockParentForChildInsertRemove is false this fragment is
never executed and there is no exception.
--
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
12:48 p.m.
New subject: [JBoss JIRA] Work started: (JBCACHE-1519) ClassCastException in ReadCommittedNode.markForUpdate()
[
https://jira.jboss.org/jira/browse/JBCACHE-1519?page=com.atlassian.jira.p...
]
Work on JBCACHE-1519 started by Galder Zamarreno.
ClassCastException in ReadCommittedNode.markForUpdate()
-------------------------------------------------------
Key: JBCACHE-1519
URL: https://jira.jboss.org/jira/browse/JBCACHE-1519
Project: JBoss Cache
Issue Type: Bug
Security Level: Public(Everyone can see)
Components: Locking, Transactions
Affects Versions: 3.1.0.GA
Reporter: Krzysztof Sobolewski
Assignee: Galder Zamarreno
Attachments: ClassCastExceptionTest.java
The exception is deterministic (test case is attached) and even easy to reproduce.
Prerequisites:
- isolation level READ_COMMITTED
- lockParentForChildInsertRemove == true
- transactions (not sure about this one)
The test attached most probably isn't minimal, but it's small enough (it's
almost exactly what my application does). The test adds a small tree in one transaction
then in another transaction removes it and adds again, and it does both of those in a
loop. The exception is in the *second* iteration.
The exception occurs because the line 121 of ReadCommittedNode expects the backup of node
to be NodeReference, but somehow it's an UnversionedNode instead. This node is
retrieved from the data container, where the child is being added as an UnversionedNode by
MVCCNodeHelper line 338. When lockParentForChildInsertRemove is false this fragment is
never executed and there is no exception.
--
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
12:48 p.m.
New subject: [JBoss JIRA] Assigned: (JBCACHE-1519) ClassCastException in ReadCommittedNode.markForUpdate()
[
https://jira.jboss.org/jira/browse/JBCACHE-1519?page=com.atlassian.jira.p...
]
Galder Zamarreno reassigned JBCACHE-1519:
-----------------------------------------
Assignee: Galder Zamarreno (was: Manik Surtani)
ClassCastException in ReadCommittedNode.markForUpdate()
-------------------------------------------------------
Key: JBCACHE-1519
URL: https://jira.jboss.org/jira/browse/JBCACHE-1519
Project: JBoss Cache
Issue Type: Bug
Security Level: Public(Everyone can see)
Components: Locking, Transactions
Affects Versions: 3.1.0.GA
Reporter: Krzysztof Sobolewski
Assignee: Galder Zamarreno
Attachments: ClassCastExceptionTest.java
The exception is deterministic (test case is attached) and even easy to reproduce.
Prerequisites:
- isolation level READ_COMMITTED
- lockParentForChildInsertRemove == true
- transactions (not sure about this one)
The test attached most probably isn't minimal, but it's small enough (it's
almost exactly what my application does). The test adds a small tree in one transaction
then in another transaction removes it and adds again, and it does both of those in a
loop. The exception is in the *second* iteration.
The exception occurs because the line 121 of ReadCommittedNode expects the backup of node
to be NodeReference, but somehow it's an UnversionedNode instead. This node is
retrieved from the data container, where the child is being added as an UnversionedNode by
MVCCNodeHelper line 338. When lockParentForChildInsertRemove is false this fragment is
never executed and there is no exception.
--
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
12:50 p.m.
New subject: [JBoss JIRA] Updated: (JBCACHE-1519) ClassCastException in ReadCommittedNode.markForUpdate()
[
https://jira.jboss.org/jira/browse/JBCACHE-1519?page=com.atlassian.jira.p...
]
Galder Zamarreno updated JBCACHE-1519:
--------------------------------------
Workaround Description: The same workaround applies: Use REPEATABLE_READ in the mean
time
Workaround: [Workaround Exists]
ClassCastException in ReadCommittedNode.markForUpdate()
-------------------------------------------------------
Key: JBCACHE-1519
URL: https://jira.jboss.org/jira/browse/JBCACHE-1519
Project: JBoss Cache
Issue Type: Bug
Security Level: Public(Everyone can see)
Components: Locking, Transactions
Affects Versions: 3.1.0.GA
Reporter: Krzysztof Sobolewski
Assignee: Galder Zamarreno
Attachments: ClassCastExceptionTest.java
The exception is deterministic (test case is attached) and even easy to reproduce.
Prerequisites:
- isolation level READ_COMMITTED
- lockParentForChildInsertRemove == true
- transactions (not sure about this one)
The test attached most probably isn't minimal, but it's small enough (it's
almost exactly what my application does). The test adds a small tree in one transaction
then in another transaction removes it and adds again, and it does both of those in a
loop. The exception is in the *second* iteration.
The exception occurs because the line 121 of ReadCommittedNode expects the backup of node
to be NodeReference, but somehow it's an UnversionedNode instead. This node is
retrieved from the data container, where the child is being added as an UnversionedNode by
MVCCNodeHelper line 338. When lockParentForChildInsertRemove is false this fragment is
never executed and there is no exception.
--
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
9:53 a.m.
New subject: [JBoss JIRA] Updated: (JBCACHE-1519) ClassCastException in ReadCommittedNode.markForUpdate()
[
https://jira.jboss.org/jira/browse/JBCACHE-1519?page=com.atlassian.jira.p...
]
Galder Zamarreno updated JBCACHE-1519:
--------------------------------------
Attachment: patch.txt
Candidate patch pending review.
ClassCastException in ReadCommittedNode.markForUpdate()
-------------------------------------------------------
Key: JBCACHE-1519
URL: https://jira.jboss.org/jira/browse/JBCACHE-1519
Project: JBoss Cache
Issue Type: Bug
Security Level: Public(Everyone can see)
Components: Locking, Transactions
Affects Versions: 3.1.0.GA
Reporter: Krzysztof Sobolewski
Assignee: Galder Zamarreno
Attachments: ClassCastExceptionTest.java, patch.txt
The exception is deterministic (test case is attached) and even easy to reproduce.
Prerequisites:
- isolation level READ_COMMITTED
- lockParentForChildInsertRemove == true
- transactions (not sure about this one)
The test attached most probably isn't minimal, but it's small enough (it's
almost exactly what my application does). The test adds a small tree in one transaction
then in another transaction removes it and adds again, and it does both of those in a
loop. The exception is in the *second* iteration.
The exception occurs because the line 121 of ReadCommittedNode expects the backup of node
to be NodeReference, but somehow it's an UnversionedNode instead. This node is
retrieved from the data container, where the child is being added as an UnversionedNode by
MVCCNodeHelper line 338. When lockParentForChildInsertRemove is false this fragment is
never executed and there is no exception.
--
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
10:03 a.m.
New subject: [JBoss JIRA] Updated: (JBCACHE-1519) ClassCastException in ReadCommittedNode.markForUpdate()
[
https://jira.jboss.org/jira/browse/JBCACHE-1519?page=com.atlassian.jira.p...
]
Galder Zamarreno updated JBCACHE-1519:
--------------------------------------
Fix Version/s: 3.2.0.GA
ClassCastException in ReadCommittedNode.markForUpdate()
-------------------------------------------------------
Key: JBCACHE-1519
URL: https://jira.jboss.org/jira/browse/JBCACHE-1519
Project: JBoss Cache
Issue Type: Bug
Security Level: Public(Everyone can see)
Components: Locking, Transactions
Affects Versions: 3.1.0.GA
Reporter: Krzysztof Sobolewski
Assignee: Galder Zamarreno
Fix For: 3.2.0.GA
Attachments: ClassCastExceptionTest.java, patch.txt
The exception is deterministic (test case is attached) and even easy to reproduce.
Prerequisites:
- isolation level READ_COMMITTED
- lockParentForChildInsertRemove == true
- transactions (not sure about this one)
The test attached most probably isn't minimal, but it's small enough (it's
almost exactly what my application does). The test adds a small tree in one transaction
then in another transaction removes it and adds again, and it does both of those in a
loop. The exception is in the *second* iteration.
The exception occurs because the line 121 of ReadCommittedNode expects the backup of node
to be NodeReference, but somehow it's an UnversionedNode instead. This node is
retrieved from the data container, where the child is being added as an UnversionedNode by
MVCCNodeHelper line 338. When lockParentForChildInsertRemove is false this fragment is
never executed and there is no exception.
--
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
5:41 a.m.
New subject: [JBoss JIRA] Commented: (JBCACHE-1519) ClassCastException in ReadCommittedNode.markForUpdate()
[
https://jira.jboss.org/jira/browse/JBCACHE-1519?page=com.atlassian.jira.p...
]
Manik Surtani commented on JBCACHE-1519:
----------------------------------------
Also please make sure the unit test is added to the test suite.
ClassCastException in ReadCommittedNode.markForUpdate()
-------------------------------------------------------
Key: JBCACHE-1519
URL: https://jira.jboss.org/jira/browse/JBCACHE-1519
Project: JBoss Cache
Issue Type: Bug
Security Level: Public(Everyone can see)
Components: Locking, Transactions
Affects Versions: 3.1.0.GA
Reporter: Krzysztof Sobolewski
Assignee: Galder Zamarreno
Fix For: 3.3.0.GA
Attachments: ClassCastExceptionTest.java, patch.txt
The exception is deterministic (test case is attached) and even easy to reproduce.
Prerequisites:
- isolation level READ_COMMITTED
- lockParentForChildInsertRemove == true
- transactions (not sure about this one)
The test attached most probably isn't minimal, but it's small enough (it's
almost exactly what my application does). The test adds a small tree in one transaction
then in another transaction removes it and adds again, and it does both of those in a
loop. The exception is in the *second* iteration.
The exception occurs because the line 121 of ReadCommittedNode expects the backup of node
to be NodeReference, but somehow it's an UnversionedNode instead. This node is
retrieved from the data container, where the child is being added as an UnversionedNode by
MVCCNodeHelper line 338. When lockParentForChildInsertRemove is false this fragment is
never executed and there is no exception.
--
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
5:55 a.m.
New subject: [JBoss JIRA] Closed: (JBCACHE-1519) ClassCastException in ReadCommittedNode.markForUpdate()
[
https://jira.jboss.org/jira/browse/JBCACHE-1519?page=com.atlassian.jira.p...
]
Galder Zamarreno closed JBCACHE-1519.
-------------------------------------
ClassCastException in ReadCommittedNode.markForUpdate()
-------------------------------------------------------
Key: JBCACHE-1519
URL: https://jira.jboss.org/jira/browse/JBCACHE-1519
Project: JBoss Cache
Issue Type: Bug
Security Level: Public(Everyone can see)
Components: Locking, Transactions
Affects Versions: 3.1.0.GA
Reporter: Krzysztof Sobolewski
Assignee: Galder Zamarreno
Fix For: 3.2.0.GA
Attachments: ClassCastExceptionTest.java, patch.txt
The exception is deterministic (test case is attached) and even easy to reproduce.
Prerequisites:
- isolation level READ_COMMITTED
- lockParentForChildInsertRemove == true
- transactions (not sure about this one)
The test attached most probably isn't minimal, but it's small enough (it's
almost exactly what my application does). The test adds a small tree in one transaction
then in another transaction removes it and adds again, and it does both of those in a
loop. The exception is in the *second* iteration.
The exception occurs because the line 121 of ReadCommittedNode expects the backup of node
to be NodeReference, but somehow it's an UnversionedNode instead. This node is
retrieved from the data container, where the child is being added as an UnversionedNode by
MVCCNodeHelper line 338. When lockParentForChildInsertRemove is false this fragment is
never executed and there is no exception.
--
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
5:55 a.m.
New subject: [JBoss JIRA] Resolved: (JBCACHE-1519) ClassCastException in ReadCommittedNode.markForUpdate()
[
https://jira.jboss.org/jira/browse/JBCACHE-1519?page=com.atlassian.jira.p...
]
Galder Zamarreno resolved JBCACHE-1519.
---------------------------------------
Fix Version/s: 3.2.0.GA
(was: 3.3.0.GA)
Resolution: Done
ClassCastException in ReadCommittedNode.markForUpdate()
-------------------------------------------------------
Key: JBCACHE-1519
URL: https://jira.jboss.org/jira/browse/JBCACHE-1519
Project: JBoss Cache
Issue Type: Bug
Security Level: Public(Everyone can see)
Components: Locking, Transactions
Affects Versions: 3.1.0.GA
Reporter: Krzysztof Sobolewski
Assignee: Galder Zamarreno
Fix For: 3.2.0.GA
Attachments: ClassCastExceptionTest.java, patch.txt
The exception is deterministic (test case is attached) and even easy to reproduce.
Prerequisites:
- isolation level READ_COMMITTED
- lockParentForChildInsertRemove == true
- transactions (not sure about this one)
The test attached most probably isn't minimal, but it's small enough (it's
almost exactly what my application does). The test adds a small tree in one transaction
then in another transaction removes it and adds again, and it does both of those in a
loop. The exception is in the *second* iteration.
The exception occurs because the line 121 of ReadCommittedNode expects the backup of node
to be NodeReference, but somehow it's an UnversionedNode instead. This node is
retrieved from the data container, where the child is being added as an UnversionedNode by
MVCCNodeHelper line 338. When lockParentForChildInsertRemove is false this fragment is
never executed and there is no exception.
--
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
6:11 a.m.
New subject: [JBoss JIRA] Reopened: (JBCACHE-1519) ClassCastException in ReadCommittedNode.markForUpdate()
[
https://jira.jboss.org/jira/browse/JBCACHE-1519?page=com.atlassian.jira.p...
]
Manik Surtani reopened JBCACHE-1519:
------------------------------------
ClassCastException in ReadCommittedNode.markForUpdate()
-------------------------------------------------------
Key: JBCACHE-1519
URL: https://jira.jboss.org/jira/browse/JBCACHE-1519
Project: JBoss Cache
Issue Type: Bug
Security Level: Public(Everyone can see)
Components: Locking, Transactions
Affects Versions: 3.1.0.GA
Reporter: Krzysztof Sobolewski
Assignee: Galder Zamarreno
Fix For: 3.2.0.GA
Attachments: ClassCastExceptionTest.java, patch.txt
The exception is deterministic (test case is attached) and even easy to reproduce.
Prerequisites:
- isolation level READ_COMMITTED
- lockParentForChildInsertRemove == true
- transactions (not sure about this one)
The test attached most probably isn't minimal, but it's small enough (it's
almost exactly what my application does). The test adds a small tree in one transaction
then in another transaction removes it and adds again, and it does both of those in a
loop. The exception is in the *second* iteration.
The exception occurs because the line 121 of ReadCommittedNode expects the backup of node
to be NodeReference, but somehow it's an UnversionedNode instead. This node is
retrieved from the data container, where the child is being added as an UnversionedNode by
MVCCNodeHelper line 338. When lockParentForChildInsertRemove is false this fragment is
never executed and there is no exception.
--
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
6:13 a.m.
New subject: [JBoss JIRA] Resolved: (JBCACHE-1519) ClassCastException in ReadCommittedNode.markForUpdate()
[
https://jira.jboss.org/jira/browse/JBCACHE-1519?page=com.atlassian.jira.p...
]
Manik Surtani resolved JBCACHE-1519.
------------------------------------
Fix Version/s: 3.2.0.BETA1
Resolution: Done
ClassCastException in ReadCommittedNode.markForUpdate()
-------------------------------------------------------
Key: JBCACHE-1519
URL: https://jira.jboss.org/jira/browse/JBCACHE-1519
Project: JBoss Cache
Issue Type: Bug
Security Level: Public(Everyone can see)
Components: Locking, Transactions
Affects Versions: 3.1.0.GA
Reporter: Krzysztof Sobolewski
Assignee: Galder Zamarreno
Fix For: 3.2.0.BETA1, 3.2.0.GA
Attachments: ClassCastExceptionTest.java, patch.txt
The exception is deterministic (test case is attached) and even easy to reproduce.
Prerequisites:
- isolation level READ_COMMITTED
- lockParentForChildInsertRemove == true
- transactions (not sure about this one)
The test attached most probably isn't minimal, but it's small enough (it's
almost exactly what my application does). The test adds a small tree in one transaction
then in another transaction removes it and adds again, and it does both of those in a
loop. The exception is in the *second* iteration.
The exception occurs because the line 121 of ReadCommittedNode expects the backup of node
to be NodeReference, but somehow it's an UnversionedNode instead. This node is
retrieved from the data container, where the child is being added as an UnversionedNode by
MVCCNodeHelper line 338. When lockParentForChildInsertRemove is false this fragment is
never executed and there is no exception.
--
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
5378
days inactive
5408
days old
jbosscache-issues@lists.jboss.org
13 comments
3 participants
participants (3)
-
Galder Zamarreno (JIRA) -
Krzysztof Sobolewski (JIRA)
-
Manik Surtani (JIRA)