[JBoss JIRA] (ISPN-5803) Custom Key Results in ClassCastException in CacheLoader
by William Burns (JIRA)
[ https://issues.jboss.org/browse/ISPN-5803?page=com.atlassian.jira.plugin.... ]
William Burns updated ISPN-5803:
--------------------------------
Fix Version/s: 8.1.0.Beta2
(was: 8.1.0.Beta1)
> Custom Key Results in ClassCastException in CacheLoader
> -------------------------------------------------------
>
> Key: ISPN-5803
> URL: https://issues.jboss.org/browse/ISPN-5803
> Project: Infinispan
> Issue Type: Bug
> Components: JCache
> Affects Versions: 8.0.1.Final
> Reporter: Dan Siviter
> Assignee: Galder Zamarreño
> Fix For: 8.1.0.Beta2, 8.1.0.Final
>
>
> If a a JCache is created using a read-through {{javax.cache.integration.CacheLoader}} using a custom Serializable key (in this case {{acme.MyCache$MyKey}}) a {{ClassCastException}} is thrown when trying to pass the key value of {{org.infinispan.marshall.core.MarshalledValue}} instead of {{MarshalledValue#get()}} into the {{CacheLoader}} instance.
> {code}
> java.lang.ClassCastException: org.infinispan.marshall.core.MarshalledValue cannot be cast to acme.MyCache$MyKey
> at acme.MyCache$2.load(MyCache.java:1) [my-app-1.0.0-SNAPSHOT.jar:]
> at org.infinispan.jcache.embedded.JCacheLoaderAdapter.loadKey(JCacheLoaderAdapter.java:65) [infinispan-jcache-8.0.1.Final.jar:8.0.1.Final]
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 5 months
[JBoss JIRA] (ISPN-5728) Implement all the default methods in Java 8's Map interface
by William Burns (JIRA)
[ https://issues.jboss.org/browse/ISPN-5728?page=com.atlassian.jira.plugin.... ]
William Burns updated ISPN-5728:
--------------------------------
Fix Version/s: 8.1.0.Beta2
(was: 8.1.0.Beta1)
> Implement all the default methods in Java 8's Map interface
> -----------------------------------------------------------
>
> Key: ISPN-5728
> URL: https://issues.jboss.org/browse/ISPN-5728
> Project: Infinispan
> Issue Type: Feature Request
> Components: Core
> Affects Versions: 8.0.0.Final
> Reporter: Dan Berindei
> Fix For: 8.1.0.Beta2
>
>
> Java 8 added many new methods to the {{Map}} interface. Some of them were already present in {{ConcurrentMap}}, but others are new: {{getOrDefault()}}, {{forEach()}}, {{replaceAll()}}, {{computeIfAbsent()}}, {{computeIfPresent()}}, {{compute()}}, {{merge()}}.
> We should try to write Infinispan-specific implementations wherever that would improve correctness and/or performance.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 5 months
[JBoss JIRA] (ISPN-5933) Make RemoteQueryEngine a cache-level component
by William Burns (JIRA)
[ https://issues.jboss.org/browse/ISPN-5933?page=com.atlassian.jira.plugin.... ]
William Burns updated ISPN-5933:
--------------------------------
Fix Version/s: 8.1.0.Beta2
(was: 8.1.0.Beta1)
> Make RemoteQueryEngine a cache-level component
> ----------------------------------------------
>
> Key: ISPN-5933
> URL: https://issues.jboss.org/browse/ISPN-5933
> Project: Infinispan
> Issue Type: Enhancement
> Components: Remote Querying
> Affects Versions: 8.0.0.Final
> Reporter: Adrian Nistor
> Assignee: Adrian Nistor
> Fix For: 8.1.0.Beta2, 8.0.2.Final
>
>
> A RemoteQueryEngine is instantiated per remote query request. While this is cheap to build (it's mostly stateless and has few internal fields) it would still be better to construct it only once during module init and register in the component registry. Should provide some minor performance improvement.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 5 months
[JBoss JIRA] (ISPN-5927) Infinispan calling setRollbackOnly() when detecting write skew
by Dennis Reed (JIRA)
[ https://issues.jboss.org/browse/ISPN-5927?page=com.atlassian.jira.plugin.... ]
Dennis Reed commented on ISPN-5927:
-----------------------------------
This error does not appear to cause functional issues outside of the incorrect logging (the exception happens to get thrown from the same method the real exception would have been thrown from immediately after the setRollbackOnly call, so it just triggers an incorrect CausedBy to be logged).
> Infinispan calling setRollbackOnly() when detecting write skew
> --------------------------------------------------------------
>
> Key: ISPN-5927
> URL: https://issues.jboss.org/browse/ISPN-5927
> Project: Infinispan
> Issue Type: Bug
> Components: Core
> Affects Versions: 6.0.2.Final
> Reporter: Stephen Fikes
> Attachments: testcase.zip
>
>
> In the context of Java Data Grid, when Infinispan detects [#write-skew] during prepare, it invokes [#setRollbackOnly]() on the transaction implementation. This results in an exception ({{com.arjuna.ats.jta.exceptions.InvalidTerminationStateException: ARJUNA016064: The transaction is in an invalid state!}}) because this operation is disallowed by Arjuna while in the {{PREPARING}} state. The result is that the causal error ({{org.infinispan.transaction.WriteSkewException}}) is lost and the error that propagates indicates that "invalid state" (of the transaction) is actually the cause of the failed commit. Only when debug logging was enabled could we see the root cause.
> h3. {anchor:write-skew}Write skew exception
> ... org.infinispan.transaction.WriteSkewException: Write skew detected on key <key> for transaction TransactionImple < ... status: ActionStatus.PREPARING >
> at org.infinispan.transaction.WriteSkewHelper.performWriteSkewCheckAndReturnNewVersions(WriteSkewHelper.java:53)
> ...
> at org.infinispan.transaction.TransactionCoordinator.prepare(TransactionCoordinator.java:104)
> at org.infinispan.transaction.xa.TransactionXaAdapter.prepare(TransactionXaAdapter.java:92)
> at com.arjuna.ats.internal.jta.resources.arjunacore.XAResourceRecord.topLevelPrepare(XAResourceRecord.java:213)
> ...
> h3. {anchor:setRollbackOnly}Set Rollback
> at com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionImple.setRollbackOnly(TransactionImple.java:313)
> at org.infinispan.interceptors.InvocationContextInterceptor.markTxForRollbackAndRethrow(InvocationContextInterceptor.java:163)
> ...
> at org.infinispan.commands.AbstractVisitor.visitPrepareCommand(AbstractVisitor.java:103)
> ...
> at org.infinispan.transaction.xa.TransactionXaAdapter.prepare(TransactionXaAdapter.java:92)
> at com.arjuna.ats.internal.jta.resources.arjunacore.XAResourceRecord.topLevelPrepare(XAResourceRecord.java:213)
> ...
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 5 months
[JBoss JIRA] (ISPN-5927) Infinispan calling setRollbackOnly() when detecting write skew
by Dennis Reed (JIRA)
[ https://issues.jboss.org/browse/ISPN-5927?page=com.atlassian.jira.plugin.... ]
Dennis Reed updated ISPN-5927:
------------------------------
> Infinispan calling setRollbackOnly() when detecting write skew
> --------------------------------------------------------------
>
> Key: ISPN-5927
> URL: https://issues.jboss.org/browse/ISPN-5927
> Project: Infinispan
> Issue Type: Bug
> Components: Core
> Affects Versions: 6.0.2.Final
> Reporter: Stephen Fikes
> Attachments: testcase.zip
>
>
> In the context of Java Data Grid, when Infinispan detects [#write-skew] during prepare, it invokes [#setRollbackOnly]() on the transaction implementation. This results in an exception ({{com.arjuna.ats.jta.exceptions.InvalidTerminationStateException: ARJUNA016064: The transaction is in an invalid state!}}) because this operation is disallowed by Arjuna while in the {{PREPARING}} state. The result is that the causal error ({{org.infinispan.transaction.WriteSkewException}}) is lost and the error that propagates indicates that "invalid state" (of the transaction) is actually the cause of the failed commit. Only when debug logging was enabled could we see the root cause.
> h3. {anchor:write-skew}Write skew exception
> ... org.infinispan.transaction.WriteSkewException: Write skew detected on key <key> for transaction TransactionImple < ... status: ActionStatus.PREPARING >
> at org.infinispan.transaction.WriteSkewHelper.performWriteSkewCheckAndReturnNewVersions(WriteSkewHelper.java:53)
> ...
> at org.infinispan.transaction.TransactionCoordinator.prepare(TransactionCoordinator.java:104)
> at org.infinispan.transaction.xa.TransactionXaAdapter.prepare(TransactionXaAdapter.java:92)
> at com.arjuna.ats.internal.jta.resources.arjunacore.XAResourceRecord.topLevelPrepare(XAResourceRecord.java:213)
> ...
> h3. {anchor:setRollbackOnly}Set Rollback
> at com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionImple.setRollbackOnly(TransactionImple.java:313)
> at org.infinispan.interceptors.InvocationContextInterceptor.markTxForRollbackAndRethrow(InvocationContextInterceptor.java:163)
> ...
> at org.infinispan.commands.AbstractVisitor.visitPrepareCommand(AbstractVisitor.java:103)
> ...
> at org.infinispan.transaction.xa.TransactionXaAdapter.prepare(TransactionXaAdapter.java:92)
> at com.arjuna.ats.internal.jta.resources.arjunacore.XAResourceRecord.topLevelPrepare(XAResourceRecord.java:213)
> ...
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 5 months
[JBoss JIRA] (ISPN-5897) Enhance filter_failed_tests.sh to support compressed logs
by Tristan Tarrant (JIRA)
[ https://issues.jboss.org/browse/ISPN-5897?page=com.atlassian.jira.plugin.... ]
Tristan Tarrant updated ISPN-5897:
----------------------------------
Status: Resolved (was: Pull Request Sent)
Fix Version/s: 8.1.0.Final
Resolution: Done
> Enhance filter_failed_tests.sh to support compressed logs
> ---------------------------------------------------------
>
> Key: ISPN-5897
> URL: https://issues.jboss.org/browse/ISPN-5897
> Project: Infinispan
> Issue Type: Task
> Components: Build process
> Affects Versions: 8.1.0.Alpha2
> Reporter: Dan Berindei
> Assignee: Dan Berindei
> Fix For: 8.1.0.Beta1, 8.1.0.Final
>
>
> Currently the trace build uses a lot of disk space. Using `CompressedFileAppender` should reduce the size of the logs considerably, but we still want to save only the logs of the failed tests in the build artifacts.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 5 months
[JBoss JIRA] (ISPN-5917) Transactions rolled back early are never removed from the transaction table
by William Burns (JIRA)
[ https://issues.jboss.org/browse/ISPN-5917?page=com.atlassian.jira.plugin.... ]
William Burns updated ISPN-5917:
--------------------------------
Status: Resolved (was: Pull Request Sent)
Resolution: Done
> Transactions rolled back early are never removed from the transaction table
> ---------------------------------------------------------------------------
>
> Key: ISPN-5917
> URL: https://issues.jboss.org/browse/ISPN-5917
> Project: Infinispan
> Issue Type: Bug
> Components: Core
> Affects Versions: 8.0.1.Final, 8.1.0.Alpha2
> Reporter: Dan Berindei
> Assignee: Dan Berindei
> Fix For: 8.1.0.Beta1, 8.1.0.Final
>
>
> When a transaction is rolled back before the first cache operation, the transaction is registered in the TransactionTable and is never removed. That happens because {{TxInterceptor}} sees the transaction is marked for rollback and immediately throws an exception.
> This can be seen in {{MarkAsRollbackTest}}, which blocks for 30 seconds during teardown because there's still a transaction in the transaction table.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 5 months
[JBoss JIRA] (ISPN-5918) Remote transactions can be registered after cache stop and block shutdown
by William Burns (JIRA)
[ https://issues.jboss.org/browse/ISPN-5918?page=com.atlassian.jira.plugin.... ]
William Burns updated ISPN-5918:
--------------------------------
Status: Resolved (was: Pull Request Sent)
Resolution: Done
> Remote transactions can be registered after cache stop and block shutdown
> -------------------------------------------------------------------------
>
> Key: ISPN-5918
> URL: https://issues.jboss.org/browse/ISPN-5918
> Project: Infinispan
> Issue Type: Bug
> Components: Core
> Affects Versions: 8.0.1.Final, 8.1.0.Alpha2
> Reporter: Dan Berindei
> Assignee: Dan Berindei
> Fix For: 8.1.0.Beta1, 8.1.0.Final
>
>
> The cache status check is done in {{InvocationContextInterceptor}}, but by that time the remote transaction was already registered, and there is nothing to remove it from the transaction table.
> This can be seen in {{TerminatedCacheWhileInTxTest}}, which logs ""Wait very briefly and then make call." and then proceeds to wait for 30s (i.e. until the cache shutdown timeout expires).
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 5 months