October 2013 - infinispan-issues - Jboss List Archives

[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: ------------------------------------- This test does not fail on the latest ISPN master currently. I looked on Jenkins to try to find which commit caused the failure, but haven't had luck. I see a SHA-1 here at https://jenkins.mw.lab.eng.bos.redhat.com/hudson/view/JDG/view/FUNC/job/e... but it doesn't appear to be a valid ISPN commit SHA-1. Are you still able to reproduce this issue or can you point me to what commit this was used against? > 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: jdg62GAblocker, testsuite_stability > 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

11 years, 3 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3611) Service jboss.infinispan.default failed to start on IBM JDK 6, argument type mismatch

by William Burns (JIRA)

[ https://issues.jboss.org/browse/ISPN-3611?page=com.atlassian.jira.plugin.... ] William Burns updated ISPN-3611: -------------------------------- Status: Pull Request Sent (was: Coding In Progress) Git Pull Request: https://github.com/infinispan/infinispan/pull/2159 > Service jboss.infinispan.default failed to start on IBM JDK 6, argument type mismatch > ------------------------------------------------------------------------------------- > > Key: ISPN-3611 > URL: https://issues.jboss.org/browse/ISPN-3611 > Project: Infinispan > Issue Type: Bug > Reporter: Mircea Markus > Assignee: William Burns > Labels: jdg62GAblocker > Fix For: 6.0.0.CR2 > > -- 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

11 years, 3 months

1
0
0 / 0

[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.... ] Work on ISPN-3364 started by William Burns. > 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: jdg62GAblocker, testsuite_stability > 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

11 years, 3 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3611) Service jboss.infinispan.default failed to start on IBM JDK 6, argument type mismatch

by William Burns (JIRA)

[ https://issues.jboss.org/browse/ISPN-3611?page=com.atlassian.jira.plugin.... ] Work on ISPN-3611 started by William Burns. > Service jboss.infinispan.default failed to start on IBM JDK 6, argument type mismatch > ------------------------------------------------------------------------------------- > > Key: ISPN-3611 > URL: https://issues.jboss.org/browse/ISPN-3611 > Project: Infinispan > Issue Type: Bug > Reporter: Mircea Markus > Assignee: William Burns > Labels: jdg62GAblocker > Fix For: 6.0.0.CR2 > > -- 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

11 years, 3 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3048) Eviction needs to be transactional

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/ISPN-3048?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on ISPN-3048: ----------------------------------------------- Dominik Pospisil <dpospisi(a)redhat.com> made a comment on [bug 1017827|https://bugzilla.redhat.com/show_bug.cgi?id=1017827] The issue affects EAP's internal caches (not JBossCache based portal caches) - mainly web session and SFSB caches. To disable the passivation user needs to remove <file-store/> element from cahce config in the server profile configuration. E.g. to disable web session cache passivation the following fragment of standalone/configuration/standalone-ha.xml <cache-container name="web" aliases="standard-session-cache" default-cache="repl" module="org.jboss.as.clustering.web.infinispan"> <transport lock-timeout="60000"/> <replicated-cache name="repl" mode="ASYNC" batching="true"> <file-store/> </replicated-cache> <replicated-cache name="sso" mode="SYNC" batching="true"/> <distributed-cache name="dist" mode="ASYNC" batching="true" l1-lifespan="0"> <file-store/> </distributed-cache> </cache-container> should be changed to: <cache-container name="web" aliases="standard-session-cache" default-cache="repl" module="org.jboss.as.clustering.web.infinispan"> <transport lock-timeout="60000"/> <replicated-cache name="repl" mode="ASYNC" batching="true">  </replicated-cache> <replicated-cache name="sso" mode="SYNC" batching="true"/> <distributed-cache name="dist" mode="ASYNC" batching="true" l1-lifespan="0">  </distributed-cache> </cache-container> > Eviction needs to be transactional > ---------------------------------- > > Key: ISPN-3048 > URL: https://issues.jboss.org/browse/ISPN-3048 > Project: Infinispan > Issue Type: Bug > Components: Eviction > Affects Versions: 5.3.0.Alpha1 > Reporter: Paul Ferraro > Assignee: William Burns > Priority: Critical > > Currently, Infinispan eviction is non-transactional. This makes Infinispan's eviction manager virtually unusable, since non-transactional eviction can cause phantom reads and data loss because it violates the isolation of concurrent transactions. This is especially problematic when using a passivation-enabled cache store. In this case, a cache eviction/passivation can cause a concurrently executed cache retrieval to return null - even though the act of passivation does not change the data - it only changes where it is stored. > We work around this in the AS by performing eviction manually, using pessimistic locking in combination with eager lock acquisition prior to eviction. This is unfortunate, since it prevents me from leveraging Infinispan's build-in eviction strategies. -- 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

11 years, 3 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3610) Upgrade to Hibernate Search 4.4.0.CR1

