[JBoss JIRA] Created: (ISPN-320) cache.get() takes some times 15 seconds to execute
by Juha Heljoranta (JIRA)
cache.get() takes some times 15 seconds to execute
---------------------------------------------------
Key: ISPN-320
URL: https://jira.jboss.org/jira/browse/ISPN-320
Project: Infinispan
Issue Type: Bug
Environment: jgroups.bind_addr = null
bind.address = 127.0.0.1
java.runtime.version = 1.6.0_0-b16
java.runtime.name =OpenJDK Runtime Environment
java.vm.version = 14.0-b16
java.vm.vendor = Sun Microsystems Inc.
os.name = Linux
os.version = 2.6.31.6-166.fc12.x86_64
sun.arch.data.model = 64
sun.cpu.endian = little
protocol.stack = tcp
java.net.preferIPv4Stack = true
java.net.preferIPv6Stack = null
MAVEN_OPTS = null
Reporter: Juha Heljoranta
Assignee: Manik Surtani
cache.get() can get stuck for 15 seconds before returning. Trace level logging reveals: org.jgroups.blocks.GroupRequest - call did not execute correctly.
--
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
14 years, 10 months
[JBoss JIRA] Created: (ISPN-296) Attempting to remove a non-existent item from the cache that is part of Hibernate throws NullPointerException
by Bryan Grunow (JIRA)
Attempting to remove a non-existent item from the cache that is part of Hibernate throws NullPointerException
-------------------------------------------------------------------------------------------------------------
Key: ISPN-296
URL: https://jira.jboss.org/jira/browse/ISPN-296
Project: Infinispan
Issue Type: Bug
Components: Lucene Directory, Querying
Affects Versions: 4.0.0.CR2
Reporter: Bryan Grunow
Assignee: Manik Surtani
Here is the execpetion generated when trying to remove an item from the cache that doesn't exist.
javax.transaction.RollbackException: [com.arjuna.ats.internal.jta.transaction.arjunacore.commitwhenaborted] [com.arjuna.ats.internal.jta.transaction.arjunacore.commitwhenaborted] Could not commit transaction.
at com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionImple.commitAndDisassociate(TransactionImple.java:1398)
at com.arjuna.ats.internal.jta.transaction.arjunacore.BaseTransaction.commit(BaseTransaction.java:138)
at BasicGridTests.removeTest(BasicGridTests.java:373)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:44)
at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:15)
at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:41)
at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:20)
at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:28)
at org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:31)
at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:73)
at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:46)
at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:180)
at org.junit.runners.ParentRunner.access$000(ParentRunner.java:41)
at org.junit.runners.ParentRunner$1.evaluate(ParentRunner.java:173)
at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:28)
at org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:31)
at org.junit.runners.ParentRunner.run(ParentRunner.java:220)
at org.eclipse.jdt.internal.junit4.runner.JUnit4TestReference.run(JUnit4TestReference.java:45)
at org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38)
at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:460)
at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:673)
at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:386)
at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:196)
Caused by: java.lang.NullPointerException
at org.hibernate.Hibernate.getClass(Hibernate.java:369)
at org.hibernate.search.backend.impl.BatchedQueueingProcessor.addWorkToBuilderQueue(BatchedQueueingProcessor.java:148)
at org.hibernate.search.backend.impl.BatchedQueueingProcessor.processWorkByLayer(BatchedQueueingProcessor.java:140)
at org.hibernate.search.backend.impl.BatchedQueueingProcessor.prepareWorks(BatchedQueueingProcessor.java:128)
at org.hibernate.search.backend.impl.PostTransactionWorkQueueSynchronization.beforeCompletion(PostTransactionWorkQueueSynchronization.java:40)
at com.arjuna.ats.internal.jta.resources.arjunacore.SynchronizationImple.beforeCompletion(SynchronizationImple.java:101)
at com.arjuna.ats.arjuna.coordinator.TwoPhaseCoordinator.beforeCompletion(TwoPhaseCoordinator.java:269)
at com.arjuna.ats.arjuna.coordinator.TwoPhaseCoordinator.end(TwoPhaseCoordinator.java:89)
at com.arjuna.ats.arjuna.AtomicAction.commit(AtomicAction.java:176)
at com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionImple.commitAndDisassociate(TransactionImple.java:1386)
... 26 more
--
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
14 years, 10 months
[JBoss JIRA] Created: (ISPN-336) Entries loaded via loadAll not being checked for expiration
by Galder Zamarreno (JIRA)
Entries loaded via loadAll not being checked for expiration
-----------------------------------------------------------
Key: ISPN-336
URL: https://jira.jboss.org/jira/browse/ISPN-336
Project: Infinispan
Issue Type: Bug
Components: Loaders and Stores
Affects Versions: 4.0.0.CR3
Reporter: Galder Zamarreno
Assignee: Galder Zamarreno
Fix For: 4.0.0.GA
Those keys loaded initially from CacheLoader via loadAll method do not obey expiration rules unless they are modified. Just after first change they expire following lifespan and maxIdle values.
It's interesting that we do check for expiration in some cases such as BucketBasedCacheStore when loading an individual. We should probably do it regardless of the type of cache loader used. IOW, we should probably move the check to CacheLoaderInterceptor or similar.
--
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
14 years, 11 months