March 2016 - infinispan-issues - Jboss List Archives

[JBoss JIRA] (ISPN-5953) Extract interface from RemoteCacheManager

by Galder Zamarreño (JIRA)

[ https://issues.jboss.org/browse/ISPN-5953?page=com.atlassian.jira.plugin.... ] Work on ISPN-5953 started by Galder Zamarreño. ---------------------------------------------- > Extract interface from RemoteCacheManager > ----------------------------------------- > > Key: ISPN-5953 > URL: https://issues.jboss.org/browse/ISPN-5953 > Project: Infinispan > Issue Type: Enhancement > Components: CDI Integration, Integration > Reporter: Sebastian Łaskawiec > Assignee: Galder Zamarreño > Priority: Minor > Fix For: 9.0.0.Final > > > Currently RemoteCacheManager is a concrete class which is problematic when using it in CDI (CDI will register it as a bean). This is very inconvenient because this instance should be created by InfinispanEmbeddedExtension. > Since this change is not backwards compatible - we need to implement it in ISPN 9. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years

1
0
0 / 0

[JBoss JIRA] (ISPN-6385) TwoNodesTests fails

by Sebastian Łaskawiec (JIRA)

[ https://issues.jboss.org/browse/ISPN-6385?page=com.atlassian.jira.plugin.... ] Sebastian Łaskawiec updated ISPN-6385: -------------------------------------- Status: Open (was: New) > TwoNodesTests fails > ------------------- > > Key: ISPN-6385 > URL: https://issues.jboss.org/browse/ISPN-6385 > Project: Infinispan > Issue Type: Bug > Reporter: Sebastian Łaskawiec > Assignee: Sebastian Łaskawiec > Priority: Minor > -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years

1
0
0 / 0

[JBoss JIRA] (ISPN-6385) TwoNodesTests fails

by Sebastian Łaskawiec (JIRA)

[ https://issues.jboss.org/browse/ISPN-6385?page=com.atlassian.jira.plugin.... ] Sebastian Łaskawiec updated ISPN-6385: -------------------------------------- Status: Pull Request Sent (was: Open) Git Pull Request: https://github.com/infinispan/infinispan/pull/4134 > TwoNodesTests fails > ------------------- > > Key: ISPN-6385 > URL: https://issues.jboss.org/browse/ISPN-6385 > Project: Infinispan > Issue Type: Bug > Reporter: Sebastian Łaskawiec > Assignee: Sebastian Łaskawiec > Priority: Minor > -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years

1
0
0 / 0

[JBoss JIRA] (ISPN-6385) TwoNodesTests fails

by Sebastian Łaskawiec (JIRA)

Sebastian Łaskawiec created ISPN-6385: ----------------------------------------- Summary: TwoNodesTests fails Key: ISPN-6385 URL: https://issues.jboss.org/browse/ISPN-6385 Project: Infinispan Issue Type: Feature Request Reporter: Sebastian Łaskawiec Assignee: Sebastian Łaskawiec Priority: Minor -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years

1
0
0 / 0

[JBoss JIRA] (ISPN-6385) TwoNodesTests fails

by Sebastian Łaskawiec (JIRA)

[ https://issues.jboss.org/browse/ISPN-6385?page=com.atlassian.jira.plugin.... ] Sebastian Łaskawiec updated ISPN-6385: -------------------------------------- Issue Type: Bug (was: Feature Request) > TwoNodesTests fails > ------------------- > > Key: ISPN-6385 > URL: https://issues.jboss.org/browse/ISPN-6385 > Project: Infinispan > Issue Type: Bug > Reporter: Sebastian Łaskawiec > Assignee: Sebastian Łaskawiec > Priority: Minor > -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years

1
0
0 / 0

[JBoss JIRA] (ISPN-6322) Infinispan can miss incoming commands with JGroupsChannelLookup

by Dan Berindei (JIRA)

[ https://issues.jboss.org/browse/ISPN-6322?page=com.atlassian.jira.plugin.... ] Dan Berindei updated ISPN-6322: ------------------------------- Status: Pull Request Sent (was: Open) Git Pull Request: https://github.com/infinispan/infinispan/pull/4133 > 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
0
0 / 0

[JBoss JIRA] (ISPN-6384) JGroupsTransport.invokeRemotelyAsync with a filter returns null on timeout

by Dan Berindei (JIRA)

[ https://issues.jboss.org/browse/ISPN-6384?page=com.atlassian.jira.plugin.... ] Dan Berindei updated ISPN-6384: ------------------------------- Status: Pull Request Sent (was: Open) Git Pull Request: https://github.com/infinispan/infinispan/pull/4133 > JGroupsTransport.invokeRemotelyAsync with a filter returns null on timeout > -------------------------------------------------------------------------- > > Key: ISPN-6384 > URL: https://issues.jboss.org/browse/ISPN-6384 > Project: Infinispan > Issue Type: Bug > Components: Core > Affects Versions: 8.2.0.Final, 9.0.0.Final > Reporter: Dan Berindei > Assignee: Dan Berindei > Fix For: 9.0.0.Alpha1, 8.2.1.Final > > > {{JGroupsTransport.invokeRemotelyAsync()}} has a {{ResponseFilter}} parameter that was traditionally used only with {{ResponseMode.GET_FIRST}}, for remote get commands. In that particular case, returning a {{null}} when some of the nodes timed out and other nodes returned invalid responses (i.e. {{null}}) was acceptable. > Since ISPN-4979, {{JGroupsTransport.invokeRemotelyAsync()}} is also used by {{ClusterTopologyManagerImpl}}, with {{ResponseMode.GET_ALL}}. Here, however, returning a {{null}} instead of throwing a {{TimeoutException}} is not acceptable. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years

1
0
0 / 0

[JBoss JIRA] (ISPN-5495) ConcurrentStartTest.testConcurrentStart random failures

by Dan Berindei (JIRA)

[ https://issues.jboss.org/browse/ISPN-5495?page=com.atlassian.jira.plugin.... ] Dan Berindei updated ISPN-5495: ------------------------------- Status: Pull Request Sent (was: Reopened) Git Pull Request: https://github.com/infinispan/infinispan/pull/4024, https://github.com/infinispan/infinispan/pull/4133 (was: https://github.com/infinispan/infinispan/pull/4024) > ConcurrentStartTest.testConcurrentStart random failures > ------------------------------------------------------- > > Key: ISPN-5495 > URL: https://issues.jboss.org/browse/ISPN-5495 > Project: Infinispan > Issue Type: Bug > Components: Core, Test Suite - Core > Affects Versions: 7.2.1.Final > Reporter: Dan Berindei > Assignee: Dan Berindei > Priority: Blocker > Labels: testsuite_stability > Fix For: 8.2.0.CR1 > > > {noformat} > org.testng.internal.thread.ThreadTimeoutException: Method org.testng.internal.TestNGMethod.testConcurrentStart() didn't finish within the time-out 60000 > at sun.misc.Unsafe.park(Native Method) > at java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:338) > at org.infinispan.test.TestingUtil.waitForRehashToComplete(TestingUtil.java:253) > {noformat} -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years

1
0
0 / 0

[JBoss JIRA] (ISPN-6384) JGroupsTransport.invokeRemotelyAsync with a filter returns null on timeout

by Dan Berindei (JIRA)

[ https://issues.jboss.org/browse/ISPN-6384?page=com.atlassian.jira.plugin.... ] Dan Berindei updated ISPN-6384: ------------------------------- Status: Open (was: New) > JGroupsTransport.invokeRemotelyAsync with a filter returns null on timeout > -------------------------------------------------------------------------- > > Key: ISPN-6384 > URL: https://issues.jboss.org/browse/ISPN-6384 > Project: Infinispan > Issue Type: Bug > Components: Core > Affects Versions: 8.2.0.Final, 9.0.0.Final > Reporter: Dan Berindei > Assignee: Dan Berindei > Fix For: 9.0.0.Alpha1, 8.2.1.Final > > > {{JGroupsTransport.invokeRemotelyAsync()}} has a {{ResponseFilter}} parameter that was traditionally used only with {{ResponseMode.GET_FIRST}}, for remote get commands. In that particular case, returning a {{null}} when some of the nodes timed out and other nodes returned invalid responses (i.e. {{null}}) was acceptable. > Since ISPN-4979, {{JGroupsTransport.invokeRemotelyAsync()}} is also used by {{ClusterTopologyManagerImpl}}, with {{ResponseMode.GET_ALL}}. Here, however, returning a {{null}} instead of throwing a {{TimeoutException}} is not acceptable. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years

1
0
0 / 0

[JBoss JIRA] (ISPN-6384) JGroupsTransport.invokeRemotelyAsync with a filter returns null on timeout

by Dan Berindei (JIRA)

Dan Berindei created ISPN-6384: ---------------------------------- Summary: JGroupsTransport.invokeRemotelyAsync with a filter returns null on timeout Key: ISPN-6384 URL: https://issues.jboss.org/browse/ISPN-6384 Project: Infinispan Issue Type: Bug Components: Core Affects Versions: 8.2.0.Final, 9.0.0.Final Reporter: Dan Berindei Assignee: Dan Berindei Fix For: 9.0.0.Alpha1, 8.2.1.Final {{JGroupsTransport.invokeRemotelyAsync()}} has a {{ResponseFilter}} parameter that was traditionally used only with {{ResponseMode.GET_FIRST}}, for remote get commands. In that particular case, returning a {{null}} when some of the nodes timed out and other nodes returned invalid responses (i.e. {{null}}) was acceptable. Since ISPN-4979, {{JGroupsTransport.invokeRemotelyAsync()}} is also used by {{ClusterTopologyManagerImpl}}, with {{ResponseMode.GET_ALL}}. Here, however, returning a {{null}} instead of throwing a {{TimeoutException}} is not acceptable. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years

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