[JBoss JIRA] Commented: (JGRP-130) Problems with reincarnation
by Bela Ban (JIRA)
[ http://jira.jboss.com/jira/browse/JGRP-130?page=comments#action_12370410 ]
Bela Ban commented on JGRP-130:
-------------------------------
here's a simple way to reproduce the issue: using the attached tcp.xml (without FD_SOCK, and with FD having a 10 sec timeout).
- Start the first Draw (A), will use port 7800
- Start the second Draw (B), will use port 7801
- Draw in the first and 2nd window.
- Assume A's digest is A:23, B:45 (45 messages from B have so far been received)
- Kill B and immediately restart it (needs to be under 10 secs, or else FD excludes B)
- Now A's digest is *still* A:23,B:45 (although B's gone !)
- B's digest is A:23,B:0
- Now draw in A: B will receive those messages
- Then draw in B: A will ignore messages B:0-B:24, as it thinks it has already received messages 0-23 from B ! Only messages after 23 from B will be accepted from A !
> Problems with reincarnation
> ---------------------------
>
> Key: JGRP-130
> URL: http://jira.jboss.com/jira/browse/JGRP-130
> Project: JGroups
> Issue Type: Feature Request
> Affects Versions: 2.2.9
> Reporter: Bela Ban
> Assigned To: Bela Ban
> Fix For: 2.6
>
> Attachments: tcp.xml
>
>
> Problems with reincarnation
> ===========================
> Author: Bela Ban
> Version: $Id$
> The identity of a JGroups member is always the IP address and a port. The port is usually chosen by the OS, unless
> bind_port is set (not set by default).
> Let's say a member's address is hostA:5000. When that member dies and is restarted, the OS will likely assign a
> higher port, say 5002. This depends on how many other processes requested a port in between the start and restart
> of the member.
> JGroups relies on the fact that the assignment of ports by the OS is always (not necessarily monotonically)
> *increasing* across a single machine. If this is not the case, then the following problems can occur:
> 1. Restart:
> When a member P crashes and then is restarted, if FD is used and P is restarted *before* it is excluded,
> then we have a new member *under the same old address* ! Since it lost all of its state (e.g. retransmission table),
> retransmission requests sent to the new P will fail.
> 2. Shunning:
> Regarding shunning: a member keeps its last N (default is 100) ports used, and makes sure it doesn't reuse one of
> those already-used ports when it is shunned. However, this is process-wide and *not* machine-wide, e.g. when we have
> processes P1 on A:5000 and P2 on A:5002 (on machine A), and both of them are shunned at the same time,
> when they rejoin, P1 does not use port 5000, but might use port 5002, and P2 doesn't use 5002, but might use 5000, so
> they could assume each other's identity !
> Both problems cannot be solved by remembering the last 100 ports: in case #1, this list is lost because we start a
> new process and in case #2, the list is process-wide, but not machine-wide.
> Again, these problems occur *only* when the OS reuses previously assigned ports.
> SOLUTION:
> A: Use temporary storage (per host) to store the last N addresses assigned on a given host. This makes sure we
> don't reuse previous addresses
> B: Use logical addresses, such as java.rmi.VMID or java.rmi.server.UID, which are unique over time for a given host.
> Then, it doesn't matter what ports we use because the ports are not used to determine a member's identity.
> The JIRA task for logical addresses is http://jira.jboss.com/jira/browse/JGRP-129.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
18 years, 12 months
[JBoss JIRA] Updated: (JGRP-130) Problems with reincarnation
by Bela Ban (JIRA)
[ http://jira.jboss.com/jira/browse/JGRP-130?page=all ]
Bela Ban updated JGRP-130:
--------------------------
Attachment: tcp.xml
> Problems with reincarnation
> ---------------------------
>
> Key: JGRP-130
> URL: http://jira.jboss.com/jira/browse/JGRP-130
> Project: JGroups
> Issue Type: Feature Request
> Affects Versions: 2.2.9
> Reporter: Bela Ban
> Assigned To: Bela Ban
> Fix For: 2.6
>
> Attachments: tcp.xml
>
>
> Problems with reincarnation
> ===========================
> Author: Bela Ban
> Version: $Id$
> The identity of a JGroups member is always the IP address and a port. The port is usually chosen by the OS, unless
> bind_port is set (not set by default).
> Let's say a member's address is hostA:5000. When that member dies and is restarted, the OS will likely assign a
> higher port, say 5002. This depends on how many other processes requested a port in between the start and restart
> of the member.
> JGroups relies on the fact that the assignment of ports by the OS is always (not necessarily monotonically)
> *increasing* across a single machine. If this is not the case, then the following problems can occur:
> 1. Restart:
> When a member P crashes and then is restarted, if FD is used and P is restarted *before* it is excluded,
> then we have a new member *under the same old address* ! Since it lost all of its state (e.g. retransmission table),
> retransmission requests sent to the new P will fail.
> 2. Shunning:
> Regarding shunning: a member keeps its last N (default is 100) ports used, and makes sure it doesn't reuse one of
> those already-used ports when it is shunned. However, this is process-wide and *not* machine-wide, e.g. when we have
> processes P1 on A:5000 and P2 on A:5002 (on machine A), and both of them are shunned at the same time,
> when they rejoin, P1 does not use port 5000, but might use port 5002, and P2 doesn't use 5002, but might use 5000, so
> they could assume each other's identity !
> Both problems cannot be solved by remembering the last 100 ports: in case #1, this list is lost because we start a
> new process and in case #2, the list is process-wide, but not machine-wide.
> Again, these problems occur *only* when the OS reuses previously assigned ports.
> SOLUTION:
> A: Use temporary storage (per host) to store the last N addresses assigned on a given host. This makes sure we
> don't reuse previous addresses
> B: Use logical addresses, such as java.rmi.VMID or java.rmi.server.UID, which are unique over time for a given host.
> Then, it doesn't matter what ports we use because the ports are not used to determine a member's identity.
> The JIRA task for logical addresses is http://jira.jboss.com/jira/browse/JGRP-129.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
18 years, 12 months
[JBoss JIRA] Created: (JBCACHE-1157) Pessimistic Lock Interceptor does not acquite a write lock for remove(Fqn, key)
by Manik Surtani (JIRA)
Pessimistic Lock Interceptor does not acquite a write lock for remove(Fqn, key)
-------------------------------------------------------------------------------
Key: JBCACHE-1157
URL: http://jira.jboss.com/jira/browse/JBCACHE-1157
Project: JBoss Cache
Issue Type: Bug
Security Level: Public (Everyone can see)
Affects Versions: 1.4.1.SP3, 1.4.1.SP2, 1.4.1.SP1, 1.4.1.SP4, 2.0.0.CR3, 2.0.0.CR2, 2.0.0.CR1
Reporter: Manik Surtani
Assigned To: Manik Surtani
Priority: Critical
Fix For: 2.0.0.GA, 1.4.1.SP5
See test added:
org.jboss.cache.lock.PessimisticLockTest
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
18 years, 12 months
[JBoss JIRA] Created: (JGRP-518) RpcDispatcher: filter for accepting incoming responses
by Bela Ban (JIRA)
RpcDispatcher: filter for accepting incoming responses
------------------------------------------------------
Key: JGRP-518
URL: http://jira.jboss.com/jira/browse/JGRP-518
Project: JGroups
Issue Type: Feature Request
Reporter: Bela Ban
Assigned To: Bela Ban
Fix For: 2.6
[Manik's email]
Are there any plans to implement a way to register a filter when using the RpcDispatcher when waiting for results?
Current options (GroupRequest.GET_ALL, GET_NONE, GET_MOST, GET_FIRST, etc) is insufficient where you want the call to block until the first *acceptable* response is received.
Basically, if I expect responses from everyone in the cluster but want to wait for the first acceptable response, I have no choice but to do a GET_ALL and then parse all the responses for the first acceptable one. Now the definition of an acceptable response is application-specific, and so perhaps a mechanism to register a filter would be useful. Perhaps something like:
RpcDispatcher.callRemoteMethods(Vector dests, MethodCall call, int mode, long timeout, boolean use_anycasting, ResponseFilter responseFilter)
public interface ResponseFilter
{
boolean isAcceptable(Object response);
}
If a filter is provided, only responses that pass the isAcceptable() test is added to the response list. Then GroupRequest.GET_FIRST could be used and we could have a very efficient mechanism of not having to wait for all responses.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
18 years, 12 months
[JBoss JIRA] Created: (JBAS-3385) cmp2.x jdbc2 pm Failed to Deploy 2 Identical EARs with Different Datasource Configuration
by Richard C. L. Li (JIRA)
cmp2.x jdbc2 pm Failed to Deploy 2 Identical EARs with Different Datasource Configuration
-----------------------------------------------------------------------------------------
Key: JBAS-3385
URL: http://jira.jboss.com/jira/browse/JBAS-3385
Project: JBoss Application Server
Issue Type: Patch
Security Level: Public (Everyone can see)
Components: CMP service
Affects Versions: JBossAS-4.0.4.GA
Reporter: Richard C. L. Li
Assigned To: Alexey Loubyansky
Deploying 2 Identical EARs with different datasource configuration will generate the following exception:
2006-07-11 12:54:36,458 INFO [org.jboss.ejb.plugins.cmp.jdbc2.schema.PartitionedTableCache] Registration is not done -> stop
2006-07-11 12:54:36,458 WARN [org.jboss.system.ServiceController] Problem starting service jboss.j2ee:module=retailsales.jar,uid=12606869,service=EjbModule
org.jboss.deployment.DeploymentException: Failed to register table cache for memo; - nested throwable: (javax.management.InstanceAlreadyExistsException: jboss.cmp:service=tablecache,ejbname=Memo,table=memo already registered.)
at org.jboss.ejb.plugins.cmp.jdbc2.schema.EntityTable.<init>(EntityTable.java:216)
at org.jboss.ejb.plugins.cmp.jdbc2.schema.Schema.createEntityTable(Schema.java:93)
at org.jboss.ejb.plugins.cmp.jdbc2.bridge.JDBCEntityBridge2.<init>(JDBCEntityBridge2.java:80)
at org.jboss.ejb.plugins.cmp.jdbc2.JDBCStoreManager2.initStoreManager(JDBCStoreManager2.java:437)
at org.jboss.ejb.plugins.cmp.jdbc2.JDBCStoreManager2.start(JDBCStoreManager2.java:175)
at org.jboss.ejb.plugins.CMPPersistenceManager.start(CMPPersistenceManager.java:172)
at org.jboss.ejb.EntityContainer.startPmAndInterceptors(EntityContainer.java:1063)
at org.jboss.ejb.EjbModule.startService(EjbModule.java:422)
at org.jboss.system.ServiceMBeanSupport.jbossInternalStart(ServiceMBeanSupport.java:289)
at org.jboss.system.ServiceMBeanSupport.jbossInternalLifecycle(ServiceMBeanSupport.java:245)
at sun.reflect.GeneratedMethodAccessor3.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
at org.jboss.mx.server.Invocation.invoke(Invocation.java:86)
at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
at org.jboss.system.ServiceController$ServiceProxy.invoke(ServiceController.java:978)
at $Proxy0.start(Unknown Source)
at org.jboss.system.ServiceController.start(ServiceController.java:417)
at sun.reflect.GeneratedMethodAccessor8.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
at org.jboss.mx.server.Invocation.invoke(Invocation.java:86)
at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:210)
at $Proxy16.start(Unknown Source)
at org.jboss.ejb.EJBDeployer.start(EJBDeployer.java:662)
at sun.reflect.GeneratedMethodAccessor77.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
at org.jboss.mx.interceptor.AbstractInterceptor.invoke(AbstractInterceptor.java:133)
at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
at org.jboss.mx.interceptor.ModelMBeanOperationInterceptor.invoke(ModelMBeanOperationInterceptor.java:142)
at org.jboss.mx.interceptor.DynamicInterceptor.invoke(DynamicInterceptor.java:97)
at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:210)
at $Proxy17.start(Unknown Source)
at org.jboss.deployment.MainDeployer.start(MainDeployer.java:1007)
at org.jboss.deployment.MainDeployer.start(MainDeployer.java:997)
at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:808)
at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:771)
at sun.reflect.GeneratedMethodAccessor49.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
at org.jboss.mx.interceptor.AbstractInterceptor.invoke(AbstractInterceptor.java:133)
at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
at org.jboss.mx.interceptor.ModelMBeanOperationInterceptor.invoke(ModelMBeanOperationInterceptor.java:142)
at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:210)
at $Proxy8.deploy(Unknown Source)
at org.jboss.deployment.scanner.URLDeploymentScanner.deploy(URLDeploymentScanner.java:421)
at org.jboss.deployment.scanner.URLDeploymentScanner.scan(URLDeploymentScanner.java:634)
at org.jboss.deployment.scanner.AbstractDeploymentScanner$ScannerThread.doScan(AbstractDeploymentScanner.java:263)
at org.jboss.deployment.scanner.AbstractDeploymentScanner$ScannerThread.loop(AbstractDeploymentScanner.java:274)
at org.jboss.deployment.scanner.AbstractDeploymentScanner$ScannerThread.run(AbstractDeploymentScanner.java:225)
Caused by: javax.management.InstanceAlreadyExistsException: jboss.cmp:service=tablecache,ejbname=Memo,table=memo already registered.
at org.jboss.mx.server.registry.BasicMBeanRegistry.add(BasicMBeanRegistry.java:761)
at org.jboss.mx.server.registry.BasicMBeanRegistry.registerMBean(BasicMBeanRegistry.java:225)
at sun.reflect.GeneratedMethodAccessor1.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
at org.jboss.mx.interceptor.AbstractInterceptor.invoke(AbstractInterceptor.java:133)
at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
at org.jboss.mx.interceptor.ModelMBeanOperationInterceptor.invoke(ModelMBeanOperationInterceptor.java:142)
at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
at org.jboss.mx.server.MBeanServerImpl$3.run(MBeanServerImpl.java:1422)
at java.security.AccessController.doPrivileged(Native Method)
at org.jboss.mx.server.MBeanServerImpl.registerMBean(MBeanServerImpl.java:1417)
at org.jboss.mx.server.MBeanServerImpl.registerMBean(MBeanServerImpl.java:376)
at org.jboss.ejb.plugins.cmp.jdbc2.schema.EntityTable.<init>(EntityTable.java:211)
... 67 more
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
18 years, 12 months
[JBoss JIRA] Commented: (JBCACHE-97) ReadWriteLockWithUpgrade: UpgradeException with more than 1 reader/writer waiting to upgrade lock
by Jason T. Greene (JIRA)
[ http://jira.jboss.com/jira/browse/JBCACHE-97?page=comments#action_12370362 ]
Jason T. Greene commented on JBCACHE-97:
----------------------------------------
This will be fixed as part of JBCACHE-1151
> ReadWriteLockWithUpgrade: UpgradeException with more than 1 reader/writer waiting to upgrade lock
> -------------------------------------------------------------------------------------------------
>
> Key: JBCACHE-97
> URL: http://jira.jboss.com/jira/browse/JBCACHE-97
> Project: JBoss Cache
> Issue Type: Bug
> Components: Clustering
> Reporter: Bela Ban
> Assigned To: Jason T. Greene
> Fix For: 2.1.0.GA
>
>
> TxDeadlockUnitTestCase has 2 methods that show the following stack traces:
> testMoreThanOneUpgrader:
> Upgrader#0: get(/a/b/c)
> Upgrader#1: get(/a/b/c)
> main: locks:
> /a (read owners=[<null>:2, <null>:1])
> /b (read owners=[<null>:2, <null>:1])
> /c (read owners=[<null>:2, <null>:1])
> Upgrader#0: put(/a/b/c)
> Upgrader#1: put(/a/b/c)
> Upgrader#1: org.jboss.cache.lock.LockingException: acquireWriteLock(): lock upgrade failed for /a/b/c (caller=<null>:2); - nested throwable: (org.jboss.cache.lock.UpgradeException: upgradeLockAttempt(): more than one reader trying to simultaneously upgrade to write lock)
> Upgrader#0: org.jboss.cache.lock.TimeoutException: upgrade lock for /a/b/c could not be acquired after 3000 ms. Lock map ownership Read lock owners: [<null>:2]
> Write lock owner: null
> (caller=<null>:1)
> org.jboss.cache.lock.TimeoutException: upgrade lock for /a/b/c could not be acquired after 3000 ms. Lock map ownership Read lock owners: [<null>:2]
> Write lock owner: null
> (caller=<null>:1)
> at org.jboss.cache.lock.IdentityLock.acquireWriteLock(IdentityLock.java:155)
> at org.jboss.cache.Node.acquireWriteLock(Node.java:448)
> at org.jboss.cache.Node.acquire(Node.java:417)
> at org.jboss.cache.interceptors.LockInterceptor.lock(LockInterceptor.java:199)
> at org.jboss.cache.interceptors.LockInterceptor.invoke(LockInterceptor.java:144)
> at org.jboss.cache.interceptors.Interceptor.invoke(Interceptor.java:40)
> at org.jboss.cache.interceptors.CreateIfNotExistsInterceptor.invoke(CreateIfNotExistsInterceptor.java:145)
> at org.jboss.cache.interceptors.Interceptor.invoke(Interceptor.java:40)
> at org.jboss.cache.interceptors.UnlockInterceptor.invoke(UnlockInterceptor.java:35)
> at org.jboss.cache.TreeCache.invokeMethod(TreeCache.java:2998)
> at org.jboss.cache.TreeCache.put(TreeCache.java:1657)
> at org.jboss.test.cache.test.local.TxDeadlockUnitTestCase$MyUpgrader._run(TxDeadlockUnitTestCase.java:346)
> at org.jboss.test.cache.test.local.TxDeadlockUnitTestCase$GenericThread.run(TxDeadlockUnitTestCase.java:213)
> at org.jboss.test.cache.test.local.TxDeadlockUnitTestCase$GenericThread.run(TxDeadlockUnitTestCase.java:213)
> and
> testConcurrentUpgrade():
> MyThread#1: get(/a/b/c)
> MyThread#2: get(/a/b/c)
> MyThread#2: done, locks:
> /a (read owners=[<null>:2])
> /b (read owners=[<null>:2])
> /c (read owners=[<null>:2])
> MyThread#1: done, locks:
> /a (read owners=[<null>:2, <null>:1])
> /b (read owners=[<null>:2, <null>:1])
> /c (read owners=[<null>:2, <null>:1])
> MyThread#2: put(/a/b/c)
> MyThread#1: put(/a/b/c)
> MyThread#1: org.jboss.cache.lock.LockingException: acquireWriteLock(): lock upgrade failed for /a/b/c (caller=<null>:1); - nested throwable: (org.jboss.cache.lock.UpgradeException: upgradeLockAttempt(): more than one reader trying to simultaneously upgrade to write lock)
> MyThread#2: org.jboss.cache.lock.TimeoutException: upgrade lock for /a/b/c could not be acquired after 3000 ms. Lock map ownership Read lock owners: [<null>:1]
> Write lock owner: null
> (caller=<null>:2)
> org.jboss.cache.lock.TimeoutException: upgrade lock for /a/b/c could not be acquired after 3000 ms. Lock map ownership Read lock owners: [<null>:1]
> Write lock owner: null
> (caller=<null>:2)
> at org.jboss.cache.lock.IdentityLock.acquireWriteLock(IdentityLock.java:155)
> at org.jboss.cache.Node.acquireWriteLock(Node.java:448)
> at org.jboss.cache.Node.acquire(Node.java:417)
> at org.jboss.cache.interceptors.LockInterceptor.lock(LockInterceptor.java:199)
> at org.jboss.cache.interceptors.LockInterceptor.invoke(LockInterceptor.java:144)
> at org.jboss.cache.interceptors.Interceptor.invoke(Interceptor.java:40)
> at org.jboss.cache.interceptors.CreateIfNotExistsInterceptor.invoke(CreateIfNotExistsInterceptor.java:145)
> at org.jboss.cache.interceptors.Interceptor.invoke(Interceptor.java:40)
> at org.jboss.cache.interceptors.UnlockInterceptor.invoke(UnlockInterceptor.java:35)
> at org.jboss.cache.TreeCache.invokeMethod(TreeCache.java:2998)
> at org.jboss.cache.TreeCache.put(TreeCache.java:1657)
> at org.jboss.test.cache.test.local.TxDeadlockUnitTestCase$MyThread._run(TxDeadlockUnitTestCase.java:317)
> at org.jboss.test.cache.test.local.TxDeadlockUnitTestCase$GenericThread.run(TxDeadlockUnitTestCase.java:213)
> at org.jboss.test.cache.test.local.TxDeadlockUnitTestCase$GenericThread.run(TxDeadlockUnitTestCase.java:213)
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
18 years, 12 months