[JBoss JIRA] (ISPN-3766) WriteSkewException
by V L (JIRA)
V L created ISPN-3766:
-------------------------
Summary: WriteSkewException
Key: ISPN-3766
URL: https://issues.jboss.org/browse/ISPN-3766
Project: Infinispan
Issue Type: Bug
Components: Transactions
Affects Versions: 6.0.0.Final, 6.0.0.CR1, 5.3.0.Final
Reporter: V L
Assignee: Mircea Markus
I'm not new with Infinispan, we use it from 5.3 version. Now I'm working on integrating WriteSkew functional in our project, but unfortunately it's not worked properly in our situation.
We use infinispan like a "cache" for some data source (doesn't matter for what)
The problem is that WriteSkewException is available in specific situation, here are steps for reproducing:
1) begin tx -> create an new element -> commit tx.
2) wait until cache expires. cache is empty now
3) being tx -> try to get element from cache, but it isn't found, so loading element from data source and put it to the cache via putForExternalRead for read access outside of current transaction.
4) make some modification with element -> put element to cache -> commit tx
Commit operation throws WriteSkewException
Here is log:
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
10 years, 5 months
[JBoss JIRA] (ISPN-3316) CDI Cache interceptor tests are failing while running in EAP container
by Pedro Ruivo (JIRA)
[ https://issues.jboss.org/browse/ISPN-3316?page=com.atlassian.jira.plugin.... ]
Pedro Ruivo updated ISPN-3316:
------------------------------
Status: Resolved (was: Pull Request Sent)
Resolution: Done
> CDI Cache interceptor tests are failing while running in EAP container
> ----------------------------------------------------------------------
>
> Key: ISPN-3316
> URL: https://issues.jboss.org/browse/ISPN-3316
> Project: Infinispan
> Issue Type: Bug
> Components: CDI integration
> Affects Versions: 5.3.0.Final, 6.0.0.Final
> Reporter: Anna Manukyan
> Assignee: Galder Zamarreño
> Labels: 620
> Fix For: 6.1.0.Final
>
>
> While migration of the CDI related tests to work under EAP container (at the moment using 6.0.GA), it was found that the tests related to interceptors are failing. The issue relates to
> org.infinispan.cdi.test.interceptor.CachePutInterceptorTest, org.infinispan.cdi.test.interceptor.CacheRemoveAllInterceptorTest, org.infinispan.cdi.test.interceptor.CacheRemoveInterceptorTest, org.infinispan.cdi.test.interceptor.CacheResultInterceptorTest.
> The failure relates to assertions. The thing is that all actions which are done using javax.cache.cache-api annotations, work properly (I've added some logs e.g. in CachePutInterceptor, and it shows that the data is put to the cache properly).
> But later when the test wants to verify that the data is really put to the data, retrieves the cache from the injected CacheContainer, the cache is empty - the data is not there.
> The issue appeared since the latest changes to the Infinispan-CDI module, and split to infinispan-jcache module. For the previous version, the tests are passed under EAP container.
> The example above was given for the CachePutInterceptorTest, but the same refers to the rest of them.
> The git repo for the sources, will be provided later.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
10 years, 5 months
[JBoss JIRA] (ISPN-3756) Unnecessary wall clock call for immortal entries
by Pedro Ruivo (JIRA)
[ https://issues.jboss.org/browse/ISPN-3756?page=com.atlassian.jira.plugin.... ]
Pedro Ruivo updated ISPN-3756:
------------------------------
Status: Resolved (was: Pull Request Sent)
Resolution: Done
> Unnecessary wall clock call for immortal entries
> ------------------------------------------------
>
> Key: ISPN-3756
> URL: https://issues.jboss.org/browse/ISPN-3756
> Project: Infinispan
> Issue Type: Bug
> Affects Versions: 6.0.0.Final
> Reporter: Galder Zamarreño
> Assignee: Galder Zamarreño
> Fix For: 6.1.0.Final
>
>
> When updating immortal entries Infinispan calls up the wall clock time unnecessarily.
> {code}
> if (e != null) {
> e.setValue(v);
> InternalCacheEntry original = e;
> e = entryFactory.update(e, metadata);
> // we have the same instance. So we need to reincarnate.
> if (original == e) {
> --> e.reincarnate(timeService.wallClockTime());
> }
> } else {
> // this is a brand-new entry
> e = entryFactory.create(k, v, metadata);
> }
> {code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
10 years, 5 months
[JBoss JIRA] (ISPN-800) Infinispan inside OSGI
by Luca Stancapiano (JIRA)
[ https://issues.jboss.org/browse/ISPN-800?page=com.atlassian.jira.plugin.s... ]
Luca Stancapiano commented on ISPN-800:
---------------------------------------
Hi Tristan.... it should be ok.... you can try to install infinispan in a osgi repository as jboss 7 or felix and step by step add the requested dependencies. All the dependencies are osgi bundle.
> Infinispan inside OSGI
> ----------------------
>
> Key: ISPN-800
> URL: https://issues.jboss.org/browse/ISPN-800
> Project: Infinispan
> Issue Type: Feature Request
> Components: Core API
> Reporter: Luca Stancapiano
> Assignee: Galder Zamarreño
>
> We need to import infinispan inside a OSGI repository. Tests are made with Felix.
> I added the configuration to use infinispan inside a osgi repository. We need to ignore all listed dependencies. With this configuration we can install infinispan-core.jar inside OSGI. Its achievement will be as a base installation here: https://github.com/flashboss/infinispan
> I added the Import-Package because you are forced to put manually in Felix all dependencies as jgroups, jboss marshalling, jcip, all apache commons. I've seen infinispan core working by default without all those libraries, so I think the same achievement should be replicated in OSGI.
> Inside the Import-Package tag I excluded those libraries so Infinispan core can be started in default mode without errors. If we want use the replication in OSGI, it is enough add manually the other packages (jgroups.jar etc etc)
> Actually the core bundle can be installed. But to be used it needs theese projects be installed as osgi bundles:
> jboss transaction api 1.0.1.GA
> We patched it. There is a new OSGI version here: https://repository.jboss.org/nexus/content/groups/public/org/jboss/spec/j... )
> jgroups 2.10.1.GA
> (it's a osgi bundle since the 3.x version)
> river 1.2.3.GA
> (opened an issue for marshalling 1.4.0 in JBMAR-118 and https://github.com/flashboss/jboss-marshalling/blob/master/river/pom.xml )
> marshalling-api 1.2.3.GA
> (opened an issue for marshalling 1.4.0 in JBMAR-118 and https://github.com/flashboss/jboss-marshalling/blob/master/api/pom.xml )
> jboss logging spi 2.0.5.GA
> (added a jira issue in JBLOGGING-51 . It could be fixed in the 2.2.0.CR2 version. Fixed in the 3.x version)
> rhq plugin annotations 1.4.0.B01
> (opened a feature request in https://bugzilla.redhat.com/show_bug.cgi?id=657754 )
> i18nlog 1.0.9
> (sent a patch in https://sourceforge.net/projects/i18nlog . It could become a OSGI bundle in the 1.0.10 version. Waiting for a response. Fixed in 1.15)
> log4j 1.2.16
> (that's ok...it is a osgi bundle ;))
> jcip-annotations 1.0
> (I sent a patch via email to brian(a)briangoetz.com and a post in http://tembrel.blogspot.com. Sent the patch in concurrency-interest(a)cs.oswego.edu too. They responded to me. There is a OSGI version with a different artifact name. I changed the dependency in the pom.xml of the parent project)
> We should make sure proper 'Import-Package' property is specified in the MANIFEST.MF so that:
> 1- it fails to load obviously when there's any missing bundles that are essential in using the very core functionality of Infinispan.
> 2 - it does not fail due to the dependency that is not really essential.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
10 years, 5 months
[JBoss JIRA] (ISPN-3765) SingleFileStoreStressTest.testWritesAndClear && SingleFileStoreFunctionalTest.testParsingEmptyElement fail with IBM6 JDK
by Vitalii Chepeliuk (JIRA)
[ https://issues.jboss.org/browse/ISPN-3765?page=com.atlassian.jira.plugin.... ]
Vitalii Chepeliuk updated ISPN-3765:
------------------------------------
Attachment: traces.zip
Add traces for this 2 tests
> SingleFileStoreStressTest.testWritesAndClear && SingleFileStoreFunctionalTest.testParsingEmptyElement fail with IBM6 JDK
> ------------------------------------------------------------------------------------------------------------------------
>
> Key: ISPN-3765
> URL: https://issues.jboss.org/browse/ISPN-3765
> Project: Infinispan
> Issue Type: Bug
> Components: Loaders and Stores
> Affects Versions: 6.0.0.Final
> Environment: RHEL6x86 IBM6
> Reporter: Vitalii Chepeliuk
> Assignee: Mircea Markus
> Labels: testsuite_stability
> Attachments: traces.zip
>
>
> Following exception is thrown
> java.util.concurrent.ExecutionException: java.lang.Exception: org.infinispan.persistence.spi.PersistenceException: java.lang.NullPointerException
> at java.util.concurrent.FutureTask$Sync.innerGet(FutureTask.java:233)
> at java.util.concurrent.FutureTask.get(FutureTask.java:94)
> at org.infinispan.persistence.file.SingleFileStoreStressTest.testWritesAndClear(SingleFileStoreStressTest.java:127)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:60)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:37)
> at java.lang.reflect.Method.invoke(Method.java:611)
> at org.testng.internal.MethodInvocationHelper.invokeMethod(MethodInvocationHelper.java:80)
> at org.testng.internal.Invoker.invokeMethod(Invoker.java:715)
> at org.testng.internal.Invoker.invokeTestMethod(Invoker.java:907)
> at org.testng.internal.Invoker.invokeTestMethods(Invoker.java:1237)
> at org.testng.internal.TestMethodWorker.invokeTestMethods(TestMethodWorker.java:127)
> at org.testng.internal.TestMethodWorker.run(TestMethodWorker.java:111)
> at org.testng.TestRunner.privateRun(TestRunner.java:767)
> at org.testng.TestRunner.run(TestRunner.java:617)
> at org.testng.SuiteRunner.runTest(SuiteRunner.java:334)
> at org.testng.SuiteRunner.access$000(SuiteRunner.java:37)
> at org.testng.SuiteRunner$SuiteWorker.run(SuiteRunner.java:368)
> at org.testng.internal.thread.ThreadUtil$2.call(ThreadUtil.java:64)
> at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:314)
> at java.util.concurrent.FutureTask.run(FutureTask.java:149)
> at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:908)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:931)
> at java.lang.Thread.run(Thread.java:738)
> Caused by: java.lang.Exception: org.infinispan.persistence.spi.PersistenceException: java.lang.NullPointerException
> at org.infinispan.persistence.file.SingleFileStoreStressTest$StopOnExceptionTask.call(SingleFileStoreStressTest.java:257)
> at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:314)
> at java.util.concurrent.FutureTask.run(FutureTask.java:149)
> ... 1 more
> Caused by: org.infinispan.persistence.spi.PersistenceException: java.lang.NullPointerException
> at org.infinispan.persistence.file.SingleFileStore.write(SingleFileStore.java:317)
> at org.infinispan.persistence.file.SingleFileStoreStressTest$WriteTask.call(SingleFileStoreStressTest.java:169)
> at org.infinispan.persistence.file.SingleFileStoreStressTest$StopOnExceptionTask.call(SingleFileStoreStressTest.java:254)
> ... 3 more
> Caused by: java.lang.NullPointerException
> at java.util.TreeMap$AbstractSubMapIterator.remove(TreeMap.java:218)
> at org.infinispan.persistence.file.SingleFileStore.allocate(SingleFileStore.java:242)
> at org.infinispan.persistence.file.SingleFileStore.write(SingleFileStore.java:284)
> ... 5 more
> You can check all 5 builds were running here
> https://jenkins.mw.lab.eng.bos.redhat.com/hudson/view/JDG/view/FUNC/job/e...
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
10 years, 5 months
[JBoss JIRA] (ISPN-3364) Tests from org.infinispan.atomic package fail with AssertionError
by William Burns (JIRA)
[ https://issues.jboss.org/browse/ISPN-3364?page=com.atlassian.jira.plugin.... ]
William Burns commented on ISPN-3364:
-------------------------------------
I was finally able to reproduce this in a way that I could debug to see what is going on. And needless to say that hasn't even helped.
In testing the ReplDeltaAwarePassivationTest I was able to narrow the culprit down to a single line where things were not working.
In BoundedConcurrentHashMap:1719 it is finally assigning the new entry to the array. For some reason this affects both the DataContainer and the DummyInMemoryCacheStore entries maps and ends up removing the additional element. Looking at all the references between the dc and store there is nothing shared in the map and doesn't make much sense as to why this occurs. I have tried changing the hash maps that are used in both the DataContainer and DummyStore to use different implementations respectively but it hasn't change the outcome either.
I haven't been able to reproduce the LocalDeltaAwarePassivationTest issue yet as it only is reproducible in a full maven run with all the tests.
> Tests from org.infinispan.atomic package fail with AssertionError
> -----------------------------------------------------------------
>
> Key: ISPN-3364
> URL: https://issues.jboss.org/browse/ISPN-3364
> Project: Infinispan
> Issue Type: Bug
> Components: Core API
> Affects Versions: 6.0.0.Alpha1
> Environment: RHEL5_x86, RHEL5_x86_64, RHEL6_x86, RHEL5_x86_64 with IBM JDK7
> Reporter: Vitalii Chepeliuk
> Assignee: William Burns
> Labels: 620
> Attachments: LocalDeltaAwarePassivationTest.log.zip, ReplDeltaAwarePassivationTest.log.zip
>
>
> Following tests fail from org.infinispan.atomic package
> org.infinispan.atomic.LocalDeltaAwarePassivationTest.testAtomicMap
> org.infinispan.atomic.LocalDeltaAwarePassivationTest.testDeltaAware
> org.infinispan.atomic.LocalDeltaAwarePassivationTest.testFineGrainedAtomicMap
> org.infinispan.atomic.ReplDeltaAwarePassivationTest.testAtomicMap
> org.infinispan.atomic.ReplDeltaAwarePassivationTest.testAtomicMap2
> org.infinispan.atomic.ReplDeltaAwarePassivationTest.testDeltaAware
> org.infinispan.atomic.ReplDeltaAwarePassivationTest.testDeltaAware2
> org.infinispan.atomic.ReplDeltaAwarePassivationTest.testFineGrainedAtomicMap
> org.infinispan.atomic.ReplDeltaAwarePassivationTest.testFineGrainedAtomicMap2
> Add link on jenkins job https://jenkins.mw.lab.eng.bos.redhat.com/hudson/view/JDG/view/FUNC/job/e...
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
10 years, 5 months
[JBoss JIRA] (ISPN-3736) Backport to 5.2.x for EAP 6.3
by Paul Ferraro (JIRA)
[ https://issues.jboss.org/browse/ISPN-3736?page=com.atlassian.jira.plugin.... ]
Paul Ferraro commented on ISPN-3736:
------------------------------------
In general, I'm not in the habit of interacting with QE teams from other products when upstream issues that affect EAP. This should not be surprising as the EAP and JDG QE teams test a different set of use cases. It is the responsibility of the Infinispan team to collaborate and manage the release streams for their supported downstream products.
> Backport to 5.2.x for EAP 6.3
> -----------------------------
>
> Key: ISPN-3736
> URL: https://issues.jboss.org/browse/ISPN-3736
> Project: Infinispan
> Issue Type: Task
> Affects Versions: 5.2.7.Final
> Reporter: Paul Ferraro
> Assignee: Mircea Markus
> Fix For: 5.2.8.Final
>
>
> This JIRA will track the issues that need to be backported to the 5.2.x branch for EAP 6.3.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
10 years, 5 months