March 2016 - infinispan-issues - Jboss List Archives

[JBoss JIRA] (ISPN-6323) Cluster startup hangs indefinitely in client-server mode

by Adrian Nistor (JIRA)

[ https://issues.jboss.org/browse/ISPN-6323?page=com.atlassian.jira.plugin.... ] Adrian Nistor updated ISPN-6323: -------------------------------- Fix Version/s: 8.2.0.Final > Cluster startup hangs indefinitely in client-server mode > -------------------------------------------------------- > > Key: ISPN-6323 > URL: https://issues.jboss.org/browse/ISPN-6323 > Project: Infinispan > Issue Type: Bug > Components: Server > Affects Versions: 8.2.0.CR1 > Reporter: Matej Čimbora > Assignee: Pedro Ruivo > Priority: Blocker > Fix For: 8.2.0.Final > > > The issue was reliably reproduced on a cluster of 64 nodes with default clustered.xml configuration. The nodes receive a view and hang. Coordinator's log is cluttered with CacheNotFoundResponse & JGroups NPE's (included below). Other nodes just receive replication timeout while getting rebalancing status. > Thread dump (coordinator): https://gist.github.com/mcimbora/b65914bcd8141427fbf4 > Exceptions (coordinator): https://gist.github.com/mcimbora/0dd9a5b53344c1cdb18b > Exceptions(other nodes): https://gist.github.com/mcimbora/49d8b9f1b983d17ca5b1 -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 1 month

1
0
0 / 0

[JBoss JIRA] (ISPN-6323) Cluster startup hangs indefinitely in client-server mode

by Adrian Nistor (JIRA)

[ https://issues.jboss.org/browse/ISPN-6323?page=com.atlassian.jira.plugin.... ] Adrian Nistor updated ISPN-6323: -------------------------------- Status: Pull Request Sent (was: Open) Git Pull Request: https://github.com/infinispan/infinispan/pull/4087 > Cluster startup hangs indefinitely in client-server mode > -------------------------------------------------------- > > Key: ISPN-6323 > URL: https://issues.jboss.org/browse/ISPN-6323 > Project: Infinispan > Issue Type: Bug > Components: Server > Affects Versions: 8.2.0.CR1 > Reporter: Matej Čimbora > Assignee: Pedro Ruivo > Priority: Blocker > > The issue was reliably reproduced on a cluster of 64 nodes with default clustered.xml configuration. The nodes receive a view and hang. Coordinator's log is cluttered with CacheNotFoundResponse & JGroups NPE's (included below). Other nodes just receive replication timeout while getting rebalancing status. > Thread dump (coordinator): https://gist.github.com/mcimbora/b65914bcd8141427fbf4 > Exceptions (coordinator): https://gist.github.com/mcimbora/0dd9a5b53344c1cdb18b > Exceptions(other nodes): https://gist.github.com/mcimbora/49d8b9f1b983d17ca5b1 -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 1 month

1
0
0 / 0

[JBoss JIRA] (ISPN-6308) Stream iterator method can fail sometimes with a node failure

by Tristan Tarrant (JIRA)

[ https://issues.jboss.org/browse/ISPN-6308?page=com.atlassian.jira.plugin.... ] Tristan Tarrant updated ISPN-6308: ---------------------------------- Status: Resolved (was: Pull Request Sent) Resolution: Done > Stream iterator method can fail sometimes with a node failure > ------------------------------------------------------------- > > Key: ISPN-6308 > URL: https://issues.jboss.org/browse/ISPN-6308 > Project: Infinispan > Issue Type: Bug > Components: Distributed Execution and Map/Reduce > Affects Versions: 8.1.2.Final > Reporter: William Burns > Assignee: William Burns > Fix For: 8.2.0.Final > > > While adding some additional changes for replication using distributed streams I ran the stress test. I found that iterator could fail somehow. Need to patch this issue. > Using following settings: > {code} > protected final static int CACHE_COUNT = 5; > protected final static int THREAD_MULTIPLIER = 15; > protected final static long CACHE_ENTRY_COUNT = 5000; > {code} > {code} > 15:25:29,655 FATAL (ForkThread-17,DistributedStreamRehashStressTest) [DistributedStreamRehashStressTest] Exception encountered: > java.lang.IllegalArgumentException: Thread[ForkThread-17,DistributedStreamRehashStressTest,5,main]-Found incorrect amount 6 of entries, expected 10 for segment 39 missing entries [ImmortalCacheEntry{key=1922, value=1922}, ImmortalCacheEntry{key=2107, value=2107}, ImmortalCacheEntry{key=2265, value=2265}, ImmortalCacheEntry{key=2412, value=2412}, ImmortalCacheEntry{key=2446, value=2446}, ImmortalCacheEntry{key=2575, value=2575}, ImmortalCacheEntry{key=3315, value=3315}, ImmortalCacheEntry{key=3324, value=3324}, ImmortalCacheEntry{key=3349, value=3349}, ImmortalCacheEntry{key=3675, value=3675}] on iteration 3 > at org.infinispan.stream.stress.DistributedStreamRehashStressTest.lambda$testStressNodesLeavingWhileMultipleIterators$4(DistributedStreamRehashStressTest.java:139) > at org.infinispan.stream.stress.DistributedStreamRehashStressTest.lambda$testStressNodesLeavingWhilePerformingCallable$5(DistributedStreamRehashStressTest.java:173) > at org.infinispan.test.AbstractInfinispanTest$LoggingCallable.call(AbstractInfinispanTest.java:478) > at java.util.concurrent.FutureTask.run(FutureTask.java:266) > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) > {code} -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 1 month

1
0
0 / 0

[JBoss JIRA] (ISPN-6329) Add Infinispan Core to Remote Uber Jar

by Sebastian Łaskawiec (JIRA)

[ https://issues.jboss.org/browse/ISPN-6329?page=com.atlassian.jira.plugin.... ] Sebastian Łaskawiec updated ISPN-6329: -------------------------------------- Status: Open (was: Pull Request Sent) > Add Infinispan Core to Remote Uber Jar > -------------------------------------- > > Key: ISPN-6329 > URL: https://issues.jboss.org/browse/ISPN-6329 > Project: Infinispan > Issue Type: Bug > Components: Loaders and Stores > Affects Versions: 8.2.0.CR1 > Reporter: Sebastian Łaskawiec > Assignee: Sebastian Łaskawiec > Fix For: 8.2.0.Final > > > We need to support Remote Cache Scenario in this type of deployment -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 1 month

1
0
0 / 0

[JBoss JIRA] (ISPN-6329) Add Infinispan Core to Remote Uber Jar

by Sebastian Łaskawiec (JIRA)

[ https://issues.jboss.org/browse/ISPN-6329?page=com.atlassian.jira.plugin.... ] Sebastian Łaskawiec closed ISPN-6329. ------------------------------------- Resolution: Rejected > Add Infinispan Core to Remote Uber Jar > -------------------------------------- > > Key: ISPN-6329 > URL: https://issues.jboss.org/browse/ISPN-6329 > Project: Infinispan > Issue Type: Bug > Components: Loaders and Stores > Affects Versions: 8.2.0.CR1 > Reporter: Sebastian Łaskawiec > Assignee: Sebastian Łaskawiec > Fix For: 8.2.0.Final > > > We need to support Remote Cache Scenario in this type of deployment -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 1 month

1
0
0 / 0

[JBoss JIRA] (ISPN-6323) Cluster startup hangs indefinitely in client-server mode

by Adrian Nistor (JIRA)

[ https://issues.jboss.org/browse/ISPN-6323?page=com.atlassian.jira.plugin.... ] Adrian Nistor updated ISPN-6323: -------------------------------- Status: Open (was: New) > Cluster startup hangs indefinitely in client-server mode > -------------------------------------------------------- > > Key: ISPN-6323 > URL: https://issues.jboss.org/browse/ISPN-6323 > Project: Infinispan > Issue Type: Bug > Components: Server > Affects Versions: 8.2.0.CR1 > Reporter: Matej Čimbora > Assignee: Pedro Ruivo > Priority: Blocker > > The issue was reliably reproduced on a cluster of 64 nodes with default clustered.xml configuration. The nodes receive a view and hang. Coordinator's log is cluttered with CacheNotFoundResponse & JGroups NPE's (included below). Other nodes just receive replication timeout while getting rebalancing status. > Thread dump (coordinator): https://gist.github.com/mcimbora/b65914bcd8141427fbf4 > Exceptions (coordinator): https://gist.github.com/mcimbora/0dd9a5b53344c1cdb18b > Exceptions(other nodes): https://gist.github.com/mcimbora/49d8b9f1b983d17ca5b1 -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 1 month

1
0
0 / 0

[JBoss JIRA] (ISPN-6333) Create more tests for Remote Script Execution

by Anna Manukyan (JIRA)

Anna Manukyan created ISPN-6333: ----------------------------------- Summary: Create more tests for Remote Script Execution Key: ISPN-6333 URL: https://issues.jboss.org/browse/ISPN-6333 Project: Infinispan Issue Type: Sub-task Components: Tasks Reporter: Anna Manukyan Include workaround for ISPN-6173 as well as more tests for map/reduce. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 1 month

1
0
0 / 0

[JBoss JIRA] (ISPN-6333) Create more tests for Remote Script Execution

by Anna Manukyan (JIRA)

[ https://issues.jboss.org/browse/ISPN-6333?page=com.atlassian.jira.plugin.... ] Anna Manukyan reassigned ISPN-6333: ----------------------------------- Assignee: Anna Manukyan > Create more tests for Remote Script Execution > --------------------------------------------- > > Key: ISPN-6333 > URL: https://issues.jboss.org/browse/ISPN-6333 > Project: Infinispan > Issue Type: Sub-task > Components: Tasks > Reporter: Anna Manukyan > Assignee: Anna Manukyan > Fix For: 8.2.0.CR1, 8.2.0.Final > > > Include workaround for ISPN-6173 as well as more tests for map/reduce. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 1 month

1
0
0 / 0

[JBoss JIRA] (ISPN-6332) L1CachingIT random failures

by Dan Berindei (JIRA)

[ https://issues.jboss.org/browse/ISPN-6332?page=com.atlassian.jira.plugin.... ] Dan Berindei updated ISPN-6332: ------------------------------- Status: Pull Request Sent (was: Open) Git Pull Request: https://github.com/infinispan/infinispan/pull/4086 > L1CachingIT random failures > --------------------------- > > Key: ISPN-6332 > URL: https://issues.jboss.org/browse/ISPN-6332 > Project: Infinispan > Issue Type: Bug > Components: Test Suite - Server > Affects Versions: 8.2.0.CR1 > Reporter: Dan Berindei > Assignee: Dan Berindei > Labels: testsuite_stability > Fix For: 8.2.0.Final > > > The test inserts 3 keys in a distributed cache with 2 members and {{numOwners == 1}}, and asserts that each member will have at least one key. > This worked prior to ISPN-4851, because the distribution of keys was always the same, but it is no longer reliable now: > {noformat} > java.lang.AssertionError: Distribution of entries is wrong (at least unexpected). > at org.junit.Assert.fail(Assert.java:88) > at org.junit.Assert.assertTrue(Assert.java:41) > at org.infinispan.server.test.l1.L1CachingIT.testL1CachingEnabled(L1CachingIT.java:85) > {noformat} -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 1 month

1
0
0 / 0

[JBoss JIRA] (ISPN-6178) Add ability to define indexable classes via config

by Tristan Tarrant (JIRA)

[ https://issues.jboss.org/browse/ISPN-6178?page=com.atlassian.jira.plugin.... ] Tristan Tarrant updated ISPN-6178: ---------------------------------- Status: Resolved (was: Pull Request Sent) Resolution: Done > Add ability to define indexable classes via config > -------------------------------------------------- > > Key: ISPN-6178 > URL: https://issues.jboss.org/browse/ISPN-6178 > Project: Infinispan > Issue Type: Feature Request > Components: Embedded Querying > Reporter: Adrian Nistor > Assignee: Adrian Nistor > Fix For: 8.2.0.Final > > > Queryable classes are currently auto-detected on the fly by the QueryInterceptor on each write operation. The set of discovered classes is replicated by means of ClusterRegistry. > This approach creates a lot of technical complexity and the implementation has a number of flaws; some have been fixed after several iterations but the solution is still brittle and can lead to locking issues. It also forces Hibernate Search to reconfigure the factory which is rather messy. Instead of continuing to patch and 'improve' this we should consider pre-declaring the indexable classes in the cache configuration (indexing configuration actually). > Given the impact of this change to existing codebase I would propose an approach that allows an easy transition: > 1. Introduction of a new config in indexing configuration to be able to specify the classes. > 2. If cache is indexed but no indexable classes were defined fallback to on-demand auto-detection as it worked in 8.1. > 3. If cache is indexed and classes were specified use them and do not perform on-demand auto-detection anymore. Also do not use ClusterRegistry to propagate the set of classes anymore. > This is how it should work in 8.2. Auto-detection should also be documented as deprecated in 8.2 and should be removed completely in 9.0. In 9.0, marking a cache as indexed but not specifying which exact classes should result in an error at config time validation. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 1 month

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

infinispan-issues March 2016