June 2020 - infinispan-issues - Jboss List Archives

[JBoss JIRA] (ISPN-11176) XSite Max Idle

by Tristan Tarrant (Jira)

[ https://issues.redhat.com/browse/ISPN-11176?page=com.atlassian.jira.plugi... ] Tristan Tarrant updated ISPN-11176: ----------------------------------- Fix Version/s: 12.0.0.Final (was: 11.0.0.Final) > XSite Max Idle > -------------- > > Key: ISPN-11176 > URL: https://issues.redhat.com/browse/ISPN-11176 > Project: Infinispan > Issue Type: Enhancement > Components: Cross-Site Replication, Expiration > Reporter: Will Burns > Priority: Major > Fix For: 12.0.0.Final > > > Max idle expiration currently doesn't work with xsite. That is if an entry was written and replicated to both sites but one site never reads the value, but the other does. If they then need to read the value from the other site it will be expired (assuming the max idle time has elapsed). > There are a few ways we can do this. > 1. Keep access times local to every site. When a site finds an entry is expired it asks the other site(s) if it has a more recent access. If a site is known to have gone down we should touch all entries, since they may not have updated access times. Requires very little additional xsite communication. > 2. Batch touch commands and only send every so often. Has window of loss, but should be small. Requires more site usage. Wouldn't work for really low max idle times as an entry could expire before the touch command is replicated. -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 9 months

1
0
0 / 0

[JBoss 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.0.0.Final (was: 11.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.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)

5 years, 9 months

1
0
0 / 0

[JBoss JIRA] (ISPN-11137) Remove AdvancedCache.removeLifespanExpired and removeMaxIdleExpired

by Tristan Tarrant (Jira)

[ https://issues.redhat.com/browse/ISPN-11137?page=com.atlassian.jira.plugi... ] Tristan Tarrant updated ISPN-11137: ----------------------------------- Fix Version/s: 12.0.0.Final (was: 11.0.0.Final) > Remove AdvancedCache.removeLifespanExpired and removeMaxIdleExpired > ------------------------------------------------------------------- > > Key: ISPN-11137 > URL: https://issues.redhat.com/browse/ISPN-11137 > Project: Infinispan > Issue Type: Bug > Components: Core > Affects Versions: 10.1.0.Final > Reporter: Dan Berindei > Assignee: Will Burns > Priority: Major > Fix For: 12.0.0.Final > > > {{removeLifespanExpired}} and {{removeMaxIdleExpired}} are in the {{AdvancedCache}} interface, but they are only for internal use, not public API. > We should remove them, and {{ClusterExpirationManager.removeMaxIdle()}} should create a {{RemoveExpiredCommand}} and execute it with the invocation chain just like {{org.infinispan.cache.impl.CacheImpl.performRemoveExpiredCommand()}} does. -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 9 months

1
0
0 / 0

[JBoss 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.0.0.Final (was: 11.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.0.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 (v7.13.8#713008)

5 years, 9 months

1
0
0 / 0

[JBoss 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.0.0.Final (was: 11.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.0.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 (v7.13.8#713008)

5 years, 9 months

1
0
0 / 0

[JBoss JIRA] (ISPN-11248) Add test for ServerTask that utilizes protostream stored entries

by Tristan Tarrant (Jira)

[ https://issues.redhat.com/browse/ISPN-11248?page=com.atlassian.jira.plugi... ] Tristan Tarrant updated ISPN-11248: ----------------------------------- Fix Version/s: 12.0.0.Final (was: 11.0.0.Final) > Add test for ServerTask that utilizes protostream stored entries > ---------------------------------------------------------------- > > Key: ISPN-11248 > URL: https://issues.redhat.com/browse/ISPN-11248 > Project: Infinispan > Issue Type: Task > Reporter: Will Burns > Priority: Major > Fix For: 12.0.0.Final > > > We currently have a single ServerTask that just prints out "Hello <name>". We should add a new test that actually tests a very likely use case of storing entries in protostream and using a task that deserializes them properly (this could be done automatically by the encoding layer of the cache, if it is working). > We may also want to look into sharing this with a custom loader, as we have users doing this today. And it is quite clunky, so we can see how the usability is in 11.0. -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 9 months

1
0
0 / 0

[JBoss JIRA] (ISPN-11254) Remove maven-failsafe-plugin in infinispan-server-runtime

by Tristan Tarrant (Jira)

[ https://issues.redhat.com/browse/ISPN-11254?page=com.atlassian.jira.plugi... ] Tristan Tarrant updated ISPN-11254: ----------------------------------- Fix Version/s: 12.0.0.Final (was: 11.0.0.Final) > Remove maven-failsafe-plugin in infinispan-server-runtime > --------------------------------------------------------- > > Key: ISPN-11254 > URL: https://issues.redhat.com/browse/ISPN-11254 > Project: Infinispan > Issue Type: Bug > Components: Server, Test Suite > Affects Versions: 10.1.1.Final > Reporter: Dan Berindei > Priority: Minor > Fix For: 12.0.0.Final > > > {{infinispan-server-runtime}} uses both {{maven-surefire-plugin}} and {{maven-failsafe-plugin}}, which makes it confusing sometimes. E.g. when trying to run a single integration test with {{-Dit.test=SomeIT}}, the surefire tests still run. > {{maven-failsafe-plugin}} 3.0.0 is supposed to replace {{-DskipTests}} with {{-DskipITs}}, so both {{-DskipTests -Dit.test=SomeIT}} and {{-DskipITs -Dtest=SomeTest}} will work. They haven't yet removed it in version 3.0.0-M4, but if we decide to keep both plugins after all, we can emulate the new behaviour with > {code:xml} > <skipTests>${skipITs}</skipTests> > {code} -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 9 months

1
0
0 / 0

[JBoss JIRA] (ISPN-11277) Off Heap expiration with custom metadata doesn't work

by Tristan Tarrant (Jira)

[ https://issues.redhat.com/browse/ISPN-11277?page=com.atlassian.jira.plugi... ] Tristan Tarrant updated ISPN-11277: ----------------------------------- Fix Version/s: 12.0.0.Final (was: 11.0.0.Final) > Off Heap expiration with custom metadata doesn't work > ----------------------------------------------------- > > Key: ISPN-11277 > URL: https://issues.redhat.com/browse/ISPN-11277 > Project: Infinispan > Issue Type: Bug > Components: Core, Off Heap > Reporter: Will Burns > Priority: Major > Fix For: 12.0.0.Final > > > Off heap assumed when a custom metadata was used that it didn't have to track expiration. However this is incorrect, we need to make sure to track the expiration values (created and/or last used) so it can expire properly. -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 9 months

1
0
0 / 0

[JBoss 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.0.0.Final (was: 11.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.0.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 (v7.13.8#713008)

5 years, 9 months

1
0
0 / 0

[JBoss 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.0.0.Final (was: 11.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.0.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 (v7.13.8#713008)

5 years, 9 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 June 2020