March 2016 - infinispan-issues - Jboss List Archives

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

by Tristan Tarrant (JIRA)

[ https://issues.jboss.org/browse/ISPN-6384?page=com.atlassian.jira.plugin.... ] Tristan Tarrant updated ISPN-6384: ---------------------------------- Status: Resolved (was: Pull Request Sent) Fix Version/s: 9.0.0.Final Resolution: Done > 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.Final, 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-6322) Infinispan can miss incoming commands with JGroupsChannelLookup

by Tristan Tarrant (JIRA)

[ https://issues.jboss.org/browse/ISPN-6322?page=com.atlassian.jira.plugin.... ] Tristan Tarrant updated ISPN-6322: ---------------------------------- Status: Resolved (was: Pull Request Sent) Fix Version/s: 9.0.0.Final 8.2.1.Final Resolution: Done > 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.Final, 9.0.0.Alpha1, 8.2.1.Final > > > 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-6385) TwoNodesTests fails

by Dan Berindei (JIRA)

[ https://issues.jboss.org/browse/ISPN-6385?page=com.atlassian.jira.plugin.... ] Dan Berindei commented on ISPN-6385: ------------------------------------ [~sebastian.laskawiec] How does it fail? Why? > 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 > Fix For: 9.0.0.Final, 9.0.0.Alpha1, 8.2.1.Final > > -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years

1
0
0 / 0

[JBoss JIRA] (ISPN-6415) Allow duplicate JMX domains in JPA cache store testsuite

by Tristan Tarrant (JIRA)

[ https://issues.jboss.org/browse/ISPN-6415?page=com.atlassian.jira.plugin.... ] Tristan Tarrant updated ISPN-6415: ---------------------------------- Status: Open (was: New) > Allow duplicate JMX domains in JPA cache store testsuite > -------------------------------------------------------- > > Key: ISPN-6415 > URL: https://issues.jboss.org/browse/ISPN-6415 > Project: Infinispan > Issue Type: Bug > Components: Test Suite - Core > Affects Versions: 8.2.0.Final > Reporter: Jiří Holuša > Assignee: Jiří Holuša > Fix For: 9.0.0.Final, 9.0.0.Alpha1 > > > When executing JPA cache store tests, I get failing org.infinispan.persistence.jpa.JpaConfigurationTest.testXmlConfig due to clash of JMX domain. > Allowing the duplicate domains solves the problem and since it's only for testing purposes, I guess this is acceptable solution. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years

1
0
0 / 0

[JBoss JIRA] (ISPN-6415) Allow duplicate JMX domains in JPA cache store testsuite

by Tristan Tarrant (JIRA)

[ https://issues.jboss.org/browse/ISPN-6415?page=com.atlassian.jira.plugin.... ] Tristan Tarrant updated ISPN-6415: ---------------------------------- Status: Pull Request Sent (was: Open) > Allow duplicate JMX domains in JPA cache store testsuite > -------------------------------------------------------- > > Key: ISPN-6415 > URL: https://issues.jboss.org/browse/ISPN-6415 > Project: Infinispan > Issue Type: Bug > Components: Test Suite - Core > Affects Versions: 8.2.0.Final > Reporter: Jiří Holuša > Assignee: Jiří Holuša > Fix For: 9.0.0.Final, 9.0.0.Alpha1 > > > When executing JPA cache store tests, I get failing org.infinispan.persistence.jpa.JpaConfigurationTest.testXmlConfig due to clash of JMX domain. > Allowing the duplicate domains solves the problem and since it's only for testing purposes, I guess this is acceptable solution. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years

1
0
0 / 0

[JBoss JIRA] (ISPN-6415) Allow duplicate JMX domains in JPA cache store testsuite

by Tristan Tarrant (JIRA)

[ https://issues.jboss.org/browse/ISPN-6415?page=com.atlassian.jira.plugin.... ] Tristan Tarrant updated ISPN-6415: ---------------------------------- Status: Resolved (was: Pull Request Sent) Fix Version/s: 9.0.0.Final 9.0.0.Alpha1 Resolution: Done > Allow duplicate JMX domains in JPA cache store testsuite > -------------------------------------------------------- > > Key: ISPN-6415 > URL: https://issues.jboss.org/browse/ISPN-6415 > Project: Infinispan > Issue Type: Bug > Components: Test Suite - Core > Affects Versions: 8.2.0.Final > Reporter: Jiří Holuša > Assignee: Jiří Holuša > Fix For: 9.0.0.Final, 9.0.0.Alpha1 > > > When executing JPA cache store tests, I get failing org.infinispan.persistence.jpa.JpaConfigurationTest.testXmlConfig due to clash of JMX domain. > Allowing the duplicate domains solves the problem and since it's only for testing purposes, I guess this is acceptable solution. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years

1
0
0 / 0

[JBoss JIRA] (ISPN-6424) Distributed Executor get can propagate exception if interrupt returns before cancellation

by William Burns (JIRA)

[ https://issues.jboss.org/browse/ISPN-6424?page=com.atlassian.jira.plugin.... ] William Burns updated ISPN-6424: -------------------------------- Status: Pull Request Sent (was: Open) Git Pull Request: https://github.com/infinispan/infinispan/pull/4162 > Distributed Executor get can propagate exception if interrupt returns before cancellation > ----------------------------------------------------------------------------------------- > > Key: ISPN-6424 > URL: https://issues.jboss.org/browse/ISPN-6424 > Project: Infinispan > Issue Type: Bug > Components: Distributed Execution and Map/Reduce > Reporter: William Burns > Fix For: 9.0.0.Alpha1 > > > This can cause get method to return an exception of the operation being interrupted instead of a CancellationException as it should. > This causes a test failure http://ci.infinispan.org/viewLog.html?buildId=37756&tab=buildResultsDiv&b... -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years

1
0
0 / 0

[JBoss JIRA] (ISPN-6424) Distributed Executor get can propagate exception if interrupt returns before cancellation

by William Burns (JIRA)

William Burns created ISPN-6424: ----------------------------------- Summary: Distributed Executor get can propagate exception if interrupt returns before cancellation Key: ISPN-6424 URL: https://issues.jboss.org/browse/ISPN-6424 Project: Infinispan Issue Type: Bug Components: Distributed Execution and Map/Reduce Reporter: William Burns Fix For: 9.0.0.Alpha1 This can cause get method to return an exception of the operation being interrupted instead of a CancellationException as it should. This causes a test failure http://ci.infinispan.org/viewLog.html?buildId=37756&tab=buildResultsDiv&b... -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years

1
0
0 / 0

[JBoss JIRA] (ISPN-6424) Distributed Executor get can propagate exception if interrupt returns before cancellation

by William Burns (JIRA)

[ https://issues.jboss.org/browse/ISPN-6424?page=com.atlassian.jira.plugin.... ] William Burns updated ISPN-6424: -------------------------------- Status: Open (was: New) > Distributed Executor get can propagate exception if interrupt returns before cancellation > ----------------------------------------------------------------------------------------- > > Key: ISPN-6424 > URL: https://issues.jboss.org/browse/ISPN-6424 > Project: Infinispan > Issue Type: Bug > Components: Distributed Execution and Map/Reduce > Reporter: William Burns > Fix For: 9.0.0.Alpha1 > > > This can cause get method to return an exception of the operation being interrupted instead of a CancellationException as it should. > This causes a test failure http://ci.infinispan.org/viewLog.html?buildId=37756&tab=buildResultsDiv&b... -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years

1
0
0 / 0

[JBoss JIRA] (ISPN-6417) Remove replication-queue support

by Dan Berindei (JIRA)

[ https://issues.jboss.org/browse/ISPN-6417?page=com.atlassian.jira.plugin.... ] Dan Berindei updated ISPN-6417: ------------------------------- Status: Open (was: New) > Remove replication-queue support > -------------------------------- > > Key: ISPN-6417 > URL: https://issues.jboss.org/browse/ISPN-6417 > Project: Infinispan > Issue Type: Task > Components: Configuration, Core > Affects Versions: 8.2.0.Final > Reporter: Dan Berindei > Assignee: Dan Berindei > Fix For: 9.0.0.Final, 9.0.0.Alpha1 > > > See ISPN-6017 for the motivation. -- 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