by Pedro Ruivo (JIRA)

[ https://issues.jboss.org/browse/ISPN-3610?page=com.atlassian.jira.plugin.... ] Pedro Ruivo updated ISPN-3610: ------------------------------ Fix Version/s: 6.0.0.CR2 > Upgrade to Hibernate Search 4.4.0.CR1 > ------------------------------------- > > Key: ISPN-3610 > URL: https://issues.jboss.org/browse/ISPN-3610 > Project: Infinispan > Issue Type: Component Upgrade > Components: Querying > Reporter: Adrian Nistor > Assignee: Adrian Nistor > Fix For: 6.0.0.CR2 > > -- 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

11 years, 3 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3610) Upgrade to Hibernate Search 4.4.0.CR1

by Pedro Ruivo (JIRA)

[ https://issues.jboss.org/browse/ISPN-3610?page=com.atlassian.jira.plugin.... ] Pedro Ruivo updated ISPN-3610: ------------------------------ Status: Resolved (was: Pull Request Sent) Resolution: Done > Upgrade to Hibernate Search 4.4.0.CR1 > ------------------------------------- > > Key: ISPN-3610 > URL: https://issues.jboss.org/browse/ISPN-3610 > Project: Infinispan > Issue Type: Component Upgrade > Components: Querying > Reporter: Adrian Nistor > Assignee: Adrian Nistor > -- 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

11 years, 3 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3295) Add a warning message to the log if the old bundler is enabled

by Pedro Ruivo (JIRA)

[ https://issues.jboss.org/browse/ISPN-3295?page=com.atlassian.jira.plugin.... ] Work on ISPN-3295 started by Pedro Ruivo. > Add a warning message to the log if the old bundler is enabled > -------------------------------------------------------------- > > Key: ISPN-3295 > URL: https://issues.jboss.org/browse/ISPN-3295 > Project: Infinispan > Issue Type: Bug > Affects Versions: 5.3.0.Final > Reporter: Alan Field > Assignee: Pedro Ruivo > Fix For: 6.0.0.Final > > > In JGroups 3.3, the new bundler is the default. If the old bundler is enabled (i.e. UDP.bundler_type="old") then Infinispan performance is adversely affected. Infinispan should warn if the old bundler is enabled to notify users of this situation. -- 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

11 years, 3 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3404) ClusterCacheLoader NPE when ClusteredGetCommand response value is null

by Pedro Ruivo (JIRA)

