December 2013 - infinispan-issues

[JBoss JIRA] (ISPN-3839) Compatibility Mode tests didn't shutdown all the cache managers

by Pedro Ruivo (JIRA)

[ https://issues.jboss.org/browse/ISPN-3839?page=com.atlassian.jira.plugin.... ] Pedro Ruivo updated ISPN-3839: ------------------------------ Summary: Compatibility Mode tests didn't shutdown all the cache managers (was: Compatibility Mode tests didn't shutdown all the caches) > Compatibility Mode tests didn't shutdown all the cache managers > --------------------------------------------------------------- > > Key: ISPN-3839 > URL: https://issues.jboss.org/browse/ISPN-3839 > Project: Infinispan > Issue Type: Bug > Components: Test Suite > Affects Versions: 6.0.0.Final > Reporter: Pedro Ruivo > Assignee: Pedro Ruivo > Labels: testsuite_stability > Fix For: 6.1.0.Final > > -- 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

12 years, 4 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3829) Null value read with RR can be replaced by cache loader value

by Mircea Markus (JIRA)

[ https://issues.jboss.org/browse/ISPN-3829?page=com.atlassian.jira.plugin.... ] Mircea Markus updated ISPN-3829: -------------------------------- Labels: 620 (was: ) > Null value read with RR can be replaced by cache loader value > ------------------------------------------------------------- > > Key: ISPN-3829 > URL: https://issues.jboss.org/browse/ISPN-3829 > Project: Infinispan > Issue Type: Bug > Components: Loaders and Stores > Affects Versions: 6.0.0.Final > Reporter: William Burns > Assignee: William Burns > Labels: 620 > > Currently the CacheLoaderInterceptor does the following check to determine if it should check the loader for a value > {code} > if (e == null || e.isNull() || e.getValue() == null) { > {code} > Unfortunately this means it checks the loader when a null value is in the entry when using RR. This can cause an issue if another transaction commits that key and puts a value that results in that value being inserted into the loader. > This also is a performance issue for RR, since it has to check the loader over and over for a given key even if it was found null the first time. > Initial thought is to do something like setSkipRemoteGet and that could actually be used for a dual purpose possibly. -- 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

12 years, 4 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3829) Null value read with RR can be replaced by cache loader value

by William Burns (JIRA)

[ https://issues.jboss.org/browse/ISPN-3829?page=com.atlassian.jira.plugin.... ] William Burns reassigned ISPN-3829: ----------------------------------- Assignee: William Burns (was: Mircea Markus) > Null value read with RR can be replaced by cache loader value > ------------------------------------------------------------- > > Key: ISPN-3829 > URL: https://issues.jboss.org/browse/ISPN-3829 > Project: Infinispan > Issue Type: Bug > Components: Loaders and Stores > Affects Versions: 6.0.0.Final > Reporter: William Burns > Assignee: William Burns > > Currently the CacheLoaderInterceptor does the following check to determine if it should check the loader for a value > {code} > if (e == null || e.isNull() || e.getValue() == null) { > {code} > Unfortunately this means it checks the loader when a null value is in the entry when using RR. This can cause an issue if another transaction commits that key and puts a value that results in that value being inserted into the loader. > This also is a performance issue for RR, since it has to check the loader over and over for a given key even if it was found null the first time. > Initial thought is to do something like setSkipRemoteGet and that could actually be used for a dual purpose possibly. -- 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

12 years, 4 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3836) TxCleanupService can cause TCCL leak

by Mircea Markus (JIRA)

[ https://issues.jboss.org/browse/ISPN-3836?page=com.atlassian.jira.plugin.... ] Mircea Markus updated ISPN-3836: -------------------------------- Labels: 620 (was: ) > TxCleanupService can cause TCCL leak > ------------------------------------ > > Key: ISPN-3836 > URL: https://issues.jboss.org/browse/ISPN-3836 > Project: Infinispan > Issue Type: Bug > Affects Versions: 6.0.0.Final > Reporter: Brent Douglas > Assignee: Mircea Markus > Labels: 620 > > Looks to me like this should be using infinispan's classloader rather than the TCCL when creating a thread. > https://issues.jboss.org/browse/WFLY-2605 -- 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

12 years, 4 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3586) Improve performance of Infinispan Lucene directory provider

by Divya Mehra (JIRA)

