[JBoss JIRA] Created: (JBCACHE-784) "Random" TimeoutException occurs after CacheLoader get() returns
6:21 a.m.
"Random" TimeoutException occurs after CacheLoader get() returns
----------------------------------------------------------------
Key: JBCACHE-784
URL: http://jira.jboss.com/jira/browse/JBCACHE-784
Project: JBoss Cache
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: Cache loaders
Affects Versions: 1.4.0
Environment: JBCache 1.4.0GA working in REPL_ASYNC mode on multiple Weblogic 8.1
instances (pessimistic locking), no eviction policy
Reporter: James Hickey
Assigned To: Manik Surtani
We experience a strange issue which happens every so often whereby shortly after one of
our replicated cache instances calls it's CacheLoader.get() to populate a particular
FQN, a TimeoutException occurs - It is extremely difficult to reproduce but the
scenario/stack trace follows:
The below exception is thrown 15 secs (configured timeout) AFTER the cache loader's
get() method successfully returns (can see this as we have debugging in the cache loader).
Subsequent calls are instantaneously successful and do not result in a further call to
the cacheloader.
It looks to me like it could possibly be some kind of tx/locking/thread contention issue,
as it happens more often than not where we have approx 10-20 threads which have all
resulted in a call to the cache loader in a short space of time.
Any advice/opinion would be appreciated
Thanks
James
org.jboss.cache.lock.TimeoutException: failure acquiring lock:
fqn=/demandload/db/gps/ipb/security/sdm/840/SECNO/DB0028807589, calle
r=GlobalTransaction:<10.152.103.22:28680>:363, lock=write
owner=GlobalTransaction:<10.152.103.22:28680>:362 (org.jboss.cache.lock.Lo
ckStrategyReadCommitted@10e4fd3)
at org.jboss.cache.Node.acquire(Node.java:407)
at
org.jboss.cache.interceptors.PessimisticLockInterceptor.lock(PessimisticLockInterceptor.java:231)
at
org.jboss.cache.interceptors.PessimisticLockInterceptor.invoke(PessimisticLockInterceptor.java:166)
at org.jboss.cache.interceptors.Interceptor.invoke(Interceptor.java:68)
at
org.jboss.cache.interceptors.CacheLoaderInterceptor.invoke(CacheLoaderInterceptor.java:197)
at org.jboss.cache.interceptors.Interceptor.invoke(Interceptor.java:68)
at
org.jboss.cache.interceptors.UnlockInterceptor.invoke(UnlockInterceptor.java:32)
at org.jboss.cache.interceptors.Interceptor.invoke(Interceptor.java:68)
at
org.jboss.cache.interceptors.ReplicationInterceptor.invoke(ReplicationInterceptor.java:34)
at org.jboss.cache.interceptors.Interceptor.invoke(Interceptor.java:68)
at
org.jboss.cache.interceptors.CacheStoreInterceptor.invoke(CacheStoreInterceptor.java:135)
at org.jboss.cache.interceptors.Interceptor.invoke(Interceptor.java:68)
at
org.jboss.cache.interceptors.TxInterceptor.handleNonTxMethod(TxInterceptor.java:345)
at org.jboss.cache.interceptors.TxInterceptor.invoke(TxInterceptor.java:156)
at org.jboss.cache.interceptors.Interceptor.invoke(Interceptor.java:68)
at
org.jboss.cache.interceptors.CacheMgmtInterceptor.invoke(CacheMgmtInterceptor.java:138)
at org.jboss.cache.TreeCache.invokeMethod(TreeCache.java:5535)
at org.jboss.cache.TreeCache.get(TreeCache.java:3485)
at org.jboss.cache.TreeCache.get(TreeCache.java:3466)
at org.jboss.cache.TreeCache.get(TreeCache.java:3453)
--
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
6:42 a.m.
New subject: [JBoss JIRA] Commented: (JBCACHE-784) "Random" TimeoutException occurs after CacheLoader get() returns
[ http://jira.jboss.com/jira/browse/JBCACHE-784?page=comments#action_12345039 ]
Manik Surtani commented on JBCACHE-784:
---------------------------------------
Have you tried this with 1.4.0.SP1?
"Random" TimeoutException occurs after CacheLoader get()
returns
----------------------------------------------------------------
Key: JBCACHE-784
URL: http://jira.jboss.com/jira/browse/JBCACHE-784
Project: JBoss Cache
Issue Type: Bug
Security Level: Public(Everyone can see)
Components: Cache loaders
Affects Versions: 1.4.0
Environment: JBCache 1.4.0GA working in REPL_ASYNC mode on multiple Weblogic 8.1
instances (pessimistic locking), no eviction policy
Reporter: James Hickey
Assigned To: Manik Surtani
We experience a strange issue which happens every so often whereby shortly after one of
our replicated cache instances calls it's CacheLoader.get() to populate a particular
FQN, a TimeoutException occurs - It is extremely difficult to reproduce but the
scenario/stack trace follows:
The below exception is thrown 15 secs (configured timeout) AFTER the cache loader's
get() method successfully returns (can see this as we have debugging in the cache loader).
Subsequent calls are instantaneously successful and do not result in a further call to
the cacheloader.
It looks to me like it could possibly be some kind of tx/locking/thread contention issue,
as it happens more often than not where we have approx 10-20 threads which have all
resulted in a call to the cache loader in a short space of time.
Any advice/opinion would be appreciated
Thanks
James
org.jboss.cache.lock.TimeoutException: failure acquiring lock:
fqn=/demandload/db/gps/ipb/security/sdm/840/SECNO/DB0028807589, calle
r=GlobalTransaction:<10.152.103.22:28680>:363, lock=write
owner=GlobalTransaction:<10.152.103.22:28680>:362 (org.jboss.cache.lock.Lo
ckStrategyReadCommitted@10e4fd3)
at org.jboss.cache.Node.acquire(Node.java:407)
at
org.jboss.cache.interceptors.PessimisticLockInterceptor.lock(PessimisticLockInterceptor.java:231)
at
org.jboss.cache.interceptors.PessimisticLockInterceptor.invoke(PessimisticLockInterceptor.java:166)
at org.jboss.cache.interceptors.Interceptor.invoke(Interceptor.java:68)
at
org.jboss.cache.interceptors.CacheLoaderInterceptor.invoke(CacheLoaderInterceptor.java:197)
at org.jboss.cache.interceptors.Interceptor.invoke(Interceptor.java:68)
at
org.jboss.cache.interceptors.UnlockInterceptor.invoke(UnlockInterceptor.java:32)
at org.jboss.cache.interceptors.Interceptor.invoke(Interceptor.java:68)
at
org.jboss.cache.interceptors.ReplicationInterceptor.invoke(ReplicationInterceptor.java:34)
at org.jboss.cache.interceptors.Interceptor.invoke(Interceptor.java:68)
at
org.jboss.cache.interceptors.CacheStoreInterceptor.invoke(CacheStoreInterceptor.java:135)
at org.jboss.cache.interceptors.Interceptor.invoke(Interceptor.java:68)
at
org.jboss.cache.interceptors.TxInterceptor.handleNonTxMethod(TxInterceptor.java:345)
at org.jboss.cache.interceptors.TxInterceptor.invoke(TxInterceptor.java:156)
at org.jboss.cache.interceptors.Interceptor.invoke(Interceptor.java:68)
at
org.jboss.cache.interceptors.CacheMgmtInterceptor.invoke(CacheMgmtInterceptor.java:138)
at org.jboss.cache.TreeCache.invokeMethod(TreeCache.java:5535)
at org.jboss.cache.TreeCache.get(TreeCache.java:3485)
at org.jboss.cache.TreeCache.get(TreeCache.java:3466)
at org.jboss.cache.TreeCache.get(TreeCache.java:3453)
--
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
7:06 a.m.
New subject: [JBoss JIRA] Commented: (JBCACHE-784) "Random" TimeoutException occurs after CacheLoader get() returns
[ http://jira.jboss.com/jira/browse/JBCACHE-784?page=comments#action_12345043 ]
James Hickey commented on JBCACHE-784:
--------------------------------------
Not yet - we plan to upgrade in about a month; we can wait until after the upgrade and
review if the problem still occurs
Thanks
James
"Random" TimeoutException occurs after CacheLoader get()
returns
----------------------------------------------------------------
Key: JBCACHE-784
URL: http://jira.jboss.com/jira/browse/JBCACHE-784
Project: JBoss Cache
Issue Type: Bug
Security Level: Public(Everyone can see)
Components: Cache loaders
Affects Versions: 1.4.0
Environment: JBCache 1.4.0GA working in REPL_ASYNC mode on multiple Weblogic 8.1
instances (pessimistic locking), no eviction policy
Reporter: James Hickey
Assigned To: Manik Surtani
We experience a strange issue which happens every so often whereby shortly after one of
our replicated cache instances calls it's CacheLoader.get() to populate a particular
FQN, a TimeoutException occurs - It is extremely difficult to reproduce but the
scenario/stack trace follows:
The below exception is thrown 15 secs (configured timeout) AFTER the cache loader's
get() method successfully returns (can see this as we have debugging in the cache loader).
Subsequent calls are instantaneously successful and do not result in a further call to
the cacheloader.
It looks to me like it could possibly be some kind of tx/locking/thread contention issue,
as it happens more often than not where we have approx 10-20 threads which have all
resulted in a call to the cache loader in a short space of time.
Any advice/opinion would be appreciated
Thanks
James
org.jboss.cache.lock.TimeoutException: failure acquiring lock:
fqn=/demandload/db/gps/ipb/security/sdm/840/SECNO/DB0028807589, calle
r=GlobalTransaction:<10.152.103.22:28680>:363, lock=write
owner=GlobalTransaction:<10.152.103.22:28680>:362 (org.jboss.cache.lock.Lo
ckStrategyReadCommitted@10e4fd3)
at org.jboss.cache.Node.acquire(Node.java:407)
at
org.jboss.cache.interceptors.PessimisticLockInterceptor.lock(PessimisticLockInterceptor.java:231)
at
org.jboss.cache.interceptors.PessimisticLockInterceptor.invoke(PessimisticLockInterceptor.java:166)
at org.jboss.cache.interceptors.Interceptor.invoke(Interceptor.java:68)
at
org.jboss.cache.interceptors.CacheLoaderInterceptor.invoke(CacheLoaderInterceptor.java:197)
at org.jboss.cache.interceptors.Interceptor.invoke(Interceptor.java:68)
at
org.jboss.cache.interceptors.UnlockInterceptor.invoke(UnlockInterceptor.java:32)
at org.jboss.cache.interceptors.Interceptor.invoke(Interceptor.java:68)
at
org.jboss.cache.interceptors.ReplicationInterceptor.invoke(ReplicationInterceptor.java:34)
at org.jboss.cache.interceptors.Interceptor.invoke(Interceptor.java:68)
at
org.jboss.cache.interceptors.CacheStoreInterceptor.invoke(CacheStoreInterceptor.java:135)
at org.jboss.cache.interceptors.Interceptor.invoke(Interceptor.java:68)
at
org.jboss.cache.interceptors.TxInterceptor.handleNonTxMethod(TxInterceptor.java:345)
at org.jboss.cache.interceptors.TxInterceptor.invoke(TxInterceptor.java:156)
at org.jboss.cache.interceptors.Interceptor.invoke(Interceptor.java:68)
at
org.jboss.cache.interceptors.CacheMgmtInterceptor.invoke(CacheMgmtInterceptor.java:138)
at org.jboss.cache.TreeCache.invokeMethod(TreeCache.java:5535)
at org.jboss.cache.TreeCache.get(TreeCache.java:3485)
at org.jboss.cache.TreeCache.get(TreeCache.java:3466)
at org.jboss.cache.TreeCache.get(TreeCache.java:3453)
--
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
11:30 a.m.
New subject: [JBoss JIRA] Commented: (JBCACHE-784) "Random" TimeoutException occurs after CacheLoader get() returns
[ http://jira.jboss.com/jira/browse/JBCACHE-784?page=comments#action_12345803 ]
Projet GAC commented on JBCACHE-784:
------------------------------------
Hi,
We experience the same kinf of issue on a project with JBCache 1.4.0.SP1 working in
REPL_ASYNC mode on multiple Weblogic 8.1 instances (pessimistic locking), with an eviction
policy, running on 25 threads.
Here are the logs generated:
org.jboss.cache.lock.TimeoutException: failure acquiring lock:
fqn=/Client/10002055250/accessType,
caller=GlobalTransaction:<172.23.70.77:44921>:13, lock=write
owner=GlobalTransaction:<172.23.70.77:44921>:10 (activeReaders=0,
activeWriter=Thread[ExecuteThread: '24' for queue: 'gac.Client',5,Thread
Group for Queue: 'gac.Client'], waitingReaders=0, waitingWriters=0,
waitingUpgrader=0)
at org.jboss.cache.Node.acquire(Node.java:407)
at
org.jboss.cache.interceptors.PessimisticLockInterceptor.lock(PessimisticLockInterceptor.java:228)
at
org.jboss.cache.interceptors.PessimisticLockInterceptor.invoke(PessimisticLockInterceptor.java:160)
at org.jboss.cache.interceptors.Interceptor.invoke(Interceptor.java:68)
at org.jboss.cache.interceptors.UnlockInterceptor.invoke(UnlockInterceptor.java:32)
at org.jboss.cache.interceptors.Interceptor.invoke(Interceptor.java:68)
at
org.jboss.cache.interceptors.ReplicationInterceptor.invoke(ReplicationInterceptor.java:34)
at org.jboss.cache.interceptors.Interceptor.invoke(Interceptor.java:68)
at org.jboss.cache.interceptors.TxInterceptor.handleNonTxMethod(TxInterceptor.java:345)
at org.jboss.cache.interceptors.TxInterceptor.invoke(TxInterceptor.java:156)
at org.jboss.cache.interceptors.Interceptor.invoke(Interceptor.java:68)
at
org.jboss.cache.interceptors.CacheMgmtInterceptor.invoke(CacheMgmtInterceptor.java:157)
at org.jboss.cache.TreeCache.invokeMethod(TreeCache.java:5520)
at org.jboss.cache.TreeCache.put(TreeCache.java:3678)
at org.jboss.cache.aop.PojoCache.lockPojo(PojoCache.java:628)
at org.jboss.cache.aop.PojoCache.putObject(PojoCache.java:442)
at org.jboss.cache.aop.CacheInterceptor.invoke(CacheInterceptor.java:115)
at org.jboss.aop.joinpoint.FieldWriteInvocation.invokeNext(FieldWriteInvocation.java:51)
at
com.bouygtel.gac.socle.client.cache.entite.client.CacheClientEntite.accessType_w_$aop(CacheClientEntite.java)
at
com.bouygtel.gac.socle.client.cache.entite.client.CacheClientEntite.setAccessType(CacheClientEntite.java:57)
at
com.bouygtel.gac.socle.client.cache.aop.dao.TreeCacheDAO.rechercherClientTravailPourProcessus(TreeCacheDAO.java:1460)
at
com.bouygtel.gac.socle.client.cache.CacheManager.rechercherClientTravailPourProcessus(CacheManager.java:215)
at
com.bouygtel.gac.socle.client.metier.PosteurDemande.posterDemande(PosteurDemande.java:59)
at
com.bouygtel.gac.socle.client.metier.MgrClientImpl.validerDemandeAction(MgrClientImpl.java:1663)
at
com.bouygtel.gac.socle.client.ejb.MgrClientEjb.validerDemandeAction(MgrClientEjb.java:263)
at
com.bouygtel.gac.socle.client.ejb.MgrClientEjb_u974l0_EOImpl.validerDemandeAction(MgrClientEjb_u974l0_EOImpl.java:732)
at com.bouygtel.gac.socle.client.ejb.MgrClientEjb_u974l0_EOImpl_WLSkel.invoke(Unknown
Source)
at weblogic.rmi.internal.BasicServerRef.invoke(BasicServerRef.java:477)
at weblogic.rmi.cluster.ReplicaAwareServerRef.invoke(ReplicaAwareServerRef.java:108)
at weblogic.rmi.internal.BasicServerRef$1.run(BasicServerRef.java:420)
at
weblogic.security.acl.internal.AuthenticatedSubject.doAs(AuthenticatedSubject.java:363)
at weblogic.security.service.SecurityManager.runAs(SecurityManager.java:144)
at weblogic.rmi.internal.BasicServerRef.handleRequest(BasicServerRef.java:415)
at weblogic.rmi.internal.BasicExecuteRequest.execute(BasicExecuteRequest.java:30)
at weblogic.kernel.ExecuteThread.execute(ExecuteThread.java:219)
at weblogic.kernel.ExecuteThread.run(ExecuteThread.java:178)
Do you have any suggestion/comment?
Thanks,
Jeff
"Random" TimeoutException occurs after CacheLoader get()
returns
----------------------------------------------------------------
Key: JBCACHE-784
URL: http://jira.jboss.com/jira/browse/JBCACHE-784
Project: JBoss Cache
Issue Type: Bug
Security Level: Public(Everyone can see)
Components: Cache loaders
Affects Versions: 1.4.0
Environment: JBCache 1.4.0GA working in REPL_ASYNC mode on multiple Weblogic 8.1
instances (pessimistic locking), no eviction policy
Reporter: James Hickey
Assigned To: Manik Surtani
We experience a strange issue which happens every so often whereby shortly after one of
our replicated cache instances calls it's CacheLoader.get() to populate a particular
FQN, a TimeoutException occurs - It is extremely difficult to reproduce but the
scenario/stack trace follows:
The below exception is thrown 15 secs (configured timeout) AFTER the cache loader's
get() method successfully returns (can see this as we have debugging in the cache loader).
Subsequent calls are instantaneously successful and do not result in a further call to
the cacheloader.
It looks to me like it could possibly be some kind of tx/locking/thread contention issue,
as it happens more often than not where we have approx 10-20 threads which have all
resulted in a call to the cache loader in a short space of time.
Any advice/opinion would be appreciated
Thanks
James
org.jboss.cache.lock.TimeoutException: failure acquiring lock:
fqn=/demandload/db/gps/ipb/security/sdm/840/SECNO/DB0028807589, calle
r=GlobalTransaction:<10.152.103.22:28680>:363, lock=write
owner=GlobalTransaction:<10.152.103.22:28680>:362 (org.jboss.cache.lock.Lo
ckStrategyReadCommitted@10e4fd3)
at org.jboss.cache.Node.acquire(Node.java:407)
at
org.jboss.cache.interceptors.PessimisticLockInterceptor.lock(PessimisticLockInterceptor.java:231)
at
org.jboss.cache.interceptors.PessimisticLockInterceptor.invoke(PessimisticLockInterceptor.java:166)
at org.jboss.cache.interceptors.Interceptor.invoke(Interceptor.java:68)
at
org.jboss.cache.interceptors.CacheLoaderInterceptor.invoke(CacheLoaderInterceptor.java:197)
at org.jboss.cache.interceptors.Interceptor.invoke(Interceptor.java:68)
at
org.jboss.cache.interceptors.UnlockInterceptor.invoke(UnlockInterceptor.java:32)
at org.jboss.cache.interceptors.Interceptor.invoke(Interceptor.java:68)
at
org.jboss.cache.interceptors.ReplicationInterceptor.invoke(ReplicationInterceptor.java:34)
at org.jboss.cache.interceptors.Interceptor.invoke(Interceptor.java:68)
at
org.jboss.cache.interceptors.CacheStoreInterceptor.invoke(CacheStoreInterceptor.java:135)
at org.jboss.cache.interceptors.Interceptor.invoke(Interceptor.java:68)
at
org.jboss.cache.interceptors.TxInterceptor.handleNonTxMethod(TxInterceptor.java:345)
at org.jboss.cache.interceptors.TxInterceptor.invoke(TxInterceptor.java:156)
at org.jboss.cache.interceptors.Interceptor.invoke(Interceptor.java:68)
at
org.jboss.cache.interceptors.CacheMgmtInterceptor.invoke(CacheMgmtInterceptor.java:138)
at org.jboss.cache.TreeCache.invokeMethod(TreeCache.java:5535)
at org.jboss.cache.TreeCache.get(TreeCache.java:3485)
at org.jboss.cache.TreeCache.get(TreeCache.java:3466)
at org.jboss.cache.TreeCache.get(TreeCache.java:3453)
--
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
6:40 a.m.
New subject: [JBoss JIRA] Closed: (JBCACHE-784) "Random" TimeoutException occurs after CacheLoader get() returns
[ http://jira.jboss.com/jira/browse/JBCACHE-784?page=all ]
Manik Surtani closed JBCACHE-784.
---------------------------------
Resolution: Rejected
I suspect this has more to do with the isolation level preventing the loader from
accessing the node when someone else has a stronger exclusive lock.
Lock acquisition timeouts could occur with any concurrent access to nodes, regardless of
whether it is a cache loader, remote invocation or even client code.
"Random" TimeoutException occurs after CacheLoader get()
returns
----------------------------------------------------------------
Key: JBCACHE-784
URL: http://jira.jboss.com/jira/browse/JBCACHE-784
Project: JBoss Cache
Issue Type: Bug
Security Level: Public(Everyone can see)
Components: Cache loaders
Affects Versions: 1.4.0.GA
Environment: JBCache 1.4.0GA working in REPL_ASYNC mode on multiple Weblogic 8.1
instances (pessimistic locking), no eviction policy
Reporter: James Hickey
Assigned To: Manik Surtani
We experience a strange issue which happens every so often whereby shortly after one of
our replicated cache instances calls it's CacheLoader.get() to populate a particular
FQN, a TimeoutException occurs - It is extremely difficult to reproduce but the
scenario/stack trace follows:
The below exception is thrown 15 secs (configured timeout) AFTER the cache loader's
get() method successfully returns (can see this as we have debugging in the cache loader).
Subsequent calls are instantaneously successful and do not result in a further call to
the cacheloader.
It looks to me like it could possibly be some kind of tx/locking/thread contention issue,
as it happens more often than not where we have approx 10-20 threads which have all
resulted in a call to the cache loader in a short space of time.
Any advice/opinion would be appreciated
Thanks
James
org.jboss.cache.lock.TimeoutException: failure acquiring lock:
fqn=/demandload/db/gps/ipb/security/sdm/840/SECNO/DB0028807589, calle
r=GlobalTransaction:<10.152.103.22:28680>:363, lock=write
owner=GlobalTransaction:<10.152.103.22:28680>:362 (org.jboss.cache.lock.Lo
ckStrategyReadCommitted@10e4fd3)
at org.jboss.cache.Node.acquire(Node.java:407)
at
org.jboss.cache.interceptors.PessimisticLockInterceptor.lock(PessimisticLockInterceptor.java:231)
at
org.jboss.cache.interceptors.PessimisticLockInterceptor.invoke(PessimisticLockInterceptor.java:166)
at org.jboss.cache.interceptors.Interceptor.invoke(Interceptor.java:68)
at
org.jboss.cache.interceptors.CacheLoaderInterceptor.invoke(CacheLoaderInterceptor.java:197)
at org.jboss.cache.interceptors.Interceptor.invoke(Interceptor.java:68)
at
org.jboss.cache.interceptors.UnlockInterceptor.invoke(UnlockInterceptor.java:32)
at org.jboss.cache.interceptors.Interceptor.invoke(Interceptor.java:68)
at
org.jboss.cache.interceptors.ReplicationInterceptor.invoke(ReplicationInterceptor.java:34)
at org.jboss.cache.interceptors.Interceptor.invoke(Interceptor.java:68)
at
org.jboss.cache.interceptors.CacheStoreInterceptor.invoke(CacheStoreInterceptor.java:135)
at org.jboss.cache.interceptors.Interceptor.invoke(Interceptor.java:68)
at
org.jboss.cache.interceptors.TxInterceptor.handleNonTxMethod(TxInterceptor.java:345)
at org.jboss.cache.interceptors.TxInterceptor.invoke(TxInterceptor.java:156)
at org.jboss.cache.interceptors.Interceptor.invoke(Interceptor.java:68)
at
org.jboss.cache.interceptors.CacheMgmtInterceptor.invoke(CacheMgmtInterceptor.java:138)
at org.jboss.cache.TreeCache.invokeMethod(TreeCache.java:5535)
at org.jboss.cache.TreeCache.get(TreeCache.java:3485)
at org.jboss.cache.TreeCache.get(TreeCache.java:3466)
at org.jboss.cache.TreeCache.get(TreeCache.java:3453)
--
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
6964
days inactive
7177
days old
4 comments
4 participants
participants (4)
-
James Hickey (JIRA) -
Manik Surtani (JIRA) -
Manik Surtani (JIRA)
-
Projet GAC (JIRA)