March 2016 - infinispan-issues - Jboss List Archives

[JBoss JIRA] (ISPN-6328) Improper configuration of marshalling can lead to com.google.protobuf.InvalidProtocolBufferException: Protocol message contained an invalid tag (zero)

by Pedro Ruivo (JIRA)

[ https://issues.jboss.org/browse/ISPN-6328?page=com.atlassian.jira.plugin.... ] Pedro Ruivo updated ISPN-6328: ------------------------------ Fix Version/s: 9.0.0.Alpha1 (was: 8.2.0.Final) > Improper configuration of marshalling can lead to com.google.protobuf.InvalidProtocolBufferException: Protocol message contained an invalid tag (zero) > ------------------------------------------------------------------------------------------------------------------------------------------------------ > > Key: ISPN-6328 > URL: https://issues.jboss.org/browse/ISPN-6328 > Project: Infinispan > Issue Type: Bug > Components: Remote Querying > Affects Versions: 8.2.0.CR1 > Reporter: Adrian Nistor > Assignee: Adrian Nistor > Fix For: 9.0.0.Alpha1 > > > Running queries on a remote cache that was previously populated by an app that did not use protobuf marshalling should be allowed, and all those entities that were not encoded using protobuf should be ignored by the query engine and a warning should be logged instructing the user about the potential issue and how to fix the configuration. > The current behaviour in this case is not user friendly, especially in case of non-indexed query. An error is thrown during query evaluation: "com.google.protobuf.InvalidProtocolBufferException: Protocol message contained an invalid tag (zero)." which indicates the unmarshalling of the queried entities is not possible. The actual cause of the bad encoding should be explained to the user and no exception should be thrown as if the type of entities does not match the requested type. -- 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 Pedro Ruivo (JIRA)

[ https://issues.jboss.org/browse/ISPN-6333?page=com.atlassian.jira.plugin.... ] Pedro Ruivo updated ISPN-6333: ------------------------------ Fix Version/s: 9.0.0.Alpha1 (was: 8.2.0.Final) > 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, 9.0.0.Alpha1 > > > 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-6322) Infinispan can miss incoming commands with JGroupsChannelLookup

by Pedro Ruivo (JIRA)

[ https://issues.jboss.org/browse/ISPN-6322?page=com.atlassian.jira.plugin.... ] Pedro Ruivo updated ISPN-6322: ------------------------------ Fix Version/s: 9.0.0.Alpha1 (was: 8.2.0.Final) > Infinispan can miss incoming commands with JGroupsChannelLookup > --------------------------------------------------------------- > > Key: ISPN-6322 > URL: https://issues.jboss.org/browse/ISPN-6322 > Project: Infinispan > Issue Type: Bug > Components: Core > Affects Versions: 8.2.0.CR1, 8.1.2.Final > Reporter: Dan Berindei > Assignee: Dan Berindei > Fix For: 9.0.0.Alpha1 > > > Normally, the JGroupsTransport startup sequence goes like this: > # Create the {{Channel}} > # Create the {{CommandAwareRpcDispatcher}} and install it as an {{UpHandler}} > # Connect the channel > This way, every {{RequestCorrelator}} message received by the channel is passed up to {{CommandAwareRpcDispatcher}}, which executes the appropriate command. > When using a {{JGroupsChannelLookup}}, the lookup implementation is allowed to return a {{Channel}} instance that is already connected ({{shouldConnect() == false}}). That means there is now a window where the channel doesn't have an {{UpHandler}}, and messages sent to this node are discarded. > Normally a node only receives commands after it sent a join request to the coordinator. There are however a few exceptions: > # On startup, {[LocalTopologyManagerImpl}} sends the join request to the JGroups coordinator, which may not have the {{UpHandler}} yet. This seems to be responsible for the recent hanging in {{ConcurrentStartTest}}. We have a workaround here, to use a smaller timeout on the {{CacheTopologyControlCommand(JOIN)}} command, and retry it on {{TimeoutException}}. > # When a node becomes coordinator, {{ClusterTopologyManagerImpl}} broadcasts a {{GET_STATUS}} request to all cluster members, and expects a response from each of them. The same workaround with a smaller timeout and retries might work here. > # In replicated mode, write commands are broadcasted to all cluster members. There is some commented out code in {{RpcManagerImpl.invokeRemotelyAsync()}} that might fix it by only waiting for responses from the cache topology members. > We should consider deprecating {{JGroupsChannelLookup.shouldConnect()}} and requiring that the channel is only connected by {{JGroupsTransport}}. Assuming that works with {{ForkChannel}}, of course. -- 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: -------------------------------- Git Pull Request: https://github.com/infinispan/infinispan/pull/4087, https://github.com/infinispan/infinispan/pull/4092 (was: 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: Adrian Nistor > Priority: Blocker > Fix For: 8.2.0.Final, 8.1.3.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: -------------------------------- Fix Version/s: 8.1.3.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: Adrian Nistor > Priority: Blocker > Fix For: 8.2.0.Final, 8.1.3.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 reassigned ISPN-6323: ----------------------------------- Assignee: Adrian Nistor (was: Pedro Ruivo) > 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: Adrian Nistor > 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-6293) Registering a clustered listener in a DIST cluster leads to SuspectException if one member is not joined yet

by Adrian Nistor (JIRA)

[ https://issues.jboss.org/browse/ISPN-6293?page=com.atlassian.jira.plugin.... ] Adrian Nistor commented on ISPN-6293: ------------------------------------- I've cherry-picked this one to 8.1.x too. > Registering a clustered listener in a DIST cluster leads to SuspectException if one member is not joined yet > ------------------------------------------------------------------------------------------------------------ > > Key: ISPN-6293 > URL: https://issues.jboss.org/browse/ISPN-6293 > Project: Infinispan > Issue Type: Bug > Affects Versions: 8.2.0.Beta2 > Reporter: Adrian Nistor > Assignee: William Burns > Fix For: 8.2.0.Final, 8.1.3.Final > > > Reproducer: > {code} > import org.infinispan.configuration.cache.CacheMode; > import org.infinispan.configuration.cache.ConfigurationBuilder; > import org.infinispan.notifications.Listener; > import org.infinispan.notifications.cachelistener.annotation.CacheEntryCreated; > import org.infinispan.notifications.cachelistener.event.CacheEntryEvent; > import org.infinispan.test.MultipleCacheManagersTest; > import org.testng.annotations.Test; > @Test(groups = "functional", testName = "ClusteredListenerJoinsTest") > public class ClusteredListenerJoinsTest extends MultipleCacheManagersTest { > @Listener(clustered = true) > private static final class NoOpListener { > @CacheEntryCreated > public void handleEvent(CacheEntryEvent<Object, Object> e) { > } > } > @Override > protected void createCacheManagers() { > ConfigurationBuilder c = buildConfiguration(); > createCluster(c, 3); > waitForClusterToForm(); > } > private ConfigurationBuilder buildConfiguration() { > ConfigurationBuilder c = getDefaultClusteredCacheConfig(CacheMode.DIST_SYNC, false); //unreproducible with CacheMode.REPL_SYNC > c.clustering().hash().numOwners(2); > return c; > } > public void testJoins() { > cache(0).addListener(new NoOpListener()); > addClusterEnabledCacheManager(buildConfiguration()); > //waitForClusterToForm(); > cache(0).addListener(new NoOpListener()); //fails most times with SuspectException; uncomment the line above to ensure it does not fail > } > } > {code} -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 1 month

1
0
0 / 0

[JBoss JIRA] (ISPN-6293) Registering a clustered listener in a DIST cluster leads to SuspectException if one member is not joined yet

by Adrian Nistor (JIRA)

[ https://issues.jboss.org/browse/ISPN-6293?page=com.atlassian.jira.plugin.... ] Adrian Nistor updated ISPN-6293: -------------------------------- Fix Version/s: 8.1.3.Final > Registering a clustered listener in a DIST cluster leads to SuspectException if one member is not joined yet > ------------------------------------------------------------------------------------------------------------ > > Key: ISPN-6293 > URL: https://issues.jboss.org/browse/ISPN-6293 > Project: Infinispan > Issue Type: Bug > Affects Versions: 8.2.0.Beta2 > Reporter: Adrian Nistor > Assignee: William Burns > Fix For: 8.2.0.Final, 8.1.3.Final > > > Reproducer: > {code} > import org.infinispan.configuration.cache.CacheMode; > import org.infinispan.configuration.cache.ConfigurationBuilder; > import org.infinispan.notifications.Listener; > import org.infinispan.notifications.cachelistener.annotation.CacheEntryCreated; > import org.infinispan.notifications.cachelistener.event.CacheEntryEvent; > import org.infinispan.test.MultipleCacheManagersTest; > import org.testng.annotations.Test; > @Test(groups = "functional", testName = "ClusteredListenerJoinsTest") > public class ClusteredListenerJoinsTest extends MultipleCacheManagersTest { > @Listener(clustered = true) > private static final class NoOpListener { > @CacheEntryCreated > public void handleEvent(CacheEntryEvent<Object, Object> e) { > } > } > @Override > protected void createCacheManagers() { > ConfigurationBuilder c = buildConfiguration(); > createCluster(c, 3); > waitForClusterToForm(); > } > private ConfigurationBuilder buildConfiguration() { > ConfigurationBuilder c = getDefaultClusteredCacheConfig(CacheMode.DIST_SYNC, false); //unreproducible with CacheMode.REPL_SYNC > c.clustering().hash().numOwners(2); > return c; > } > public void testJoins() { > cache(0).addListener(new NoOpListener()); > addClusterEnabledCacheManager(buildConfiguration()); > //waitForClusterToForm(); > cache(0).addListener(new NoOpListener()); //fails most times with SuspectException; uncomment the line above to ensure it does not fail > } > } > {code} -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 1 month

1
0
0 / 0

[JBoss JIRA] (ISPN-6067) ClientAsymmetricClusterTest broken

by Radim Vansa (JIRA)

[ https://issues.jboss.org/browse/ISPN-6067?page=com.atlassian.jira.plugin.... ] Radim Vansa resolved ISPN-6067. ------------------------------- Resolution: Duplicate Issue > ClientAsymmetricClusterTest broken > ---------------------------------- > > Key: ISPN-6067 > URL: https://issues.jboss.org/browse/ISPN-6067 > Project: Infinispan > Issue Type: Bug > Components: Remote Protocols > Affects Versions: 8.1.0.Final > Reporter: Radim Vansa > > When the TransportObjectFactory is created, it executes a first ping in which it gets the topology. > When the test tries to retrieve cache 'asymmetricCache' which is defined only on one node, another ping is executed, checking the presence of this cache. However, the ping can go to any node, and therefore it may fail to retrieve the cache and cache manager returns null, which results in NPE in the test. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 1 month

1
0
0 / 0

[JBoss JIRA] (ISPN-6341) StateTransferManager should be the first component to stop

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/ISPN-6341?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration updated ISPN-6341: ------------------------------------------ Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1315393 Bugzilla Update: Perform > StateTransferManager should be the first component to stop > ---------------------------------------------------------- > > Key: ISPN-6341 > URL: https://issues.jboss.org/browse/ISPN-6341 > Project: Infinispan > Issue Type: Bug > Components: Core > Affects Versions: 8.2.0.CR1 > Reporter: Dan Berindei > Assignee: Dan Berindei > > When a cache stops, it first removes the component registry from the {{GlobalComponentsRegistry}}'s {{namedComponents}} map, which means the node (let's call it {{A}}) will reply with a {{CacheNotFoundResponse}} to any remote command. > Another node {{B}} trying to execute a write/transactional command will receive the {{CacheNotFoundResponse}}, assume that a new cache topology with id {{current topology id + 1}} is coming soon, and wait for that new topology before retrying. > Normally this is not a problem, because {{StateTransferManagerImpl.stop()}} sends a {{CacheTopologyControlCommand(LEAVE)}} to the coordinator quickly enough, then {{B}} receives the {{current topology id + 1}} topology and retries the command. > But in some cases, the cache components that stop before {{StateTransferManagerImpl}} can take a long time to do so. In particular, because of {{ISPN-5507}}, {{TransactionTable}} can block for {{cacheStopTimeout}} if there are remote transactions in progress, even though the cache can no longer process remote commands. > We should give {{StateTransferManagerImpl.stop()}} a priority of {{0}}, so that the {{CacheTopologyControlCommand(LEAVE)}} comand is sent as soon as possible. -- 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