[JBoss JIRA] (ISPN-9667) DefaultCacheManager inconsistent status checks
by Dan Berindei (Jira)
[ https://issues.jboss.org/browse/ISPN-9667?page=com.atlassian.jira.plugin.... ]
Dan Berindei updated ISPN-9667:
-------------------------------
Description:
{{DefaultCacheManager.getTransport()}} returns {{null}} when the manager is stopping, it should not.
To make things worse, {{DefaultCacheManager.getStatus()}} returns the status of the {{GlobalComponentRegistry}}, which is still {{RUNNING}} while caches are shutting down.
was:{{DefaultCacheManager.getTransport()}} returns {{null}} when the manager is stopping, it should not. To make things worse, {{DefaultCacheManager.getStatus()}} returns the status of the {{GlobalComponentRegistry}}, which is still {{RUNNING}} while caches are shutting down.
> DefaultCacheManager inconsistent status checks
> ----------------------------------------------
>
> Key: ISPN-9667
> URL: https://issues.jboss.org/browse/ISPN-9667
> Project: Infinispan
> Issue Type: Bug
> Components: Core
> Affects Versions: 9.4.1.Final
> Reporter: Dan Berindei
> Assignee: Dan Berindei
> Priority: Major
> Fix For: 10.0.0.Alpha1, 9.4.2.Final
>
>
> {{DefaultCacheManager.getTransport()}} returns {{null}} when the manager is stopping, it should not.
> To make things worse, {{DefaultCacheManager.getStatus()}} returns the status of the {{GlobalComponentRegistry}}, which is still {{RUNNING}} while caches are shutting down.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
6 years, 1 month
[JBoss JIRA] (ISPN-9667) DefaultCacheManager inconsistent status checks
by Dan Berindei (Jira)
Dan Berindei created ISPN-9667:
----------------------------------
Summary: DefaultCacheManager inconsistent status checks
Key: ISPN-9667
URL: https://issues.jboss.org/browse/ISPN-9667
Project: Infinispan
Issue Type: Bug
Components: Core
Affects Versions: 9.4.1.Final
Reporter: Dan Berindei
Assignee: Dan Berindei
Fix For: 10.0.0.Alpha1, 9.4.2.Final
{{DefaultCacheManager.getTransport()}} returns {{null}} when the manager is stopping, it should not. To make things worse, {{DefaultCacheManager.getStatus()}} returns the status of the {{GlobalComponentRegistry}}, which is still {{RUNNING}} while caches are shutting down.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
6 years, 1 month
[JBoss JIRA] (ISPN-9514) Entry replaced with same expiration can expire immediately
by Gustavo Lira (Jira)
[ https://issues.jboss.org/browse/ISPN-9514?page=com.atlassian.jira.plugin.... ]
Gustavo Lira closed ISPN-9514.
------------------------------
> Entry replaced with same expiration can expire immediately
> ----------------------------------------------------------
>
> Key: ISPN-9514
> URL: https://issues.jboss.org/browse/ISPN-9514
> Project: Infinispan
> Issue Type: Bug
> Components: Expiration
> Affects Versions: 9.3.3.Final
> Reporter: William Burns
> Assignee: William Burns
> Priority: Major
> Fix For: 9.4.0.Final
>
>
> Currently lifespan expiration removes an expired entry based on the key value and lifespan parameter matching. Unfortunately this still leaves it open to removing an entry that was just inserted if it was expired and it was replaced with the same value.
> This is especially problematic with `RemoteCache.putIfAbsent` or other conditional operations as they perform a get before doing the actual operation.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
6 years, 1 month
[JBoss JIRA] (ISPN-9517) State transfer times out if initiated with yet to be verified suspected member and reincarnated member
by Gustavo Lira (Jira)
[ https://issues.jboss.org/browse/ISPN-9517?page=com.atlassian.jira.plugin.... ]
Gustavo Lira commented on ISPN-9517:
------------------------------------
[~pferraro] I couldn't reproduce this behaviour. I tried with your reproducer.
I'm attaching my log [^log.rtf]
> State transfer times out if initiated with yet to be verified suspected member and reincarnated member
> ------------------------------------------------------------------------------------------------------
>
> Key: ISPN-9517
> URL: https://issues.jboss.org/browse/ISPN-9517
> Project: Infinispan
> Issue Type: Bug
> Components: State Transfer
> Affects Versions: 9.3.3.Final
> Reporter: Paul Ferraro
> Assignee: Dan Berindei
> Priority: Major
> Fix For: 9.4.0.Final
>
> Attachments: Test.java, log.rtf, node-1.zip, node-2.zip
>
>
> Here's the scenario:
> 1. Cluster contains caches on 2 members, node-1 and node-2
> 2. node-2 is killed
> 3. node-2 is restarted (using same physical address)
> 4. State transfer initiates, view contains node-1, suspected node-2, and reincarnated node-2
> 5. State transfer times out
> Log of node-1 includes:
> {noformat}
> 12:09:51,882 WARN [org.infinispan.topology.ClusterTopologyManagerImpl] (transport-thread--p14-t4) ISPN000197: Error updating cluster member list: org.infinispan.util.concurrent.TimeoutException: ISPN000476: Timed out waiting for responses for request 3 from node-2
> at org.infinispan.remoting.transport.impl.MultiTargetRequest.onTimeout(MultiTargetRequest.java:167)
> at org.infinispan.remoting.transport.AbstractRequest.call(AbstractRequest.java:87)
> at org.infinispan.remoting.transport.AbstractRequest.call(AbstractRequest.java:22)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266) [rt.jar:1.8.0_181]
> at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:180) [rt.jar:1.8.0_181]
> at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293) [rt.jar:1.8.0_181]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) [rt.jar:1.8.0_181]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) [rt.jar:1.8.0_181]
> at java.lang.Thread.run(Thread.java:748) [rt.jar:1.8.0_181]
> Suppressed: org.infinispan.util.logging.TraceException
> at org.infinispan.remoting.transport.Transport.invokeRemotely(Transport.java:75)
> at org.infinispan.topology.ClusterTopologyManagerImpl.confirmMembersAvailable(ClusterTopologyManagerImpl.java:525)
> at org.infinispan.topology.ClusterTopologyManagerImpl.updateCacheMembers(ClusterTopologyManagerImpl.java:508)
> at org.infinispan.topology.ClusterTopologyManagerImpl.handleClusterView(ClusterTopologyManagerImpl.java:321)
> at org.infinispan.topology.ClusterTopologyManagerImpl.access$500(ClusterTopologyManagerImpl.java:87)
> at org.infinispan.topology.ClusterTopologyManagerImpl$ClusterViewListener.lambda$handleViewChange$0(ClusterTopologyManagerImpl.java:731)
> at org.infinispan.executors.LimitedExecutor.runTasks(LimitedExecutor.java:175)
> at org.infinispan.executors.LimitedExecutor.access$100(LimitedExecutor.java:37)
> at org.infinispan.executors.LimitedExecutor$Runner.run(LimitedExecutor.java:227)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) [rt.jar:1.8.0_181]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) [rt.jar:1.8.0_181]
> at org.wildfly.clustering.service.concurrent.ClassLoaderThreadFactory.lambda$newThread$0(ClassLoaderThreadFactory.java:47)
> ... 1 more
> {noformat}
> I've attached trace logs from node-1 and node-2.
> Changing ClusterTopologyManagerImpl.confirmMembersAvailable() to use ResponseMode.SYNCHRONOUS_IGNORE_LEAVERS instead of ResponseMode.SYNCHRONOUS allows state transfer to complete successfully.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
6 years, 1 month
[JBoss JIRA] (ISPN-9517) State transfer times out if initiated with yet to be verified suspected member and reincarnated member
by Gustavo Lira (Jira)
[ https://issues.jboss.org/browse/ISPN-9517?page=com.atlassian.jira.plugin.... ]
Gustavo Lira updated ISPN-9517:
-------------------------------
Attachment: log.rtf
> State transfer times out if initiated with yet to be verified suspected member and reincarnated member
> ------------------------------------------------------------------------------------------------------
>
> Key: ISPN-9517
> URL: https://issues.jboss.org/browse/ISPN-9517
> Project: Infinispan
> Issue Type: Bug
> Components: State Transfer
> Affects Versions: 9.3.3.Final
> Reporter: Paul Ferraro
> Assignee: Dan Berindei
> Priority: Major
> Fix For: 9.4.0.Final
>
> Attachments: Test.java, log.rtf, node-1.zip, node-2.zip
>
>
> Here's the scenario:
> 1. Cluster contains caches on 2 members, node-1 and node-2
> 2. node-2 is killed
> 3. node-2 is restarted (using same physical address)
> 4. State transfer initiates, view contains node-1, suspected node-2, and reincarnated node-2
> 5. State transfer times out
> Log of node-1 includes:
> {noformat}
> 12:09:51,882 WARN [org.infinispan.topology.ClusterTopologyManagerImpl] (transport-thread--p14-t4) ISPN000197: Error updating cluster member list: org.infinispan.util.concurrent.TimeoutException: ISPN000476: Timed out waiting for responses for request 3 from node-2
> at org.infinispan.remoting.transport.impl.MultiTargetRequest.onTimeout(MultiTargetRequest.java:167)
> at org.infinispan.remoting.transport.AbstractRequest.call(AbstractRequest.java:87)
> at org.infinispan.remoting.transport.AbstractRequest.call(AbstractRequest.java:22)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266) [rt.jar:1.8.0_181]
> at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:180) [rt.jar:1.8.0_181]
> at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293) [rt.jar:1.8.0_181]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) [rt.jar:1.8.0_181]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) [rt.jar:1.8.0_181]
> at java.lang.Thread.run(Thread.java:748) [rt.jar:1.8.0_181]
> Suppressed: org.infinispan.util.logging.TraceException
> at org.infinispan.remoting.transport.Transport.invokeRemotely(Transport.java:75)
> at org.infinispan.topology.ClusterTopologyManagerImpl.confirmMembersAvailable(ClusterTopologyManagerImpl.java:525)
> at org.infinispan.topology.ClusterTopologyManagerImpl.updateCacheMembers(ClusterTopologyManagerImpl.java:508)
> at org.infinispan.topology.ClusterTopologyManagerImpl.handleClusterView(ClusterTopologyManagerImpl.java:321)
> at org.infinispan.topology.ClusterTopologyManagerImpl.access$500(ClusterTopologyManagerImpl.java:87)
> at org.infinispan.topology.ClusterTopologyManagerImpl$ClusterViewListener.lambda$handleViewChange$0(ClusterTopologyManagerImpl.java:731)
> at org.infinispan.executors.LimitedExecutor.runTasks(LimitedExecutor.java:175)
> at org.infinispan.executors.LimitedExecutor.access$100(LimitedExecutor.java:37)
> at org.infinispan.executors.LimitedExecutor$Runner.run(LimitedExecutor.java:227)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) [rt.jar:1.8.0_181]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) [rt.jar:1.8.0_181]
> at org.wildfly.clustering.service.concurrent.ClassLoaderThreadFactory.lambda$newThread$0(ClassLoaderThreadFactory.java:47)
> ... 1 more
> {noformat}
> I've attached trace logs from node-1 and node-2.
> Changing ClusterTopologyManagerImpl.confirmMembersAvailable() to use ResponseMode.SYNCHRONOUS_IGNORE_LEAVERS instead of ResponseMode.SYNCHRONOUS allows state transfer to complete successfully.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
6 years, 1 month
[JBoss JIRA] (ISPN-9054) Upgrade to Aesh 1.0
by Ryan Emerson (Jira)
[ https://issues.jboss.org/browse/ISPN-9054?page=com.atlassian.jira.plugin.... ]
Ryan Emerson reassigned ISPN-9054:
----------------------------------
Assignee: (was: Ryan Emerson)
> Upgrade to Aesh 1.0
> -------------------
>
> Key: ISPN-9054
> URL: https://issues.jboss.org/browse/ISPN-9054
> Project: Infinispan
> Issue Type: Component Upgrade
> Components: CLI
> Reporter: Ryan Emerson
> Priority: Major
> Fix For: 9.4.2.Final
>
>
> Aesh 1.0 has been released, and is currently used by Wildfly 12.x. 1.0 has several differences to Aesh 0.66.x, most notably the introduction of the aesh-readline project and the removal of AeshConsoleCallback. The upgrade is non-trivial, however due to some of the new features provided by Aesh 1.x, it could greatly reduce the amount of code required.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
6 years, 1 month
[JBoss JIRA] (ISPN-8375) Allow additional HikariCP properties to be passed via PooledConnectionFactoryConfiguration
by Ryan Emerson (Jira)
[ https://issues.jboss.org/browse/ISPN-8375?page=com.atlassian.jira.plugin.... ]
Ryan Emerson closed ISPN-8375.
------------------------------
Resolution: Out of Date
> Allow additional HikariCP properties to be passed via PooledConnectionFactoryConfiguration
> ------------------------------------------------------------------------------------------
>
> Key: ISPN-8375
> URL: https://issues.jboss.org/browse/ISPN-8375
> Project: Infinispan
> Issue Type: Enhancement
> Components: Loaders and Stores
> Affects Versions: 9.1.1.Final
> Reporter: Ryan Emerson
> Assignee: Ryan Emerson
> Priority: Major
> Fix For: 9.4.2.Final
>
>
> Currently the only way to provide additional HikariCP configuration is via a `hikari.properties` file. We should allow users to enter these properties via our xml/config builders.
> This will also benefit the new datagrid-infinispan-datasources subsystem, as it will allow users to continue to utilise many of the additional tuning options that we have inherited from the wildfly-connector subsystem.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
6 years, 1 month