[JBoss JIRA] (ISPN-7035) Support Spring 5
by Katia Aresti (Jira)
[ https://issues.jboss.org/browse/ISPN-7035?page=com.atlassian.jira.plugin.... ]
Katia Aresti reopened ISPN-7035:
--------------------------------
backport
> Support Spring 5
> ----------------
>
> Key: ISPN-7035
> URL: https://issues.jboss.org/browse/ISPN-7035
> Project: Infinispan
> Issue Type: Enhancement
> Reporter: Sebastian Łaskawiec
> Assignee: Katia Aresti
> Priority: Critical
> Fix For: 10.0.0.Alpha2, 10.0.0.Final
>
>
> Currently everything is placed in {{org.infinispan.spring}} package. We should provide exactly the same split as we did in CDI ({{org.infinispan.spring}} into {{org.infinispan.spring.remote}} and {{org.infinispan.spring.embedded}})
> Move to Spring 5.1.x.RELEASE, Spring Session 2.x and Spring-Boot 2.x
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 4 months
[JBoss JIRA] (ISPN-9720) JDK11: An illegal reflective access operation has occurred
by William Burns (Jira)
[ https://issues.jboss.org/browse/ISPN-9720?page=com.atlassian.jira.plugin.... ]
William Burns updated ISPN-9720:
--------------------------------
Fix Version/s: 10.0.0.Alpha2
9.3.6.Final
9.4.4.Final
> JDK11: An illegal reflective access operation has occurred
> ----------------------------------------------------------
>
> Key: ISPN-9720
> URL: https://issues.jboss.org/browse/ISPN-9720
> Project: Infinispan
> Issue Type: Bug
> Components: Core
> Affects Versions: 9.4.1.Final
> Reporter: Tomas Hofman
> Assignee: Tomas Hofman
> Priority: Critical
> Labels: Java11
> Fix For: 10.0.0.Alpha2, 9.3.6.Final, 9.4.4.Final
>
>
> server prints infinispan warnings during deploying the deployment or start server with deployment:
> {noformat}
> WARNING: An illegal reflective access operation has occurred
> WARNING: Illegal reflective access by org.infinispan.marshall.exts.SecurityActions (jar:file:/home/mkopecky/playground/eap/7.2.0.GA.CR1/jboss-eap-7.2/modules/system/layers/base/org/infinispan/main/infinispan-core-9.3.3.Final-redhat-00001.jar!/) to field java.util.DoubleSummaryStatistics.count
> WARNING: Please consider reporting this to the maintainers of org.infinispan.marshall.exts.SecurityActions
> WARNING: Use --illegal-access=warn to enable warnings of further illegal reflective access operations
> WARNING: All illegal access operations will be denied in a future release
> {noformat}
> This is follow up for JBEAP-15475, as [~jamezp] mentioned in [his comment|https://issues.jboss.org/browse/JBEAP-15475?focusedCommentId=1364...].
> cc: [~msvehla], [~rsvoboda]
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 4 months
[JBoss JIRA] (ISPN-9720) JDK11: An illegal reflective access operation has occurred
by William Burns (Jira)
[ https://issues.jboss.org/browse/ISPN-9720?page=com.atlassian.jira.plugin.... ]
William Burns resolved ISPN-9720.
---------------------------------
Resolution: Done
> JDK11: An illegal reflective access operation has occurred
> ----------------------------------------------------------
>
> Key: ISPN-9720
> URL: https://issues.jboss.org/browse/ISPN-9720
> Project: Infinispan
> Issue Type: Bug
> Components: Core
> Affects Versions: 9.4.1.Final
> Reporter: Tomas Hofman
> Assignee: Tomas Hofman
> Priority: Critical
> Labels: Java11
> Fix For: 10.0.0.Alpha2, 9.3.6.Final, 9.4.4.Final
>
>
> server prints infinispan warnings during deploying the deployment or start server with deployment:
> {noformat}
> WARNING: An illegal reflective access operation has occurred
> WARNING: Illegal reflective access by org.infinispan.marshall.exts.SecurityActions (jar:file:/home/mkopecky/playground/eap/7.2.0.GA.CR1/jboss-eap-7.2/modules/system/layers/base/org/infinispan/main/infinispan-core-9.3.3.Final-redhat-00001.jar!/) to field java.util.DoubleSummaryStatistics.count
> WARNING: Please consider reporting this to the maintainers of org.infinispan.marshall.exts.SecurityActions
> WARNING: Use --illegal-access=warn to enable warnings of further illegal reflective access operations
> WARNING: All illegal access operations will be denied in a future release
> {noformat}
> This is follow up for JBEAP-15475, as [~jamezp] mentioned in [his comment|https://issues.jboss.org/browse/JBEAP-15475?focusedCommentId=1364...].
> cc: [~msvehla], [~rsvoboda]
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 4 months
[JBoss JIRA] (ISPN-9720) JDK11: An illegal reflective access operation has occurred
by William Burns (Jira)
[ https://issues.jboss.org/browse/ISPN-9720?page=com.atlassian.jira.plugin.... ]
William Burns updated ISPN-9720:
--------------------------------
Status: Open (was: New)
> JDK11: An illegal reflective access operation has occurred
> ----------------------------------------------------------
>
> Key: ISPN-9720
> URL: https://issues.jboss.org/browse/ISPN-9720
> Project: Infinispan
> Issue Type: Bug
> Components: Core
> Affects Versions: 9.4.1.Final
> Reporter: Tomas Hofman
> Assignee: Tomas Hofman
> Priority: Critical
> Labels: Java11
>
> server prints infinispan warnings during deploying the deployment or start server with deployment:
> {noformat}
> WARNING: An illegal reflective access operation has occurred
> WARNING: Illegal reflective access by org.infinispan.marshall.exts.SecurityActions (jar:file:/home/mkopecky/playground/eap/7.2.0.GA.CR1/jboss-eap-7.2/modules/system/layers/base/org/infinispan/main/infinispan-core-9.3.3.Final-redhat-00001.jar!/) to field java.util.DoubleSummaryStatistics.count
> WARNING: Please consider reporting this to the maintainers of org.infinispan.marshall.exts.SecurityActions
> WARNING: Use --illegal-access=warn to enable warnings of further illegal reflective access operations
> WARNING: All illegal access operations will be denied in a future release
> {noformat}
> This is follow up for JBEAP-15475, as [~jamezp] mentioned in [his comment|https://issues.jboss.org/browse/JBEAP-15475?focusedCommentId=1364...].
> cc: [~msvehla], [~rsvoboda]
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 4 months
[JBoss JIRA] (ISPN-9802) Docs: Externalize dependency excerpts for productization
by Don Naro (Jira)
Don Naro created ISPN-9802:
------------------------------
Summary: Docs: Externalize dependency excerpts for productization
Key: ISPN-9802
URL: https://issues.jboss.org/browse/ISPN-9802
Project: Infinispan
Issue Type: Enhancement
Components: Documentation-Core
Affects Versions: 10.0.0.Alpha2, 9.4.4.Final
Reporter: Don Naro
Assignee: Don Naro
Externalize all the dependencies to a central location so we can productize them in the RHDG doc builds.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 4 months
[JBoss JIRA] (ISPN-9801) ClusterTopologyManagerImpl hangs when restarting a node with FORK
by Dan Berindei (Jira)
[ https://issues.jboss.org/browse/ISPN-9801?page=com.atlassian.jira.plugin.... ]
Dan Berindei updated ISPN-9801:
-------------------------------
Forum Reference: https://infinispan.zulipchat.com/#narrow/stream/118645-infinispan/subject...
> ClusterTopologyManagerImpl hangs when restarting a node with FORK
> -----------------------------------------------------------------
>
> Key: ISPN-9801
> URL: https://issues.jboss.org/browse/ISPN-9801
> Project: Infinispan
> Issue Type: Bug
> Components: Core
> Affects Versions: 10.0.0.Alpha1, 9.4.3.Final
> Reporter: Dan Berindei
> Assignee: Dan Berindei
> Priority: Major
> Fix For: 10.0.0.Alpha2, 9.4.4.Final
>
>
> When a server is restarted with `kill -9` or similar, both the old node and the new one can be in the JGroups view for a while. Normally this shouldn't be a problem, but sometimes the new node doesn't receive the {{HeartBeatCommand}} and the coordinator cannot process any new view updates.
> {noformat}
> 14:29:19,981 INFO (jgroups-12,Test-NodeA:[]) [CLUSTER] ISPN000094: Received new cluster view for channel FORKISPN: [Test-NodeA|4] (5) [Test-NodeA, Test-NodeB, Test-NodeC, Test-NodeD, Test-NodeE]
> 14:29:19,982 TRACE (transport-thread-Test-NodeA-p4-t14:[ViewHandling]) [ClusterTopologyManagerImpl] Updating cluster members for all the caches. New list is [Test-NodeA, Test-NodeB, Test-NodeC, Test-NodeD, Test-NodeE]
> 14:29:19,982 TRACE (transport-thread-Test-NodeA-p4-t14:[ViewHandling]) [JGroupsTransport] Test-NodeA sending request 9 to all: org.infinispan.topology.HeartBeatCommand@1163beb6
> 14:29:19,986 TRACE (jgroups-6,Test-NodeA:[]) [JGroupsTransport] Test-NodeA received response for request 9 from Test-NodeC: SuccessfulResponse(null)
> 14:29:19,987 TRACE (jgroups-9,Test-NodeA:[]) [JGroupsTransport] Test-NodeA received response for request 9 from Test-NodeD: SuccessfulResponse(null)
> 14:29:20,032 TRACE (jgroups-6,Test-NodeE:[]) [TCP_NIO2] Test-NodeE: received message batch of 1 messages from Test-NodeA
> 14:29:20,032 TRACE (jgroups-6,Test-NodeE:[]) [NAKACK2] Test-NodeE: message Test-NodeA::39 was added to queue (not yet server)
> 14:29:20,054 TRACE (jgroups-6,Test-NodeE:[]) [NAKACK2] Test-NodeE: received Test-NodeA#38
> 14:29:20,054 TRACE (jgroups-6,Test-NodeE:[]) [NAKACK2] Test-NodeE: delivering Test-NodeA#38
> # not actually delivered :)
> 14:29:20,054 TRACE (jgroups-6,Test-NodeE:[]) [MFC] Test-NodeA used 5 credits, 1999995 remaining
> 14:29:20,149 INFO (ForkThread-1,ForkChannelRestartTest:[]) [CLUSTER] ISPN000094: Received new cluster view for channel FORKISPN: [Test-NodeA|4] (5) [Test-NodeA, Test-NodeB, Test-NodeC, Test-NodeD, Test-NodeE]
> 14:29:21,119 DEBUG (testng-Test-1:[]) [ForkChannelRestartTest] Stopping channel Test-NodeB
> 14:29:23,319 INFO (VERIFY_SUSPECT.TimerThread-32,Test-NodeA:[]) [CLUSTER] ISPN000094: Received new cluster view for channel FORKISPN: [Test-NodeA|5] (4) [Test-NodeA, Test-NodeC, Test-NodeD, Test-NodeE]
> 14:29:23,320 TRACE (remote-thread-Test-NodeA-p2-t1:[]) [MultiTargetRequest] Target Test-NodeB of request 9 left the cluster view
> {noformat}
> So far, it looks like it's a JGroups bug similar to JGRP-2294, but we need to investigate further.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 4 months
[JBoss JIRA] (ISPN-9801) ClusterTopologyManagerImpl hangs when restarting a node with FORK
by Dan Berindei (Jira)
[ https://issues.jboss.org/browse/ISPN-9801?page=com.atlassian.jira.plugin.... ]
Dan Berindei edited comment on ISPN-9801 at 12/6/18 9:58 AM:
-------------------------------------------------------------
Update: in my test, the cluster seems to recover after the hearbeat command times out, 4 minutes by default ({{TransportConfiguration.DISTRIBUTED_SYNC_TIMEOUT}}, or {{<transport lock-timeout="..."/>}}).
was (Author: dan.berindei):
Update: in my test, the cluster seems to recover after the hearbeat command times out, 4 minutes by default ({{TransportConfiguration.DISTRIBUTED_SYNC_TIMEOUT}}, or {{<transport lock-timeout="..."/>).
> ClusterTopologyManagerImpl hangs when restarting a node with FORK
> -----------------------------------------------------------------
>
> Key: ISPN-9801
> URL: https://issues.jboss.org/browse/ISPN-9801
> Project: Infinispan
> Issue Type: Bug
> Components: Core
> Affects Versions: 10.0.0.Alpha1, 9.4.3.Final
> Reporter: Dan Berindei
> Assignee: Dan Berindei
> Priority: Major
> Fix For: 10.0.0.Alpha2, 9.4.4.Final
>
>
> When a server is restarted with `kill -9` or similar, both the old node and the new one can be in the JGroups view for a while. Normally this shouldn't be a problem, but sometimes the new node doesn't receive the {{HeartBeatCommand}} and the coordinator cannot process any new view updates.
> {noformat}
> 14:29:19,981 INFO (jgroups-12,Test-NodeA:[]) [CLUSTER] ISPN000094: Received new cluster view for channel FORKISPN: [Test-NodeA|4] (5) [Test-NodeA, Test-NodeB, Test-NodeC, Test-NodeD, Test-NodeE]
> 14:29:19,982 TRACE (transport-thread-Test-NodeA-p4-t14:[ViewHandling]) [ClusterTopologyManagerImpl] Updating cluster members for all the caches. New list is [Test-NodeA, Test-NodeB, Test-NodeC, Test-NodeD, Test-NodeE]
> 14:29:19,982 TRACE (transport-thread-Test-NodeA-p4-t14:[ViewHandling]) [JGroupsTransport] Test-NodeA sending request 9 to all: org.infinispan.topology.HeartBeatCommand@1163beb6
> 14:29:19,986 TRACE (jgroups-6,Test-NodeA:[]) [JGroupsTransport] Test-NodeA received response for request 9 from Test-NodeC: SuccessfulResponse(null)
> 14:29:19,987 TRACE (jgroups-9,Test-NodeA:[]) [JGroupsTransport] Test-NodeA received response for request 9 from Test-NodeD: SuccessfulResponse(null)
> 14:29:20,032 TRACE (jgroups-6,Test-NodeE:[]) [TCP_NIO2] Test-NodeE: received message batch of 1 messages from Test-NodeA
> 14:29:20,032 TRACE (jgroups-6,Test-NodeE:[]) [NAKACK2] Test-NodeE: message Test-NodeA::39 was added to queue (not yet server)
> 14:29:20,054 TRACE (jgroups-6,Test-NodeE:[]) [NAKACK2] Test-NodeE: received Test-NodeA#38
> 14:29:20,054 TRACE (jgroups-6,Test-NodeE:[]) [NAKACK2] Test-NodeE: delivering Test-NodeA#38
> # not actually delivered :)
> 14:29:20,054 TRACE (jgroups-6,Test-NodeE:[]) [MFC] Test-NodeA used 5 credits, 1999995 remaining
> 14:29:20,149 INFO (ForkThread-1,ForkChannelRestartTest:[]) [CLUSTER] ISPN000094: Received new cluster view for channel FORKISPN: [Test-NodeA|4] (5) [Test-NodeA, Test-NodeB, Test-NodeC, Test-NodeD, Test-NodeE]
> 14:29:21,119 DEBUG (testng-Test-1:[]) [ForkChannelRestartTest] Stopping channel Test-NodeB
> 14:29:23,319 INFO (VERIFY_SUSPECT.TimerThread-32,Test-NodeA:[]) [CLUSTER] ISPN000094: Received new cluster view for channel FORKISPN: [Test-NodeA|5] (4) [Test-NodeA, Test-NodeC, Test-NodeD, Test-NodeE]
> 14:29:23,320 TRACE (remote-thread-Test-NodeA-p2-t1:[]) [MultiTargetRequest] Target Test-NodeB of request 9 left the cluster view
> {noformat}
> So far, it looks like it's a JGroups bug similar to JGRP-2294, but we need to investigate further.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 4 months
[JBoss JIRA] (ISPN-9801) ClusterTopologyManagerImpl hangs when restarting a node with FORK
by Dan Berindei (Jira)
[ https://issues.jboss.org/browse/ISPN-9801?page=com.atlassian.jira.plugin.... ]
Dan Berindei edited comment on ISPN-9801 at 12/6/18 9:57 AM:
-------------------------------------------------------------
Update: in my test, the cluster seems to recover after the hearbeat command times out, 4 minutes by default ({{TransportConfiguration.DISTRIBUTED_SYNC_TIMEOUT}}, or {{<transport lock-timeout="..."/>).
was (Author: dan.berindei):
Update: in my test, the cluster seems to recover after the hearbeat command times out, 4 minutes by default ({{TransportConfiguration.DISTRIBUTED_SYNC_TIMEOUT}}).
> ClusterTopologyManagerImpl hangs when restarting a node with FORK
> -----------------------------------------------------------------
>
> Key: ISPN-9801
> URL: https://issues.jboss.org/browse/ISPN-9801
> Project: Infinispan
> Issue Type: Bug
> Components: Core
> Affects Versions: 10.0.0.Alpha1, 9.4.3.Final
> Reporter: Dan Berindei
> Assignee: Dan Berindei
> Priority: Major
> Fix For: 10.0.0.Alpha2, 9.4.4.Final
>
>
> When a server is restarted with `kill -9` or similar, both the old node and the new one can be in the JGroups view for a while. Normally this shouldn't be a problem, but sometimes the new node doesn't receive the {{HeartBeatCommand}} and the coordinator cannot process any new view updates.
> {noformat}
> 14:29:19,981 INFO (jgroups-12,Test-NodeA:[]) [CLUSTER] ISPN000094: Received new cluster view for channel FORKISPN: [Test-NodeA|4] (5) [Test-NodeA, Test-NodeB, Test-NodeC, Test-NodeD, Test-NodeE]
> 14:29:19,982 TRACE (transport-thread-Test-NodeA-p4-t14:[ViewHandling]) [ClusterTopologyManagerImpl] Updating cluster members for all the caches. New list is [Test-NodeA, Test-NodeB, Test-NodeC, Test-NodeD, Test-NodeE]
> 14:29:19,982 TRACE (transport-thread-Test-NodeA-p4-t14:[ViewHandling]) [JGroupsTransport] Test-NodeA sending request 9 to all: org.infinispan.topology.HeartBeatCommand@1163beb6
> 14:29:19,986 TRACE (jgroups-6,Test-NodeA:[]) [JGroupsTransport] Test-NodeA received response for request 9 from Test-NodeC: SuccessfulResponse(null)
> 14:29:19,987 TRACE (jgroups-9,Test-NodeA:[]) [JGroupsTransport] Test-NodeA received response for request 9 from Test-NodeD: SuccessfulResponse(null)
> 14:29:20,032 TRACE (jgroups-6,Test-NodeE:[]) [TCP_NIO2] Test-NodeE: received message batch of 1 messages from Test-NodeA
> 14:29:20,032 TRACE (jgroups-6,Test-NodeE:[]) [NAKACK2] Test-NodeE: message Test-NodeA::39 was added to queue (not yet server)
> 14:29:20,054 TRACE (jgroups-6,Test-NodeE:[]) [NAKACK2] Test-NodeE: received Test-NodeA#38
> 14:29:20,054 TRACE (jgroups-6,Test-NodeE:[]) [NAKACK2] Test-NodeE: delivering Test-NodeA#38
> # not actually delivered :)
> 14:29:20,054 TRACE (jgroups-6,Test-NodeE:[]) [MFC] Test-NodeA used 5 credits, 1999995 remaining
> 14:29:20,149 INFO (ForkThread-1,ForkChannelRestartTest:[]) [CLUSTER] ISPN000094: Received new cluster view for channel FORKISPN: [Test-NodeA|4] (5) [Test-NodeA, Test-NodeB, Test-NodeC, Test-NodeD, Test-NodeE]
> 14:29:21,119 DEBUG (testng-Test-1:[]) [ForkChannelRestartTest] Stopping channel Test-NodeB
> 14:29:23,319 INFO (VERIFY_SUSPECT.TimerThread-32,Test-NodeA:[]) [CLUSTER] ISPN000094: Received new cluster view for channel FORKISPN: [Test-NodeA|5] (4) [Test-NodeA, Test-NodeC, Test-NodeD, Test-NodeE]
> 14:29:23,320 TRACE (remote-thread-Test-NodeA-p2-t1:[]) [MultiTargetRequest] Target Test-NodeB of request 9 left the cluster view
> {noformat}
> So far, it looks like it's a JGroups bug similar to JGRP-2294, but we need to investigate further.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 4 months
[JBoss JIRA] (ISPN-9801) ClusterTopologyManagerImpl hangs when restarting a node with FORK
by Dan Berindei (Jira)
[ https://issues.jboss.org/browse/ISPN-9801?page=com.atlassian.jira.plugin.... ]
Dan Berindei commented on ISPN-9801:
------------------------------------
Update: in my test, the cluster seems to recover after the hearbeat command times out, 4 minutes by default ({{TransportConfiguration.DISTRIBUTED_SYNC_TIMEOUT}}).
> ClusterTopologyManagerImpl hangs when restarting a node with FORK
> -----------------------------------------------------------------
>
> Key: ISPN-9801
> URL: https://issues.jboss.org/browse/ISPN-9801
> Project: Infinispan
> Issue Type: Bug
> Components: Core
> Affects Versions: 10.0.0.Alpha1, 9.4.3.Final
> Reporter: Dan Berindei
> Assignee: Dan Berindei
> Priority: Major
> Fix For: 10.0.0.Alpha2, 9.4.4.Final
>
>
> When a server is restarted with `kill -9` or similar, both the old node and the new one can be in the JGroups view for a while. Normally this shouldn't be a problem, but sometimes the new node doesn't receive the {{HeartBeatCommand}} and the coordinator cannot process any new view updates.
> {noformat}
> 14:29:19,981 INFO (jgroups-12,Test-NodeA:[]) [CLUSTER] ISPN000094: Received new cluster view for channel FORKISPN: [Test-NodeA|4] (5) [Test-NodeA, Test-NodeB, Test-NodeC, Test-NodeD, Test-NodeE]
> 14:29:19,982 TRACE (transport-thread-Test-NodeA-p4-t14:[ViewHandling]) [ClusterTopologyManagerImpl] Updating cluster members for all the caches. New list is [Test-NodeA, Test-NodeB, Test-NodeC, Test-NodeD, Test-NodeE]
> 14:29:19,982 TRACE (transport-thread-Test-NodeA-p4-t14:[ViewHandling]) [JGroupsTransport] Test-NodeA sending request 9 to all: org.infinispan.topology.HeartBeatCommand@1163beb6
> 14:29:19,986 TRACE (jgroups-6,Test-NodeA:[]) [JGroupsTransport] Test-NodeA received response for request 9 from Test-NodeC: SuccessfulResponse(null)
> 14:29:19,987 TRACE (jgroups-9,Test-NodeA:[]) [JGroupsTransport] Test-NodeA received response for request 9 from Test-NodeD: SuccessfulResponse(null)
> 14:29:20,032 TRACE (jgroups-6,Test-NodeE:[]) [TCP_NIO2] Test-NodeE: received message batch of 1 messages from Test-NodeA
> 14:29:20,032 TRACE (jgroups-6,Test-NodeE:[]) [NAKACK2] Test-NodeE: message Test-NodeA::39 was added to queue (not yet server)
> 14:29:20,054 TRACE (jgroups-6,Test-NodeE:[]) [NAKACK2] Test-NodeE: received Test-NodeA#38
> 14:29:20,054 TRACE (jgroups-6,Test-NodeE:[]) [NAKACK2] Test-NodeE: delivering Test-NodeA#38
> # not actually delivered :)
> 14:29:20,054 TRACE (jgroups-6,Test-NodeE:[]) [MFC] Test-NodeA used 5 credits, 1999995 remaining
> 14:29:20,149 INFO (ForkThread-1,ForkChannelRestartTest:[]) [CLUSTER] ISPN000094: Received new cluster view for channel FORKISPN: [Test-NodeA|4] (5) [Test-NodeA, Test-NodeB, Test-NodeC, Test-NodeD, Test-NodeE]
> 14:29:21,119 DEBUG (testng-Test-1:[]) [ForkChannelRestartTest] Stopping channel Test-NodeB
> 14:29:23,319 INFO (VERIFY_SUSPECT.TimerThread-32,Test-NodeA:[]) [CLUSTER] ISPN000094: Received new cluster view for channel FORKISPN: [Test-NodeA|5] (4) [Test-NodeA, Test-NodeC, Test-NodeD, Test-NodeE]
> 14:29:23,320 TRACE (remote-thread-Test-NodeA-p2-t1:[]) [MultiTargetRequest] Target Test-NodeB of request 9 left the cluster view
> {noformat}
> So far, it looks like it's a JGroups bug similar to JGRP-2294, but we need to investigate further.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 4 months