January 2021 - infinispan-issues - Jboss List Archives

by Tristan Tarrant (Jira)

[ https://issues.redhat.com/browse/ISPN-11081?page=com.atlassian.jira.plugi... ] Tristan Tarrant updated ISPN-11081: ----------------------------------- Fix Version/s: 12.1.0.Final (was: 12.0.0.Final) > Data Store > ---------- > > Key: ISPN-11081 > URL: https://issues.redhat.com/browse/ISPN-11081 > Project: Infinispan > Issue Type: Task > Components: Core > Affects Versions: 10.1.0.CR1 > Reporter: Tristan Tarrant > Assignee: Dan Berindei > Priority: Major > Fix For: 12.1.0.Final > > > In scenarios where Infinispan is used as a persistent data store, the elasticity provided by rebalancing on scaling down (either voluntarily or because of node failure) can lead to data loss, even with persistent caches if all the owners of a segment leave the cluster before rebalancing can be completed. The remaining cluster should prevent writes to the lost segments until the nodes that own them are restarted. > It should be possible to configure Infinispan so that elasticity only applies when scaling up, i.e. adding a node will cause a rebalance. -- This message was sent by Atlassian Jira (v8.13.1#813001)

5 years, 3 months

1
0
0 / 0

[Red Hat JIRA] (ISPN-11119) Invalidation put should load previous value from stores

by Tristan Tarrant (Jira)

[ https://issues.redhat.com/browse/ISPN-11119?page=com.atlassian.jira.plugi... ] Tristan Tarrant updated ISPN-11119: ----------------------------------- Fix Version/s: 12.1.0.Final (was: 12.0.0.Final) > Invalidation put should load previous value from stores > ------------------------------------------------------- > > Key: ISPN-11119 > URL: https://issues.redhat.com/browse/ISPN-11119 > Project: Infinispan > Issue Type: Bug > Components: Core > Affects Versions: 9.3.6.Final, 9.4.17.Final, 10.0.1.Final, 10.1.0.Final > Reporter: Dan Berindei > Assignee: Dan Berindei > Priority: Major > Fix For: 12.1.0.Final > > > A {{cache.put(key, value)}} without the {{IGNORE_RETURN_VALUES}} flag should load the previous value from the store(s) and return it. > Currently the previous value is loaded only if the originator of the put is the primary owner of the key (see {{ClusteredCacheLoaderInterceptor.skipLoadForWriteCommand()}}). -- This message was sent by Atlassian Jira (v8.13.1#813001)

5 years, 3 months

1
0
0 / 0

[Red Hat JIRA] (ISPN-11212) Ensure max idle works with passivation

by Tristan Tarrant (Jira)

[ https://issues.redhat.com/browse/ISPN-11212?page=com.atlassian.jira.plugi... ] Tristan Tarrant updated ISPN-11212: ----------------------------------- Fix Version/s: 12.1.0.Final (was: 12.0.0.Final) > Ensure max idle works with passivation > -------------------------------------- > > Key: ISPN-11212 > URL: https://issues.redhat.com/browse/ISPN-11212 > Project: Infinispan > Issue Type: Bug > Components: Expiration, Loaders and Stores > Affects Versions: 10.1.1.Final > Reporter: Tristan Tarrant > Assignee: Will Burns > Priority: Major > Fix For: 12.1.0.Final > > > We need to have tests in place that ensure that maxIdle expiration works in combination with passivation. -- This message was sent by Atlassian Jira (v8.13.1#813001)

5 years, 3 months

1
0
0 / 0

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

by Tristan Tarrant (Jira)

[ https://issues.redhat.com/browse/ISPN-11167?page=com.atlassian.jira.plugi... ] Tristan Tarrant updated ISPN-11167: ----------------------------------- Fix Version/s: 12.1.0.Final (was: 12.0.0.Final) > 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 > Priority: Major > Fix For: 12.1.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 (v8.13.1#813001)

5 years, 3 months

1
0
0 / 0

[Red Hat JIRA] (ISPN-11225) Server should send stack trace to client

by Tristan Tarrant (Jira)

[ https://issues.redhat.com/browse/ISPN-11225?page=com.atlassian.jira.plugi... ] Tristan Tarrant updated ISPN-11225: ----------------------------------- Fix Version/s: 12.1.0.Final (was: 12.0.0.Final) > Server should send stack trace to client > ---------------------------------------- > > Key: ISPN-11225 > URL: https://issues.redhat.com/browse/ISPN-11225 > Project: Infinispan > Issue Type: Enhancement > Components: Server > Affects Versions: 10.1.1.Final > Reporter: Dan Berindei > Assignee: Dan Berindei > Priority: Major > Fix For: 12.1.0.Final > > > When an error happens on the server, all the client gets is the exception message. Many times that is enough, as the user can use the exception message to search the server logs, but sometimes the server logs are not available, and changing the server logging configuration is not always an option. > We don't want to fill the client logs with too server stack traces either, so we need to limit the amount of information we send with one or more of > 1. Disable server stack traces by default, and add a client configuration property to request stack traces when enabled. > 2. Don't send the full stack trace, just 5-10 stack frames (for each exception, if there's an exception chain). > 3. Don't send the stack trace for common exceptions like {{IllegalLifecycleStateException}}. -- This message was sent by Atlassian Jira (v8.13.1#813001)

5 years, 3 months

1
0
0 / 0

[Red Hat JIRA] (ISPN-11230) Remove all usages of java.util.UUID.randomUUID()

by Tristan Tarrant (Jira)

[ https://issues.redhat.com/browse/ISPN-11230?page=com.atlassian.jira.plugi... ] Tristan Tarrant updated ISPN-11230: ----------------------------------- Fix Version/s: 12.1.0.Final (was: 12.0.0.Final) > Remove all usages of java.util.UUID.randomUUID() > ------------------------------------------------ > > Key: ISPN-11230 > URL: https://issues.redhat.com/browse/ISPN-11230 > Project: Infinispan > Issue Type: Enhancement > Components: CLI, Core, Embedded Querying, Server > Affects Versions: 9.4.17.Final, 10.1.1.Final > Reporter: Dan Berindei > Assignee: Dan Berindei > Priority: Major > Fix For: 12.1.0.Final > > > {{java.util.UUID.randomUUID()}} uses a "cryptographically strong pseudo random number generator", which reads from {{/dev/urandom}} (or even {{/dev/random}} in older Java versions), and then computes an expensive cryptographic digest on the bytes it read. > We don't need a cryptographically strong random number, so we can use {{org.infinispan.commons.util.Util.threadLocalRandomUUID()}} instead. -- This message was sent by Atlassian Jira (v8.13.1#813001)

5 years, 3 months

1
0
0 / 0

[Red Hat JIRA] (ISPN-11223) Support tcp_keepalive_time, tcp_keepalive_intvl, tcp_keepalive_probes for our (HotRod|Rest) clients

by Tristan Tarrant (Jira)

[ https://issues.redhat.com/browse/ISPN-11223?page=com.atlassian.jira.plugi... ] Tristan Tarrant updated ISPN-11223: ----------------------------------- Fix Version/s: 12.1.0.Final (was: 12.0.0.Final) > Support tcp_keepalive_time, tcp_keepalive_intvl, tcp_keepalive_probes for our (HotRod|Rest) clients > --------------------------------------------------------------------------------------------------- > > Key: ISPN-11223 > URL: https://issues.redhat.com/browse/ISPN-11223 > Project: Infinispan > Issue Type: Enhancement > Affects Versions: 10.1.1.Final > Reporter: Diego Lovison > Assignee: Tristan Tarrant > Priority: Major > Fix For: 12.1.0.Final > > > Java11 added the ExtendedSocketOptions. > See http://hg.openjdk.java.net/jdk/jdk/rev/7164c3bb55df as a reference. > The class TcpKeepAliveTest has good examples how this should be configured -- This message was sent by Atlassian Jira (v8.13.1#813001)

5 years, 3 months

1
0
0 / 0

[Red Hat JIRA] (ISPN-11187) Completely remove support for Index.LOCAL in parser and config

by Tristan Tarrant (Jira)

[ https://issues.redhat.com/browse/ISPN-11187?page=com.atlassian.jira.plugi... ] Tristan Tarrant updated ISPN-11187: ----------------------------------- Fix Version/s: 12.1.0.Final (was: 12.0.0.Final) > Completely remove support for Index.LOCAL in parser and config > -------------------------------------------------------------- > > Key: ISPN-11187 > URL: https://issues.redhat.com/browse/ISPN-11187 > Project: Infinispan > Issue Type: Task > Reporter: Nistor Adrian > Assignee: Nistor Adrian > Priority: Major > Labels: SearchNG > Fix For: 12.1.0.Final > > > Support for Index.LOCAL has been removed already but in some places in code we still accept it leniently and convert it to Index.PRIMARY_OWNER and issue a warning in 10.x to ease config migration. In 11 we should completely remove that also. -- This message was sent by Atlassian Jira (v8.13.1#813001)

5 years, 3 months

1
0
0 / 0

[Red Hat JIRA] (ISPN-11256) Context entries should always be MvccEntries

by Tristan Tarrant (Jira)

[ https://issues.redhat.com/browse/ISPN-11256?page=com.atlassian.jira.plugi... ] Tristan Tarrant updated ISPN-11256: ----------------------------------- Fix Version/s: 12.1.0.Final (was: 12.0.0.Final) > Context entries should always be MvccEntries > -------------------------------------------- > > Key: ISPN-11256 > URL: https://issues.redhat.com/browse/ISPN-11256 > Project: Infinispan > Issue Type: Enhancement > Components: Core > Affects Versions: 10.1.1.Final > Reporter: Dan Berindei > Priority: Major > Fix For: 12.1.0.Final > > > We optimize reads by storing {{InternalCacheEntry}} instances directly in the {{InvocationContext}}, instead of creating a {{ReadCommittedEntry}} or a {{RepeatableReadEntry}}. > This helps {{READ_COMMITTED}} behave like users expect it to, at least in local mode with OBJECT storage: since the context has a reference to the entry in the data container, the transaction sees external updates automatically. I also see this as a negative, though, becase it's practically impossible to extend it to work with distributed caches or with off-heap storage. > The downside is that reading from the entry in the context is racy, so we need {{synchronized}} blocks everywhere, and me may even be missing {{synchronized}} in some places. > It also means that things like {{ReadCommittedEntry.isLoaded()}} don't if the command that triggered the load from the store was a read, because there is no {{ReadCommittedEntry}}. > I suggest always wrapping the entry in a {{MvccEntry}}, and making {{READ_COMMITTED}} caches re-fetch the entry on every read to see external updates (maybe guarded by a flag/configuration attribute). {{SingleKeyNonTxInvocationContext}} may avoid the extra allocation by implementing {{MvccEntry}} itself. -- This message was sent by Atlassian Jira (v8.13.1#813001)

5 years, 3 months

1
0
0 / 0

[Red Hat JIRA] (ISPN-11281) Near cache should not be applied for internal caches

by Tristan Tarrant (Jira)

[ https://issues.redhat.com/browse/ISPN-11281?page=com.atlassian.jira.plugi... ] Tristan Tarrant updated ISPN-11281: ----------------------------------- Fix Version/s: 12.1.0.Final (was: 12.0.0.Final) > Near cache should not be applied for internal caches > ---------------------------------------------------- > > Key: ISPN-11281 > URL: https://issues.redhat.com/browse/ISPN-11281 > Project: Infinispan > Issue Type: Enhancement > Components: Quarkus > Affects Versions: 10.1.1.Final > Reporter: Katia Aresti > Assignee: Katia Aresti > Priority: Minor > Labels: Quarkus > Fix For: 12.1.0.Final > > > When near caching is enabled it will register a listener in an internal cache such as ___protobuf_metadata which can be used by remote clients to register metadata. The server should not allow any clients to register a listener on any of these caches. > More details, see the issue in Quarkus > https://github.com/quarkusio/quarkus/issues/3548 -- This message was sent by Atlassian Jira (v8.13.1#813001)

5 years, 3 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 2021