November 2018 - infinispan-issues

[JBoss JIRA] (ISPN-9519) Upgrade JGroups to 4.0.14.Final

by Paul Ferraro (Jira)

[ https://issues.jboss.org/browse/ISPN-9519?page=com.atlassian.jira.plugin.... ] Paul Ferraro updated ISPN-9519: ------------------------------- Status: Open (was: Pull Request Sent) Git Pull Request: (was: https://github.com/infinispan/infinispan/pull/6257) > Upgrade JGroups to 4.0.14.Final > ------------------------------- > > Key: ISPN-9519 > URL: https://issues.jboss.org/browse/ISPN-9519 > Project: Infinispan > Issue Type: Component Upgrade > Components: Core > Affects Versions: 9.4.0.CR3, 9.3.3.Final > Reporter: Paul Ferraro > Assignee: Paul Ferraro > Priority: Major > -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 4 months

1
0
0 / 0

[JBoss JIRA] (ISPN-9519) Upgrade JGroups to 4.0.14.Final

by Paul Ferraro (Jira)

[ https://issues.jboss.org/browse/ISPN-9519?page=com.atlassian.jira.plugin.... ] Paul Ferraro closed ISPN-9519. ------------------------------ Resolution: Out of Date > Upgrade JGroups to 4.0.14.Final > ------------------------------- > > Key: ISPN-9519 > URL: https://issues.jboss.org/browse/ISPN-9519 > Project: Infinispan > Issue Type: Component Upgrade > Components: Core > Affects Versions: 9.4.0.CR3, 9.3.3.Final > Reporter: Paul Ferraro > Assignee: Paul Ferraro > Priority: Major > -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 4 months

1
0
0 / 0

[JBoss JIRA] (ISPN-9773) Disabling a store puts persistence manager in invalid state if there is another store

by William Burns (Jira)

[ https://issues.jboss.org/browse/ISPN-9773?page=com.atlassian.jira.plugin.... ] William Burns updated ISPN-9773: -------------------------------- Status: Open (was: New) > Disabling a store puts persistence manager in invalid state if there is another store > ------------------------------------------------------------------------------------- > > Key: ISPN-9773 > URL: https://issues.jboss.org/browse/ISPN-9773 > Project: Infinispan > Issue Type: Bug > Components: Loaders and Stores > Reporter: William Burns > Assignee: William Burns > Priority: Major > Fix For: 9.3.6.Final, 10.0.0.Alpha2, 9.4.3.Final > > > When we disable a store, we accidentally remove all of the storeStatuses. This can cause an issue if there is another store configured besides the one that was just disabled. > The problem is that this line is always invoked https://github.com/infinispan/infinispan/blob/master/core/src/main/java/o... We need to optionally invoke it if the store matches the type. -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 4 months

1
0
0 / 0

[JBoss JIRA] (ISPN-9773) Disabling a store puts persistence manager in invalid state if there is another store

by William Burns (Jira)

[ https://issues.jboss.org/browse/ISPN-9773?page=com.atlassian.jira.plugin.... ] William Burns updated ISPN-9773: -------------------------------- Status: Pull Request Sent (was: Open) Git Pull Request: https://github.com/infinispan/infinispan/pull/6471 > Disabling a store puts persistence manager in invalid state if there is another store > ------------------------------------------------------------------------------------- > > Key: ISPN-9773 > URL: https://issues.jboss.org/browse/ISPN-9773 > Project: Infinispan > Issue Type: Bug > Components: Loaders and Stores > Reporter: William Burns > Assignee: William Burns > Priority: Major > Fix For: 9.3.6.Final, 10.0.0.Alpha2, 9.4.3.Final > > > When we disable a store, we accidentally remove all of the storeStatuses. This can cause an issue if there is another store configured besides the one that was just disabled. > The problem is that this line is always invoked https://github.com/infinispan/infinispan/blob/master/core/src/main/java/o... We need to optionally invoke it if the store matches the type. -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 4 months

1
0
0 / 0

[JBoss JIRA] (ISPN-8381) OffHeap doesn't work with passivation

by Diego Lovison (Jira)

[ https://issues.jboss.org/browse/ISPN-8381?page=com.atlassian.jira.plugin.... ] Diego Lovison closed ISPN-8381. ------------------------------- > OffHeap doesn't work with passivation > ------------------------------------- > > Key: ISPN-8381 > URL: https://issues.jboss.org/browse/ISPN-8381 > Project: Infinispan > Issue Type: Bug > Components: Off Heap > Affects Versions: 9.1.1.Final > Reporter: William Burns > Assignee: William Burns > Priority: Major > Labels: on-hold > Fix For: 9.4.0.CR3, 9.4.0.Final > > > Off Heap currently doesn't have an ActivationManager which is required to be invoked when entries are accessed. -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 4 months

1
0
0 / 0

[JBoss JIRA] (ISPN-9352) Report cache read/write/remote stats also as nanoseconds

by Diego Lovison (Jira)

[ https://issues.jboss.org/browse/ISPN-9352?page=com.atlassian.jira.plugin.... ] Diego Lovison closed ISPN-9352. ------------------------------- > Report cache read/write/remote stats also as nanoseconds > -------------------------------------------------------- > > Key: ISPN-9352 > URL: https://issues.jboss.org/browse/ISPN-9352 > Project: Infinispan > Issue Type: Feature Request > Components: JMX, reporting and management > Affects Versions: 9.3.0.Final > Reporter: Tristan Tarrant > Assignee: Tristan Tarrant > Priority: Major > Labels: on-hold > Fix For: 9.4.0.Alpha1, 9.4.0.CR3 > > > Add three new stats that report read/write/remove averages in nanoseconds. -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 4 months

1
0
0 / 0

[JBoss JIRA] (ISPN-9500) ConcurrentSmallIntSet.clear() does not always set the size to 0

by Diego Lovison (Jira)

[ https://issues.jboss.org/browse/ISPN-9500?page=com.atlassian.jira.plugin.... ] Diego Lovison updated ISPN-9500: -------------------------------- Labels: (was: on-hold) > ConcurrentSmallIntSet.clear() does not always set the size to 0 > --------------------------------------------------------------- > > Key: ISPN-9500 > URL: https://issues.jboss.org/browse/ISPN-9500 > Project: Infinispan > Issue Type: Bug > Components: Core > Affects Versions: 9.4.0.CR1 > Reporter: Dan Berindei > Assignee: Dan Berindei > Priority: Major > Fix For: 9.4.0.CR3, 9.3.4.Final > > > {{ConcurrentSmallIntSet.clear()}} processes the array values with a loop that stops when {{value <= 0}}. This breaks when the highest bit is set, leaving the set empty but with {{size() > 0}} and {{isEmpty() == false}}. -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 4 months

1
0
0 / 0

[JBoss JIRA] (ISPN-9500) ConcurrentSmallIntSet.clear() does not always set the size to 0

by Diego Lovison (Jira)

[ https://issues.jboss.org/browse/ISPN-9500?page=com.atlassian.jira.plugin.... ] Diego Lovison closed ISPN-9500. ------------------------------- > ConcurrentSmallIntSet.clear() does not always set the size to 0 > --------------------------------------------------------------- > > Key: ISPN-9500 > URL: https://issues.jboss.org/browse/ISPN-9500 > Project: Infinispan > Issue Type: Bug > Components: Core > Affects Versions: 9.4.0.CR1 > Reporter: Dan Berindei > Assignee: Dan Berindei > Priority: Major > Fix For: 9.4.0.CR3, 9.3.4.Final > > > {{ConcurrentSmallIntSet.clear()}} processes the array values with a loop that stops when {{value <= 0}}. This breaks when the highest bit is set, leaving the set empty but with {{size() > 0}} and {{isEmpty() == false}}. -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 4 months

1
0
0 / 0

[JBoss JIRA] (ISPN-9500) ConcurrentSmallIntSet.clear() does not always set the size to 0

by Diego Lovison (Jira)

[ https://issues.jboss.org/browse/ISPN-9500?page=com.atlassian.jira.plugin.... ] Diego Lovison updated ISPN-9500: -------------------------------- Tester: Diego Lovison > ConcurrentSmallIntSet.clear() does not always set the size to 0 > --------------------------------------------------------------- > > Key: ISPN-9500 > URL: https://issues.jboss.org/browse/ISPN-9500 > Project: Infinispan > Issue Type: Bug > Components: Core > Affects Versions: 9.4.0.CR1 > Reporter: Dan Berindei > Assignee: Dan Berindei > Priority: Major > Labels: on-hold > Fix For: 9.4.0.CR3, 9.3.4.Final > > > {{ConcurrentSmallIntSet.clear()}} processes the array values with a loop that stops when {{value <= 0}}. This breaks when the highest bit is set, leaving the set empty but with {{size() > 0}} and {{isEmpty() == false}}. -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 4 months

1
0
0 / 0

[JBoss JIRA] (ISPN-9701) TransactionTable does not shutdown gracefully

by Dan Berindei (Jira)

[ https://issues.jboss.org/browse/ISPN-9701?page=com.atlassian.jira.plugin.... ] Dan Berindei commented on ISPN-9701: ------------------------------------ I haven't yet integrated the backport to 9.3.x because of a test failure: {noformat} java.lang.AssertionError at org.infinispan.lock.singlelock.AbstractInitiatorCrashTest.testInitiatorCrashesBeforeReleasingLock(AbstractInitiatorCrashTest.java:33) {noformat} I think it's an issue with the test though, it assumes that the local tx info is removed before the {{TxCompletionNotificationCommand}} is sent. > TransactionTable does not shutdown gracefully > --------------------------------------------- > > Key: ISPN-9701 > URL: https://issues.jboss.org/browse/ISPN-9701 > Project: Infinispan > Issue Type: Bug > Components: Transactions > Affects Versions: 9.2.4.Final, 9.3.5.Final, 9.4.1.Final > Reporter: Paul Ferraro > Assignee: Paul Ferraro > Priority: Critical > Fix For: 10.0.0.Alpha2, 9.4.3.Final > > > Here's a sample stacktrace during shutdown: > {noformat} > 16:54:15,033 WARN [org.wildfly.clustering.web.undertow] (default task-1) ISPN000472: Cache manager is stopping: org.infinispan.IllegalLifecycleStateException: ISPN000472: Cache manager is stopping > at org.infinispan.marshall.core.GlobalMarshaller.getExternalizer(GlobalMarshaller.java:420) > at org.infinispan.marshall.core.GlobalMarshaller.writeNonNullableObject(GlobalMarshaller.java:400) > at org.infinispan.marshall.core.GlobalMarshaller.writeNullableObject(GlobalMarshaller.java:355) > at org.infinispan.marshall.core.GlobalMarshaller.writeObjectOutput(GlobalMarshaller.java:183) > at org.infinispan.marshall.core.GlobalMarshaller.writeObjectOutput(GlobalMarshaller.java:176) > at org.infinispan.marshall.core.GlobalMarshaller.objectToBuffer(GlobalMarshaller.java:305) > at org.infinispan.remoting.transport.jgroups.JGroupsTransport.marshallRequest(JGroupsTransport.java:1009) > at org.infinispan.remoting.transport.jgroups.JGroupsTransport.sendCommand(JGroupsTransport.java:1209) > at org.infinispan.remoting.transport.jgroups.JGroupsTransport.performAsyncRemoteInvocation(JGroupsTransport.java:1105) > at org.infinispan.remoting.transport.jgroups.JGroupsTransport.invokeRemotelyAsync(JGroupsTransport.java:246) > at org.infinispan.remoting.rpc.RpcManagerImpl.invokeRemotelyAsync(RpcManagerImpl.java:291) > at org.infinispan.remoting.rpc.RpcManagerImpl.invokeRemotely(RpcManagerImpl.java:323) > at org.infinispan.transaction.impl.TransactionTable.removeTransactionInfoRemotely(TransactionTable.java:900) > at org.infinispan.transaction.impl.TransactionTable.releaseLocksForCompletedTransaction(TransactionTable.java:886) > at org.infinispan.transaction.xa.XaTransactionTable.forgetSuccessfullyCompletedTransaction(XaTransactionTable.java:195) > at org.infinispan.transaction.xa.XaTransactionTable.commit(XaTransactionTable.java:128) > at org.infinispan.transaction.xa.TransactionXaAdapter.commit(TransactionXaAdapter.java:68) > at org.infinispan.commons.tx.TransactionImpl.finishResource(TransactionImpl.java:419) > at org.infinispan.commons.tx.TransactionImpl.commitResources(TransactionImpl.java:466) > at org.infinispan.commons.tx.TransactionImpl.runCommit(TransactionImpl.java:335) > at org.infinispan.commons.tx.TransactionImpl.commit(TransactionImpl.java:110) > {noformat} > The problem seems to be that shutDownGracefully() first waits for the localTransactions map to be empty. However, when the cache is clustered, releaseLocksForCompletedTransaction(...) removes the transaction from the localTransactions map *before* invoking removeTransactionInfoRemotely(...), which means that the subsequent TxCompletionNotificationCommand can fail to marshal (see above), or the transport might close before this command is sent. > A naive fix would simply reorder the removeLocalTransaction(...) to happen after the call to removeTransactionInfoRemotely(...) within the releaseLocksForCompletedTransaction(...) method, but I'm sure there's more to it. -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 4 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 November 2018