[ https://issues.jboss.org/browse/ISPN-3404?page=com.atlassian.jira.plugin.... ] Pedro Ruivo updated ISPN-3404: ------------------------------ Status: Pull Request Sent (was: Coding In Progress) Git Pull Request: https://github.com/infinispan/infinispan/pull/2158 > ClusterCacheLoader NPE when ClusteredGetCommand response value is null > ---------------------------------------------------------------------- > > Key: ISPN-3404 > URL: https://issues.jboss.org/browse/ISPN-3404 > Project: Infinispan > Issue Type: Bug > Affects Versions: 6.0.0.Alpha2 > Reporter: Tomas Sykora > Assignee: Pedro Ruivo > Labels: jdg62GAblocker > Fix For: 6.0.0.CR2, 6.0.0.Final > > Attachments: clusterCacheLoaderNullPointerResponseValueError.txt, server1DR2.log, server2DR2.log > > > We found this issue in DR2 (Alpha2). In Alpha1 this was ok. > Our internal test: > {code:title=Bar.java|borderStyle=solid} > @Test > public void testLazyLoadingWhenStateTransferDisabled() throws Exception { > controller.start(CONTAINER1); > mc = new MemcachedHelper(server1.getMemcachedEndpoint().getInetAddress().getHostName(), server1.getMemcachedEndpoint() > .getPort()); > mc.set("k1", "v1"); > mc.set("k2", "v2"); > assertEquals("v1", mc.get("k1")); > assertEquals("v2", mc.get("k2")); > assertEquals(2, server1.getDefaultCacheManager().getCache(CACHE_NAME).getNumberOfEntries()); > controller.start(CONTAINER2); > mc2 = new MemcachedHelper(server2.getMemcachedEndpoint().getInetAddress().getHostName(), server2.getMemcachedEndpoint() > .getPort()); > assertEquals(2, server2.getDefaultCacheManager().getClusterSize()); > //state-transfer = false -> no entries in the newly joined node > assertEquals(0, server2.getDefaultCacheManager().getCache(CACHE_NAME).getNumberOfEntries()); > assertEquals("v1", mc2.get("k1")); //lazily load the entries > assertEquals("v2", mc2.get("k2")); > assertEquals(2, server2.getDefaultCacheManager().getCache(CACHE_NAME).getNumberOfEntries()); > mc2.set("k3", "v3"); // THIS IS FAILING HERE > assertEquals(3, server2.getDefaultCacheManager().getCache(CACHE_NAME).getNumberOfEntries()); > assertEquals(3, server1.getDefaultCacheManager().getCache(CACHE_NAME).getNumberOfEntries()); > controller.kill(CONTAINER2); > controller.kill(CONTAINER1); > } > {code} > *mc2.set("k3", "v3"); = put into memcached cache, is throwing an exception: see in attachment.* > You can see MemcachedHelper class here: https://code.engineering.redhat.com/gerrit/gitweb?p=jdg-functional-tests.... > I also include trace logs for both memcached jdg servers if they can be useful. > --------------- > I was able to replicate the same error in Infinispan test suite for Rest endpoint. It was enough to start 2 REST nodes and issue 1 put resulting into the same error. > {code:title=Bar.java|borderStyle=solid} > ConfigurationBuilder cfgBuilder = AbstractCacheTest.getDefaultClusteredCacheConfig(CacheMode.REPL_SYNC, false); > cfgBuilder.clustering().hash().numOwners(1); > cfgBuilder.clustering().stateTransfer().fetchInMemoryState(false); > cfgBuilder.clustering().stateTransfer().timeout(20000); > cfgBuilder.loaders().addClusterCacheLoader().remoteCallTimeout(60000); > RestServerConfigurationBuilder restCfgBuilder = new RestServerConfigurationBuilder(); > addServer("1", 8890, TestCacheManagerFactory.createClusteredCacheManager(cfgBuilder), restCfgBuilder.build()); > addServer("2", 8891, TestCacheManagerFactory.createClusteredCacheManager(cfgBuilder), restCfgBuilder.build()); > startServers(); > ...... > PutMethod put = new PutMethod(PATH1 + "key1"); > put.setRequestEntity(new StringRequestEntity("value1", "application/text", null)); > call(put); > assertEquals(put.getStatusCode(), HttpServletResponse.SC_OK); > put.releaseConnection(); > {code} > This scenario is different from aforementioned JDG internal test suite one but I expect this should be ok and should be performed without any problems. > -- 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

11 years, 3 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3404) ClusterCacheLoader NPE when ClusteredGetCommand response value is null

by Pedro Ruivo (JIRA)

