January 2020 - infinispan-issues - Jboss List Archives

[JBoss JIRA] (ISPN-11164) Docs: Clustered max idle updates

by Donald Naro (Jira)

[ https://issues.redhat.com/browse/ISPN-11164?page=com.atlassian.jira.plugi... ] Donald Naro updated ISPN-11164: ------------------------------- Status: Pull Request Sent (was: Open) Git Pull Request: https://github.com/infinispan/infinispan/pull/7742 > Docs: Clustered max idle updates > -------------------------------- > > Key: ISPN-11164 > URL: https://issues.redhat.com/browse/ISPN-11164 > Project: Infinispan > Issue Type: Enhancement > Components: Documentation > Reporter: Donald Naro > Assignee: Donald Naro > Priority: Major > > whenever an entry is read that can expire via max idle, we send a touch command to all owners so they all have the same relative access time. the get won't return until the touch command has completed. > scattered the backup can be any node and we don't know which nodes are backups. in this case the touch command goes to all nodes. > if you have max idle and eviction, any access of an entry on any node will update the eviction recency on all owners as well -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 2 months

1
0
0 / 0

[JBoss JIRA] (ISPN-11148) CLI hangs on exit after connection failure

by Dan Berindei (Jira)

[ https://issues.redhat.com/browse/ISPN-11148?page=com.atlassian.jira.plugi... ] Dan Berindei updated ISPN-11148: -------------------------------- Status: Resolved (was: Pull Request Sent) Resolution: Done > CLI hangs on exit after connection failure > ------------------------------------------ > > Key: ISPN-11148 > URL: https://issues.redhat.com/browse/ISPN-11148 > Project: Infinispan > Issue Type: Bug > Components: CLI > Affects Versions: 10.1.0.Final > Reporter: Tristan Tarrant > Assignee: Tristan Tarrant > Priority: Major > Fix For: 10.1.1.Final > > > Whenever the CLI fails to connect to the server, it will hang on exit. This also happens when attempting to connect to a server with authentication without providing credentials on the connection command. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 2 months

1
0
0 / 0

[JBoss JIRA] (ISPN-11150) The server should display its main URL in the logs

by Dan Berindei (Jira)

[ https://issues.redhat.com/browse/ISPN-11150?page=com.atlassian.jira.plugi... ] Dan Berindei updated ISPN-11150: -------------------------------- Status: Resolved (was: Pull Request Sent) Resolution: Done > The server should display its main URL in the logs > -------------------------------------------------- > > Key: ISPN-11150 > URL: https://issues.redhat.com/browse/ISPN-11150 > Project: Infinispan > Issue Type: Enhancement > Components: Server > Affects Versions: 10.1.0.Final > Reporter: Tristan Tarrant > Assignee: Tristan Tarrant > Priority: Major > Fix For: 10.1.1.Final > > > The server should display a message with the URL of the main endpoint. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 2 months

1
0
0 / 0

[JBoss JIRA] (ISPN-11149) The CLI should have a dedicated log4j configuration

by Dan Berindei (Jira)

[ https://issues.redhat.com/browse/ISPN-11149?page=com.atlassian.jira.plugi... ] Dan Berindei updated ISPN-11149: -------------------------------- Status: Resolved (was: Pull Request Sent) Resolution: Done > The CLI should have a dedicated log4j configuration > --------------------------------------------------- > > Key: ISPN-11149 > URL: https://issues.redhat.com/browse/ISPN-11149 > Project: Infinispan > Issue Type: Bug > Components: CLI > Reporter: Tristan Tarrant > Assignee: Tristan Tarrant > Priority: Major > Fix For: 10.1.1.Final > > > ISPN-11131 made the server and CLI use log4j 2.x but did not add a logging config for the CLI. We should provide one. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 2 months

1
0
0 / 0

[JBoss JIRA] (ISPN-11167) Retrying transactions after WriteSkewException should be easier

by Dan Berindei (Jira)

Dan Berindei created ISPN-11167: ----------------------------------- Summary: Retrying transactions after WriteSkewException should be easier Key: ISPN-11167 URL: https://issues.redhat.com/browse/ISPN-11167 Project: Infinispan Issue Type: Bug Components: Core, Documentation Affects Versions: 10.1.0.Final Reporter: Dan Berindei Fix For: 11.0.0.Final I've added the documentation tag because we "know" users of optimistic transactions should catch {{WriteSkewException}}s and retry, but the user guide never explains how a user should do it. It turns out the exception tree is really complicated: {noformat} javax.transaction.RollbackException: ARJUNA016053: Could not commit transaction. at com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionImple.commitAndDisassociate(TransactionImple.java:1299) Suppressed: javax.transaction.xa.XAException at org.infinispan.transaction.impl.TransactionCoordinator.prepare(TransactionCoordinator.java:143) Caused by: org.infinispan.remoting.RemoteException: ISPN000217: Received exception from ... at org.infinispan.remoting.transport.ResponseCollectors.wrapRemoteException(ResponseCollectors.java:25) Suppressed: org.infinispan.util.logging.TraceException at org.infinispan.interceptors.impl.SimpleAsyncInvocationStage.get(SimpleAsyncInvocationStage.java:39) Caused by: org.infinispan.transaction.WriteSkewException: Write skew detected on key ... at org.infinispan.marshall.exts.ThrowableExternalizer.readObject(ThrowableExternalizer.java:257) {noformat} Part of the problem is internal: we shouldn't wrap {{WriteSkewException}} in a {{RemoteException}}. The other part is harder to control: Narayana makes our {{XAException}} a suppressed exception instead of a cause, probably because in the general case multiple XA resources could fail to prepare. Initially I thought the XAException was suppressed because Narayana committed the transaction in one phase, but I disabled {{CoordinatorEnvironmentBean.commitOnePhase}} and it's still suppressed. OTOH the exception tree could be much simpler with {{useSynchronization(true)}}, if it weren't for our own gratuitous wrapping: {noformat} javax.transaction.RollbackException: ARJUNA016053: Could not commit transaction. at com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionImple.commitAndDisassociate(TransactionImple.java:1299) Caused by: org.infinispan.commons.CacheException: Could not prepare. at org.infinispan.transaction.impl.TransactionTable.beforeCompletion(TransactionTable.java:898) Caused by: javax.transaction.xa.XAException at org.infinispan.transaction.impl.TransactionCoordinator.prepare(TransactionCoordinator.java:143) Caused by: org.infinispan.remoting.RemoteException: ISPN000217: Received exception from ... at org.infinispan.remoting.transport.ResponseCollectors.wrapRemoteException(ResponseCollectors.java:25) Suppressed: org.infinispan.util.logging.TraceException at org.infinispan.interceptors.impl.SimpleAsyncInvocationStage.get(SimpleAsyncInvocationStage.java:39) Caused by: org.infinispan.transaction.WriteSkewException: Write skew detected on key ... at org.infinispan.marshall.exts.ThrowableExternalizer.readObject(ThrowableExternalizer.java:257) {noformat} We could remove the {{CacheException}}, the {{XAException}}, and the {{RemoteException}}, leaving just a {{RollbackException}} caused by a {{WriteSkewException}}. For implicit transactions we add yet another wrapper: sync operations wrap the {{RollbackException}} in a {{CacheException}}, async operations wrap it in a {{CompletionException}}. We could instead check if the exception is caused by a {{WriteSkewException}} and unwrap it. We should definitely add a helper static method for the users to check if they should retry the transaction, something like {{CacheTransactions.isWriteSkew(RollbackException)}}, and we should change the write skew to use it. Currently they are content to catch a {{RollbackException}} and assume it has a {{WriteSkewException}} inside. We should also add a {{useSynchronization}} parameter to {{AbstractClusteredWriteSkewTest}} and all the write skew tests. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 2 months

1
0
0 / 0

[JBoss JIRA] (ISPN-11166) SocketTimeoutFailureRetryTest random failures

by Dan Berindei (Jira)

Dan Berindei created ISPN-11166: ----------------------------------- Summary: SocketTimeoutFailureRetryTest random failures Key: ISPN-11166 URL: https://issues.redhat.com/browse/ISPN-11166 Project: Infinispan Issue Type: Bug Components: Server, Test Suite Affects Versions: 10.1.0.Final Reporter: Dan Berindei Assignee: Dan Berindei Fix For: 10.1.1.Final Replicated non-tx caches without stores have an optimization for get operations to bypass the interceptor chain and query the data container directly. The optimization was added with the non-blocking listener changes, in order to compensate their overhead, but it only covered {{get()}} and {{getAsync()}}, while the HotRod server uses {{getCacheEntryAsync()}}. The ISPN-11020 fix extended the replicated get optimization to {{getCacheEntryAsync()}}, so now HotRod replicated reads bypass the interceptor chain, including the {{DelayingInterceptor}} added by {{SocketTimeoutFailureRetryTest}}. {noformat} java.lang.AssertionError: expected:<1> but was:<0> at org.testng.AssertJUnit.fail(AssertJUnit.java:59) at org.testng.AssertJUnit.failNotEquals(AssertJUnit.java:364) at org.testng.AssertJUnit.assertEquals(AssertJUnit.java:80) at org.testng.AssertJUnit.assertEquals(AssertJUnit.java:170) at org.testng.AssertJUnit.assertEquals(AssertJUnit.java:177) at org.infinispan.client.hotrod.retry.SocketTimeoutFailureRetryTest.testRetrySocketTimeout(SocketTimeoutFailureRetryTest.java:68) {noformat} -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 2 months

1
0
0 / 0

[JBoss JIRA] (ISPN-11166) SocketTimeoutFailureRetryTest random failures

by Dan Berindei (Jira)

[ https://issues.redhat.com/browse/ISPN-11166?page=com.atlassian.jira.plugi... ] Dan Berindei updated ISPN-11166: -------------------------------- Status: Open (was: New) > SocketTimeoutFailureRetryTest random failures > --------------------------------------------- > > Key: ISPN-11166 > URL: https://issues.redhat.com/browse/ISPN-11166 > Project: Infinispan > Issue Type: Bug > Components: Server, Test Suite > Affects Versions: 10.1.0.Final > Reporter: Dan Berindei > Assignee: Dan Berindei > Priority: Major > Labels: testsuite_stability > Fix For: 10.1.1.Final > > > Replicated non-tx caches without stores have an optimization for get operations to bypass the interceptor chain and query the data container directly. The optimization was added with the non-blocking listener changes, in order to compensate their overhead, but it only covered {{get()}} and {{getAsync()}}, while the HotRod server uses {{getCacheEntryAsync()}}. > The ISPN-11020 fix extended the replicated get optimization to {{getCacheEntryAsync()}}, so now HotRod replicated reads bypass the interceptor chain, including the {{DelayingInterceptor}} added by {{SocketTimeoutFailureRetryTest}}. > {noformat} > java.lang.AssertionError: expected:<1> but was:<0> > at org.testng.AssertJUnit.fail(AssertJUnit.java:59) > at org.testng.AssertJUnit.failNotEquals(AssertJUnit.java:364) > at org.testng.AssertJUnit.assertEquals(AssertJUnit.java:80) > at org.testng.AssertJUnit.assertEquals(AssertJUnit.java:170) > at org.testng.AssertJUnit.assertEquals(AssertJUnit.java:177) > at org.infinispan.client.hotrod.retry.SocketTimeoutFailureRetryTest.testRetrySocketTimeout(SocketTimeoutFailureRetryTest.java:68) > {noformat} -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 2 months

1
0
0 / 0

[JBoss JIRA] (ISPN-11165) Remove JBossTS dependency

by Dan Berindei (Jira)

[ https://issues.redhat.com/browse/ISPN-11165?page=com.atlassian.jira.plugi... ] Dan Berindei updated ISPN-11165: -------------------------------- Status: Open (was: New) > Remove JBossTS dependency > ------------------------- > > Key: ISPN-11165 > URL: https://issues.redhat.com/browse/ISPN-11165 > Project: Infinispan > Issue Type: Task > Components: Dependency > Affects Versions: 10.1.0.Final > Reporter: Dan Berindei > Priority: Major > Fix For: 10.1.1.Final > > > We already have Narayana, which is JBossTS 5, so there's no need to keep JBossTS 4.x around. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 2 months

1
0
0 / 0

[JBoss JIRA] (ISPN-11165) Remove JBossTS dependency

by Dan Berindei (Jira)

[ https://issues.redhat.com/browse/ISPN-11165?page=com.atlassian.jira.plugi... ] Dan Berindei reassigned ISPN-11165: ----------------------------------- Assignee: Dan Berindei > Remove JBossTS dependency > ------------------------- > > Key: ISPN-11165 > URL: https://issues.redhat.com/browse/ISPN-11165 > Project: Infinispan > Issue Type: Task > Components: Dependency > Affects Versions: 10.1.0.Final > Reporter: Dan Berindei > Assignee: Dan Berindei > Priority: Major > Fix For: 10.1.1.Final > > > We already have Narayana, which is JBossTS 5, so there's no need to keep JBossTS 4.x around. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 2 months

1
0
0 / 0

[JBoss JIRA] (ISPN-11165) Remove JBossTS dependency

by Dan Berindei (Jira)

Dan Berindei created ISPN-11165: ----------------------------------- Summary: Remove JBossTS dependency Key: ISPN-11165 URL: https://issues.redhat.com/browse/ISPN-11165 Project: Infinispan Issue Type: Task Components: Dependency Affects Versions: 10.1.0.Final Reporter: Dan Berindei Fix For: 10.1.1.Final We already have Narayana, which is JBossTS 5, so there's no need to keep JBossTS 4.x around. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 2 months

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

infinispan-issues January 2020