[ https://issues.jboss.org/browse/ISPN-3586?page=com.atlassian.jira.plugin.... ] Divya Mehra updated ISPN-3586: ------------------------------ Labels: 620 (was: ) > Improve performance of Infinispan Lucene directory provider > ----------------------------------------------------------- > > Key: ISPN-3586 > URL: https://issues.jboss.org/browse/ISPN-3586 > Project: Infinispan > Issue Type: Enhancement > Components: Lucene Directory > Affects Versions: 6.0.0.Beta2 > Reporter: Adrian Nistor > Assignee: Sanne Grinovero > Labels: 620 > > Currently in distributed mode it takes about 2 minutes to index 2000 entries. This was found in ISPN-3102. -- 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

12 years, 4 months

1
0
0 / 0

[JBoss JIRA] (ISPN-2255) FineGrainedAtomicMap missing key, value pairs in some cluster nodes in distributed mode, embedded infinispan cache

by Pedro Ruivo (JIRA)

[ https://issues.jboss.org/browse/ISPN-2255?page=com.atlassian.jira.plugin.... ] Pedro Ruivo updated ISPN-2255: ------------------------------ Status: Pull Request Sent (was: Coding In Progress) Git Pull Request: https://github.com/infinispan/infinispan/pull/2289 > FineGrainedAtomicMap missing key,value pairs in some cluster nodes in distributed mode, embedded infinispan cache > ----------------------------------------------------------------------------------------------------------------- > > Key: ISPN-2255 > URL: https://issues.jboss.org/browse/ISPN-2255 > Project: Infinispan > Issue Type: Bug > Components: Fine-grained API > Affects Versions: 5.1.5.FINAL > Environment: Details about cluster: > 1. Infinispan 5.1.5 > 2. java 7u5 64bit > 3. linux 64bit (two nodes debian and one node ubuntu) > 4. tomcat 7.0.28 > 5. jbossTM 4.16.0 JTA only > Tomcat integration code is here: > https://github.com/zvrablik/tomcatInfinispanSessionManager/tree/master/to... > 6. all machines are on real hw ( no virtual machines), date and time is synchronized and shouldn't vary more than 1 second > Reporter: Zdenek Henek > Assignee: Pedro Ruivo > Priority: Critical > Fix For: 6.1.0.Final > > Attachments: fgamissueTest2.zip, jgroupsConfig.xml, sessionInfinispanConfigtestLB.xml > > > I am using FineGrainedAtomicMap to store data into clustering distributed cache. When clustering set to replicated doesn't cause any issues or at least I haven't run > into any. When I switch to distributed mode I don't see some key,value pairs in some nodes. This happens randomly. The numOwners is set to two and I have cluster of three nodes. > more details: > https://community.jboss.org/thread/203420?tstart=60 -- 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

12 years, 4 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3772) Reduce marshalling payload sizes

by Pedro Ruivo (JIRA)

[ https://issues.jboss.org/browse/ISPN-3772?page=com.atlassian.jira.plugin.... ] Pedro Ruivo updated ISPN-3772: ------------------------------ Status: Resolved (was: Pull Request Sent) Resolution: Done > Reduce marshalling payload sizes > -------------------------------- > > Key: ISPN-3772 > URL: https://issues.jboss.org/browse/ISPN-3772 > Project: Infinispan > Issue Type: Enhancement > Components: Marshalling > Affects Versions: 6.0.0.Final > Reporter: Galder Zamarreño > Assignee: Galder Zamarreño > Fix For: 6.1.0.Final > > > Apply some marshalling improvements: > 1. Marshall instances of java.util.Arrays$ArrayList with ArrayListExternalizer so that it occupies less space. > 2. RegularEnumSet and JumboEnumSet should be detected and they should be written using SetExternalizer. For an enum set with a single value, this means going from writing 41 bytes to 10 bytes. > 3. Avoid sending OPERATION_X flags when compatibility mode is disabled. > 4. Current array support in JBoss Marshalling ends up writing class information even for know types. Try to figure out a way to detect the most commonly written arrays in Infinispan and find an efficient way to marshall them. -- 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

12 years, 4 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3724) REST RollUps -- Unsupported protocol version 60 throws annoying ERROR and WARN

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/ISPN-3724?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on ISPN-3724: ----------------------------------------------- Tomas Sykora <tsykora(a)redhat.com> changed the Status of [bug 1031660|https://bugzilla.redhat.com/show_bug.cgi?id=1031660] from ON_QA to ASSIGNED > REST RollUps -- Unsupported protocol version 60 throws annoying ERROR and WARN > ------------------------------------------------------------------------------ > > Key: ISPN-3724 > URL: https://issues.jboss.org/browse/ISPN-3724 > Project: Infinispan > Issue Type: Bug > Affects Versions: 6.0.0.CR1 > Reporter: Tomas Sykora > Assignee: Mircea Markus > Labels: 620 > Fix For: 6.1.0.Final > > Attachments: restRollups6dot0to6dot0tryingToGetHRkey, RestRollUpsUnsupportedProtocol60 > > > Trying to process REST rolling upgrades using latest infinispan server 6.0.0 snapshot as a TARGET node and the same server as a source node. > Run Infinispan-server testsuite test for REST Rolling Upgrades. > mvn clean verify -P suite.examples -Dtest=ExampleConfigsTest#testRestRollingUpgrades -DfailIfNoTests=false > See new attached file with current stacktrace. REST rolling upgrades from 5.2.x to 6.0 will probably _not_ be supported. -- 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

12 years, 4 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3764) ISPN testsuite fails for RHEL6x64 && IBM JDK6

by William Burns (JIRA)

[ https://issues.jboss.org/browse/ISPN-3764?page=com.atlassian.jira.plugin.... ] William Burns closed ISPN-3764. ------------------------------- Resolution: Rejected Talking with Vitalii this is no longer reproducible with latest build {quote} <vchepeli> So as you can see there is big matrix and that configuration is passing. I think we can close this bug cause I cant reproduce it with ER5. {quote} If this comes up again please reopen or create another JIRA, thanks! > ISPN testsuite fails for RHEL6x64 && IBM JDK6 > ---------------------------------------------- > > Key: ISPN-3764 > URL: https://issues.jboss.org/browse/ISPN-3764 > Project: Infinispan > Issue Type: Bug > Components: Build process > Affects Versions: 6.0.0.Final > Environment: RHEL6x64 IBM6 > Reporter: Vitalii Chepeliuk > Assignee: William Burns > Priority: Critical > Labels: 620, testsuite_stability > > Sometimes build is stucked and sometiemes it throws following exception when CORE module is running > !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! > !!!!!! (testng-DistWriteSkewTest) Exiting because DistWriteSkewTest has NOT shut down all the cache managers it has started !!!!!!! > !!!!!! (testng-DistWriteSkewTest) See allocation stacktrace to find out where still-running cacheManager was created: !!!!!!! > !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! > java.lang.Throwable > at org.infinispan.test.fwk.TestCacheManagerFactory.addThreadCacheManager(TestCacheManagerFactory.java:373) > at org.infinispan.test.fwk.TestCacheManagerFactory.newDefaultCacheManager(TestCacheManagerFactory.java:356) > at org.infinispan.test.fwk.TestCacheManagerFactory.newDefaultCacheManager(TestCacheManagerFactory.java:68) > at org.infinispan.test.fwk.TestCacheManagerFactory.createClusteredCacheManager(TestCacheManagerFactory.java:160) > at org.infinispan.test.fwk.TestCacheManagerFactory.createClusteredCacheManager(TestCacheManagerFactory.java:151) > at org.infinispan.test.fwk.TestCacheManagerFactory.createClusteredCacheManager(TestCacheManagerFactory.java:125) > at org.infinispan.test.MultipleCacheManagersTest.addClusterEnabledCacheManager(MultipleCacheManagersTest.java:177) > at org.infinispan.test.MultipleCacheManagersTest.addClusterEnabledCacheManager(MultipleCacheManagersTest.java:162) > at org.infinispan.test.MultipleCacheManagersTest.createCluster(MultipleCacheManagersTest.java:196) > at org.infinispan.container.versioning.AbstractClusteredWriteSkewTest.createCacheManagers(AbstractClusteredWriteSkewTest.java:59) > at org.infinispan.test.MultipleCacheManagersTest.callCreateCacheManagers(MultipleCacheManagersTest.java:69) > at org.infinispan.test.MultipleCacheManagersTest.createBeforeMethod(MultipleCacheManagersTest.java:79) > at sun.reflect.GeneratedMethodAccessor151.invoke(Unknown Source) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:37) > at java.lang.reflect.Method.invoke(Method.java:611) > Add link to 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

12 years, 4 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3422) In non-tx caches, write operations may not be atomic during rebalance

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/ISPN-3422?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on ISPN-3422: ----------------------------------------------- Radim Vansa <rvansa(a)redhat.com> changed the Status of [bug 1021461|https://bugzilla.redhat.com/show_bug.cgi?id=1021461] from ON_QA to VERIFIED > In non-tx caches, write operations may not be atomic during rebalance > --------------------------------------------------------------------- > > Key: ISPN-3422 > URL: https://issues.jboss.org/browse/ISPN-3422 > Project: Infinispan > Issue Type: Bug > Reporter: Dan Berindei > Assignee: Dan Berindei > Priority: Critical > Labels: 620, nbst > Fix For: 6.1.0.Final > > > If the cache topology changes while a write command is running and before it has actually committed the entry to the data container, we retry the command (see ISPN-3366 and ISPN-3357). But before we detect the topology change, one or more of the backup owners may have already applied the modification. > Retrying the command re-acquires the key lock on the primary owner (even if the primary owner didn't change). That means another command could have modified the same key in the meantime, but the retried command is going to ignore any changes and is going to return the value before the first attempt. Obviously, the command is not retried if the first attempt is not successful, but scenarios like this are possible: > {code} > thread 1: putIfAbsent(k, v1) -> null > thread 2: putIfAbsent(k, v2) -> null > {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

12 years, 4 months

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

infinispan-issues December 2013