[ https://issues.jboss.org/browse/ISPN-3404?page=com.atlassian.jira.plugin.... ] Pedro Ruivo updated ISPN-3404: ------------------------------ Summary: ClusterCacheLoader NPE when ClusteredGetCommand response value is null (was: ClusterCacheLoader - clusteredGetCommand response value is null) > ClusterCacheLoader NPE when ClusteredGetCommand response value is null > ---------------------------------------------------------------------- > > Key: ISPN-3404 > URL: https://issues.jboss.org/browse/ISPN-3404 > Project: Infinispan > Issue Type: Bug > Affects Versions: 6.0.0.Alpha2 > Reporter: Tomas Sykora > Assignee: Pedro Ruivo > Labels: jdg62GAblocker > Fix For: 6.0.0.CR2, 6.0.0.Final > > Attachments: clusterCacheLoaderNullPointerResponseValueError.txt, server1DR2.log, server2DR2.log > > > We found this issue in DR2 (Alpha2). In Alpha1 this was ok. > Our internal test: > {code:title=Bar.java|borderStyle=solid} > @Test > public void testLazyLoadingWhenStateTransferDisabled() throws Exception { > controller.start(CONTAINER1); > mc = new MemcachedHelper(server1.getMemcachedEndpoint().getInetAddress().getHostName(), server1.getMemcachedEndpoint() > .getPort()); > mc.set("k1", "v1"); > mc.set("k2", "v2"); > assertEquals("v1", mc.get("k1")); > assertEquals("v2", mc.get("k2")); > assertEquals(2, server1.getDefaultCacheManager().getCache(CACHE_NAME).getNumberOfEntries()); > controller.start(CONTAINER2); > mc2 = new MemcachedHelper(server2.getMemcachedEndpoint().getInetAddress().getHostName(), server2.getMemcachedEndpoint() > .getPort()); > assertEquals(2, server2.getDefaultCacheManager().getClusterSize()); > //state-transfer = false -> no entries in the newly joined node > assertEquals(0, server2.getDefaultCacheManager().getCache(CACHE_NAME).getNumberOfEntries()); > assertEquals("v1", mc2.get("k1")); //lazily load the entries > assertEquals("v2", mc2.get("k2")); > assertEquals(2, server2.getDefaultCacheManager().getCache(CACHE_NAME).getNumberOfEntries()); > mc2.set("k3", "v3"); // THIS IS FAILING HERE > assertEquals(3, server2.getDefaultCacheManager().getCache(CACHE_NAME).getNumberOfEntries()); > assertEquals(3, server1.getDefaultCacheManager().getCache(CACHE_NAME).getNumberOfEntries()); > controller.kill(CONTAINER2); > controller.kill(CONTAINER1); > } > {code} > *mc2.set("k3", "v3"); = put into memcached cache, is throwing an exception: see in attachment.* > You can see MemcachedHelper class here: https://code.engineering.redhat.com/gerrit/gitweb?p=jdg-functional-tests.... > I also include trace logs for both memcached jdg servers if they can be useful. > --------------- > I was able to replicate the same error in Infinispan test suite for Rest endpoint. It was enough to start 2 REST nodes and issue 1 put resulting into the same error. > {code:title=Bar.java|borderStyle=solid} > ConfigurationBuilder cfgBuilder = AbstractCacheTest.getDefaultClusteredCacheConfig(CacheMode.REPL_SYNC, false); > cfgBuilder.clustering().hash().numOwners(1); > cfgBuilder.clustering().stateTransfer().fetchInMemoryState(false); > cfgBuilder.clustering().stateTransfer().timeout(20000); > cfgBuilder.loaders().addClusterCacheLoader().remoteCallTimeout(60000); > RestServerConfigurationBuilder restCfgBuilder = new RestServerConfigurationBuilder(); > addServer("1", 8890, TestCacheManagerFactory.createClusteredCacheManager(cfgBuilder), restCfgBuilder.build()); > addServer("2", 8891, TestCacheManagerFactory.createClusteredCacheManager(cfgBuilder), restCfgBuilder.build()); > startServers(); > ...... > PutMethod put = new PutMethod(PATH1 + "key1"); > put.setRequestEntity(new StringRequestEntity("value1", "application/text", null)); > call(put); > assertEquals(put.getStatusCode(), HttpServletResponse.SC_OK); > put.releaseConnection(); > {code} > This scenario is different from aforementioned JDG internal test suite one but I expect this should be ok and should be performed without any problems. > -- 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

11 years, 3 months

1
0
0 / 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

infinispan-issues October 2013