[JBoss JIRA] (WFLY-6355) Error executing command PrepareCommand/GetKeyValueCommand due to replication timeout
by Markus Heberling (JIRA)
[ https://issues.jboss.org/browse/WFLY-6355?page=com.atlassian.jira.plugin.... ]
Markus Heberling commented on WFLY-6355:
----------------------------------------
We get the error on Wildfly 10.1.0.CR1. We haven't seen it on Wildfly 10.0.0.Final, which we used before.
16:49:22,394 ERROR [org.infinispan.interceptors.InvocationContextInterceptor] (default task-7) ISPN000136: Error executing command GetKeyValueCommand, writing keys []: org.infinispan.util.concurrent.TimeoutException: Replication timeout for usp2vmurcs001
at org.infinispan.remoting.transport.jgroups.JGroupsTransport.checkRsp(JGroupsTransport.java:801)
at org.infinispan.remoting.transport.jgroups.JGroupsTransport.lambda$invokeRemotelyAsync$1(JGroupsTransport.java:642)
at java.util.concurrent.CompletableFuture.uniApply(CompletableFuture.java:602)
at java.util.concurrent.CompletableFuture$UniApply.tryFire(CompletableFuture.java:577)
at java.util.concurrent.CompletableFuture.postComplete(CompletableFuture.java:474)
at java.util.concurrent.CompletableFuture.complete(CompletableFuture.java:1962)
at org.infinispan.remoting.transport.jgroups.CommandAwareRpcDispatcher.staggeredProcessNext(CommandAwareRpcDispatcher.java:375)
at org.infinispan.remoting.transport.jgroups.CommandAwareRpcDispatcher.lambda$processCallsStaggered$3(CommandAwareRpcDispatcher.java:357)
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
at java.util.concurrent.FutureTask.run(FutureTask.java:266)
at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:180)
at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at java.lang.Thread.run(Thread.java:745)
> Error executing command PrepareCommand/GetKeyValueCommand due to replication timeout
> ------------------------------------------------------------------------------------
>
> Key: WFLY-6355
> URL: https://issues.jboss.org/browse/WFLY-6355
> Project: WildFly
> Issue Type: Bug
> Components: Clustering
> Affects Versions: 10.0.0.Final
> Reporter: Michal Vinkler
> Assignee: Paul Ferraro
>
> This is a separate issue originally logged as part of JBEAP-794 (#2 in this [comment|https://issues.jboss.org/browse/JBEAP-794?focusedCommentId=131706...]).
> It comes with 2 different messages:
> {code:title=1. Error executing command GetKeyValueCommand}
> [JBossINF] [0m[31m03:23:38,763 ERROR [org.infinispan.interceptors.InvocationContextInterceptor] (default task-92) ISPN000136: Error executing command GetKeyValueCommand, writing keys []: org.infinispan.util.concurrent.TimeoutException: Replication timeout for perf19
> [JBossINF] at org.infinispan.remoting.transport.jgroups.JGroupsTransport.checkRsp(JGroupsTransport.java:765)
> [JBossINF] at org.infinispan.remoting.transport.jgroups.JGroupsTransport.lambda$invokeRemotelyAsync$175(JGroupsTransport.java:612)
> [JBossINF] at java.util.concurrent.CompletableFuture.uniApply(CompletableFuture.java:602)
> [JBossINF] at java.util.concurrent.CompletableFuture$UniApply.tryFire(CompletableFuture.java:577)
> [JBossINF] at java.util.concurrent.CompletableFuture.postComplete(CompletableFuture.java:474)
> [JBossINF] at java.util.concurrent.CompletableFuture.complete(CompletableFuture.java:1962)
> [JBossINF] at org.infinispan.remoting.transport.jgroups.RspListFuture.call(RspListFuture.java:47)
> [JBossINF] at org.infinispan.remoting.transport.jgroups.RspListFuture.call(RspListFuture.java:16)
> [JBossINF] at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> [JBossINF] at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:180)
> [JBossINF] at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293)
> [JBossINF] at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> [JBossINF] at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> [JBossINF] at java.lang.Thread.run(Thread.java:745)
> {code}
> This one appears exactly in the same scenarios and numbers as JBEAP-3696 - see [occurrences report|http://download.eng.brq.redhat.com/scratch/mvinkler/reports/occurr...]
> (ejb-ejbservlet and http-session scenarios with *REPL* cache)
> {code:title=2. Error executing command PrepareCommand}
> [JBossINF] [0m[31m03:23:38,454 ERROR [org.infinispan.interceptors.InvocationContextInterceptor] (default task-24) ISPN000136: Error executing command PrepareCommand, writing keys [UOzA9Tq6F40Y0pcaLUpLe6YLgsYPuFE3SZQoH7iW, UOzA9Tq6F40Y0pcaLUpLe6YLgsYPuFE3SZQoH7iW, UOzA9Tq6F40Y0pcaLUpLe6YLgsYPuFE3SZQoH7iW]: org.infinispan.util.concurrent.TimeoutException: Replication timeout for perf19
> [JBossINF] at org.infinispan.remoting.transport.jgroups.JGroupsTransport.checkRsp(JGroupsTransport.java:765)
> [JBossINF] at org.infinispan.remoting.transport.jgroups.JGroupsTransport.lambda$invokeRemotelyAsync$175(JGroupsTransport.java:612)
> [JBossINF] at java.util.concurrent.CompletableFuture.uniApply(CompletableFuture.java:602)
> [JBossINF] at java.util.concurrent.CompletableFuture$UniApply.tryFire(CompletableFuture.java:577)
> [JBossINF] at java.util.concurrent.CompletableFuture.postComplete(CompletableFuture.java:474)
> [JBossINF] at java.util.concurrent.CompletableFuture.complete(CompletableFuture.java:1962)
> [JBossINF] at org.infinispan.remoting.transport.jgroups.RspListFuture.call(RspListFuture.java:47)
> [JBossINF] at org.infinispan.remoting.transport.jgroups.RspListFuture.call(RspListFuture.java:16)
> [JBossINF] at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> [JBossINF] at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:180)
> [JBossINF] at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293)
> [JBossINF] at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> [JBossINF] at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> [JBossINF] at java.lang.Thread.run(Thread.java:745)
> {code}
> This one appears exactly in the same scenarios and numbers as JBEAP-3780, JBEAP-3781 (and partially also JBEAP-3782) - see [occurrences report|http://download.eng.brq.redhat.com/scratch/mvinkler/reports/occurr...]
> (ejb-remote, ejb-ejbservlet and http-session scenarios with *REPL* cache and *SYNC* replication)
> Server link:
> http://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/eap-7x-failover-http-...
> Occurrences report:
> http://download.eng.brq.redhat.com/scratch/mvinkler/reports/occurrences/E...
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 8 months
[JBoss JIRA] (WFLY-6882) A client is not able to invoke EJB's deployed as "HASingleton deployment"
by Enrique González Martínez (JIRA)
[ https://issues.jboss.org/browse/WFLY-6882?page=com.atlassian.jira.plugin.... ]
Enrique González Martínez commented on WFLY-6882:
-------------------------------------------------
Hi [~pferraro]
I think ejb-client topology and ejb are separate concepts. The topology does not contain any information about what is deployed (just the info related to connect to that node). I think is posible to allow the topology to be sent independently if the singleton is deployed or not and let the ejb-client to query once one node is down. After all setting up the whole topology statically will throw the same result (most of the endpoint connections will be useless except one where the singleton is deployed)
> A client is not able to invoke EJB's deployed as "HASingleton deployment"
> -------------------------------------------------------------------------
>
> Key: WFLY-6882
> URL: https://issues.jboss.org/browse/WFLY-6882
> Project: WildFly
> Issue Type: Bug
> Components: Clustering, EJB
> Affects Versions: 10.0.0.Final, 11.0.0.Alpha1
> Reporter: Wolf-Dieter Fink
> Assignee: Enrique González Martínez
>
> Given that an application contains a SLSB and is clustered, any EJB client will be updated to have a view off all cluster members and is able to use and failover to any node in the cluster no matter whether it is in the initial list of servers.
> Now if the application is marked as "singleton-deployment" via jboss-all.xml and deployed to all servers only one server in a cluster will pick it and make it active.
> Now the expectation is that a client is routed to that server no matter whether this special server is included in the clients initial connection list.
> The interesting thing is that the client.log show that both servers are connected it the application is NOT marked as singleton
> But only the initial server is connected if the app is marked as singleton!
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 8 months
[JBoss JIRA] (ELY-587) SSLContext integration into DirContext supplier service
by Jan Kalina (JIRA)
[ https://issues.jboss.org/browse/ELY-587?page=com.atlassian.jira.plugin.sy... ]
Jan Kalina edited comment on ELY-587 at 8/16/16 6:06 AM:
---------------------------------------------------------
If we would like *to pass parameter into SocketFactory*, it would require custom version of:
* LdapCtxFactory (can be passed into InitialContext as java.naming.factory.initial env)
* LdapCtx (get SocketFactory class name from env)
* LdapClient (constructed in LdapCtx)
* Connection (constructed in LdapClient, use reflection to obtain new instance of (SSL)SocketFactory - call getDefault())
was (Author: honza889):
If we would like *to pass parameter into SocketFactory*, it would require custom version of:
* LdapCtxFactory (can be passed into InitialContext as java.naming.factory.initial env)
* LdapCtx (get SocketFactory class name from env)
* LdapClient (constructed in LdapCtx)
* Connection (constructed in LdapClient, use abstraction to obtain (SSL)SocketFactory)
> SSLContext integration into DirContext supplier service
> -------------------------------------------------------
>
> Key: ELY-587
> URL: https://issues.jboss.org/browse/ELY-587
> Project: WildFly Elytron
> Issue Type: Task
> Components: SSL
> Reporter: Jan Kalina
> Assignee: Jan Kalina
>
> * we already have a resource to define the SSLContext
> * we want use it for connection to LDAP
> * resource of DirContext supplier (see ELY-462) should reference SSLContext resource / capability
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 8 months
[JBoss JIRA] (ELY-587) SSLContext integration into DirContext supplier service
by Jan Kalina (JIRA)
[ https://issues.jboss.org/browse/ELY-587?page=com.atlassian.jira.plugin.sy... ]
Jan Kalina commented on ELY-587:
--------------------------------
If we would like *to pass parameter into SocketFactory*, it would require custom version of:
* LdapCtxFactory (can be passed into InitialContext as java.naming.factory.initial env)
* LdapCtx (get SocketFactory class name from env)
* LdapClient (constructed in LdapCtx)
* Connection (constructed in LdapClient, use abstraction to obtain (SSL)SocketFactory)
> SSLContext integration into DirContext supplier service
> -------------------------------------------------------
>
> Key: ELY-587
> URL: https://issues.jboss.org/browse/ELY-587
> Project: WildFly Elytron
> Issue Type: Task
> Components: SSL
> Reporter: Jan Kalina
> Assignee: Jan Kalina
>
> * we already have a resource to define the SSLContext
> * we want use it for connection to LDAP
> * resource of DirContext supplier (see ELY-462) should reference SSLContext resource / capability
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 8 months
[JBoss JIRA] (WFCORE-1718) Handlers within Audit Logger are not removed properly when Audit Logger is removed
by Jan Tymel (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1718?page=com.atlassian.jira.plugi... ]
Jan Tymel updated WFCORE-1718:
------------------------------
Description:
If Audit Logger is removed, destination handlers (i.e. its child nodes) are not removed properly. They are not present in the config file. They seem to be not removed "internally" though. This leads to a couple of issues:
1. It is not possible to remove referenced File/Syslog handlers. If user tries to remove them the _NullPointerException_ is given as a result. Try following commands:
{{/core-service=management/access=audit/file-handler=file:remove()}}
{{/core-service=management/access=audit/syslog-handler=my-syslog-handler:remove()}}
Their output is:
{code}
{
"outcome" => "failed",
"failure-description" => "WFLYCTL0158: Operation handler failed: java.lang.NullPointerException",
"rolled-back" => true
}
{code}
2. AuditLog continues to send auditable events to previously referenced File/Syslog handlers.
* Create auditable event (e.g. {{/subsystem=logging/logger=com.arjuna:write-attribute(name=level,value=DEBUG)}})
* See log in the file (WILDFLY_HOME/standalone/data/audit-log.log)
* See log in the syslog (/var/log/messages)
was:
If Audit Logger is removed, destination handlers (i.e. its child nodes) are not removed properly. They are not present in the config file. They seem to be not removed "internally" though. This leads to a couple of issues:
1. It is not possible to remove referenced File/Syslog handlers. If user tries to remove them the _NullPointerException_ is given as a result. Try following commands:
{{/core-service=management/access=audit/file-handler=file:remove()}}
{{/core-service=management/access=audit/syslog-handler=my-syslog-handler:remove()}}
Their output is:
{code}
{
"outcome" => "failed",
"failure-description" => "WFLYCTL0158: Operation handler failed: java.lang.NullPointerException",
"rolled-back" => true
}
{code}
2. AuditLog continues to send auditable events to previously referenced File/Syslog handlers.
* Create auditable event (e.g. {{/subsystem=logging/logger=com.arjuna:write-attribute(name=level,value=DEBUG)}})
* See log in the file (EAP_HOME/standalone/data/audit-log.log)
* See log in the syslog (/var/log/messages)
> Handlers within Audit Logger are not removed properly when Audit Logger is removed
> ----------------------------------------------------------------------------------
>
> Key: WFCORE-1718
> URL: https://issues.jboss.org/browse/WFCORE-1718
> Project: WildFly Core
> Issue Type: Bug
> Components: Domain Management
> Affects Versions: 3.0.0.Alpha5
> Reporter: Jan Tymel
> Assignee: Brian Stansberry
>
> If Audit Logger is removed, destination handlers (i.e. its child nodes) are not removed properly. They are not present in the config file. They seem to be not removed "internally" though. This leads to a couple of issues:
> 1. It is not possible to remove referenced File/Syslog handlers. If user tries to remove them the _NullPointerException_ is given as a result. Try following commands:
> {{/core-service=management/access=audit/file-handler=file:remove()}}
> {{/core-service=management/access=audit/syslog-handler=my-syslog-handler:remove()}}
> Their output is:
> {code}
> {
> "outcome" => "failed",
> "failure-description" => "WFLYCTL0158: Operation handler failed: java.lang.NullPointerException",
> "rolled-back" => true
> }
> {code}
> 2. AuditLog continues to send auditable events to previously referenced File/Syslog handlers.
> * Create auditable event (e.g. {{/subsystem=logging/logger=com.arjuna:write-attribute(name=level,value=DEBUG)}})
> * See log in the file (WILDFLY_HOME/standalone/data/audit-log.log)
> * See log in the syslog (/var/log/messages)
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 8 months
[JBoss JIRA] (WFCORE-1718) Handlers within Audit Logger are not removed properly when Audit Logger is removed
by Jan Tymel (JIRA)
Jan Tymel created WFCORE-1718:
---------------------------------
Summary: Handlers within Audit Logger are not removed properly when Audit Logger is removed
Key: WFCORE-1718
URL: https://issues.jboss.org/browse/WFCORE-1718
Project: WildFly Core
Issue Type: Bug
Components: Domain Management
Affects Versions: 3.0.0.Alpha5
Reporter: Jan Tymel
Assignee: Brian Stansberry
If Audit Logger is removed, destination handlers (i.e. its child nodes) are not removed properly. They are not present in the config file. They seem to be not removed "internally" though. This leads to a couple of issues:
1. It is not possible to remove referenced File/Syslog handlers. If user tries to remove them the _NullPointerException_ is given as a result. Try following commands:
{{/core-service=management/access=audit/file-handler=file:remove()}}
{{/core-service=management/access=audit/syslog-handler=my-syslog-handler:remove()}}
Their output is:
{code}
{
"outcome" => "failed",
"failure-description" => "WFLYCTL0158: Operation handler failed: java.lang.NullPointerException",
"rolled-back" => true
}
{code}
2. AuditLog continues to send auditable events to previously referenced File/Syslog handlers.
* Create auditable event (e.g. {{/subsystem=logging/logger=com.arjuna:write-attribute(name=level,value=DEBUG)}})
* See log in the file (EAP_HOME/standalone/data/audit-log.log)
* See log in the syslog (/var/log/messages)
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 8 months
[JBoss JIRA] (WFLY-6959) Move to using apache's upstream JSTL
by Tomaz Cerar (JIRA)
Tomaz Cerar created WFLY-6959:
---------------------------------
Summary: Move to using apache's upstream JSTL
Key: WFLY-6959
URL: https://issues.jboss.org/browse/WFLY-6959
Project: WildFly
Issue Type: Task
Components: EE, Web (Undertow)
Affects Versions: 10.0.0.CR2
Reporter: Tomaz Cerar
Assignee: Tomaz Cerar
We are now using forked combination of apache & java.net's version of JSTL.
We should look into using upstream version if possible.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 8 months
[JBoss JIRA] (WFCORE-897) IPv6 address in security realm using Kerberos
by Darran Lofthouse (JIRA)
[ https://issues.jboss.org/browse/WFCORE-897?page=com.atlassian.jira.plugin... ]
Darran Lofthouse commented on WFCORE-897:
-----------------------------------------
Leaving unassigned as I am not planning to look into this one.
> IPv6 address in security realm using Kerberos
> ---------------------------------------------
>
> Key: WFCORE-897
> URL: https://issues.jboss.org/browse/WFCORE-897
> Project: WildFly Core
> Issue Type: Bug
> Components: Security
> Reporter: Martin Choma
> Priority: Optional
>
> When kerberos in realm is configured to use IPv6 address with square brackets, eg. [2620:52:0:2804:56ee:75ff:fe34:630e], EAP generates TGS-REQ for remote/2620:52:0:2804:56ee:75ff:fe34:630e instead of remote/[2620:52:0:2804:56ee:75ff:fe34:630e]. It cause failures when remote/[2620:52:0:2804:56ee:75ff:fe34:630e]@JBOSS.ORG is used in keytab.
> This happens when such realm secures CLI or EJB remoting. It doesnt happen when used for securing management console."
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 8 months
[JBoss JIRA] (WFCORE-897) IPv6 address in security realm using Kerberos
by Darran Lofthouse (JIRA)
[ https://issues.jboss.org/browse/WFCORE-897?page=com.atlassian.jira.plugin... ]
Darran Lofthouse reassigned WFCORE-897:
---------------------------------------
Assignee: (was: Darran Lofthouse)
> IPv6 address in security realm using Kerberos
> ---------------------------------------------
>
> Key: WFCORE-897
> URL: https://issues.jboss.org/browse/WFCORE-897
> Project: WildFly Core
> Issue Type: Bug
> Components: Security
> Reporter: Martin Choma
> Priority: Optional
>
> When kerberos in realm is configured to use IPv6 address with square brackets, eg. [2620:52:0:2804:56ee:75ff:fe34:630e], EAP generates TGS-REQ for remote/2620:52:0:2804:56ee:75ff:fe34:630e instead of remote/[2620:52:0:2804:56ee:75ff:fe34:630e]. It cause failures when remote/[2620:52:0:2804:56ee:75ff:fe34:630e]@JBOSS.ORG is used in keytab.
> This happens when such realm secures CLI or EJB remoting. It doesnt happen when used for securing management console."
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 8 months
[JBoss JIRA] (JGRP-2082) Coordinator failover is taking longer because VERIFY_SUSPECT runs twice
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/JGRP-2082?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on JGRP-2082:
-----------------------------------------------
Jakub Markos <jmarkos(a)redhat.com> changed the Status of [bug 1348404|https://bugzilla.redhat.com/show_bug.cgi?id=1348404] from ON_QA to VERIFIED
> Coordinator failover is taking longer because VERIFY_SUSPECT runs twice
> -----------------------------------------------------------------------
>
> Key: JGRP-2082
> URL: https://issues.jboss.org/browse/JGRP-2082
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 3.6.3
> Reporter: Osamu Nagano
> Assignee: Bela Ban
> Fix For: 3.6.10, 4.0
>
>
> There are 4 machines (m03, ..., m06) and 7 nodes (n001, ..., n007) on each. To test the coordinator failover behaviour, nodes on m03 are all killed at the same time. These are suspected and verified in sequence at the first time (line 9 to 18, only m03_n007 is verified as dead and others are just queued), while these are verified as a whole at the second time (line 19 to 34). Since the coordinator is in the queued at the first time, view change is not triggered and causing a delay.
> - m03_n001 is the original coordinator.
> - m05_n001 is the next coordinator and the owner of the following log messages.
> {code}
> 8 12:04:10,997 TRACE [org.jgroups.protocols.FD_SOCK] (FD_SOCK acceptor,m05_n001/clustered) m05_n001/clustered: accepted connection from /172.20.66.36:29702
> 9 12:04:10,999 TRACE [org.jgroups.protocols.FD_SOCK] (INT-28,shared=udp) m05_n001/clustered: received SUSPECT message from m06_n007/clustered: suspects=[m03_n001/clustered]
> 10 12:04:10,999 TRACE [org.jgroups.protocols.FD_SOCK] (INT-28,shared=udp) m05_n001/clustered: received SUSPECT message from m06_n007/clustered: suspects=[m03_n002/clustered]
> 11 12:04:10,999 TRACE [org.jgroups.protocols.FD_SOCK] (INT-28,shared=udp) m05_n001/clustered: received SUSPECT message from m06_n007/clustered: suspects=[m03_n003/clustered]
> 12 12:04:10,999 TRACE [org.jgroups.protocols.FD_SOCK] (INT-28,shared=udp) m05_n001/clustered: received SUSPECT message from m06_n007/clustered: suspects=[m03_n004/clustered]
> 13 12:04:10,999 TRACE [org.jgroups.protocols.FD_SOCK] (INT-28,shared=udp) m05_n001/clustered: received SUSPECT message from m06_n007/clustered: suspects=[m03_n005/clustered]
> 14 12:04:10,999 TRACE [org.jgroups.protocols.FD_SOCK] (INT-28,shared=udp) m05_n001/clustered: received SUSPECT message from m06_n007/clustered: suspects=[m03_n006/clustered]
> 15 12:04:10,999 TRACE [org.jgroups.protocols.FD_SOCK] (INT-28,shared=udp) m05_n001/clustered: received SUSPECT message from m06_n007/clustered: suspects=[m03_n007/clustered]
> 16 12:04:10,999 DEBUG [org.jgroups.protocols.FD_SOCK] (INT-28,shared=udp) m05_n001/clustered: suspecting [m03_n001/clustered, m03_n002/clustered, m03_n003/clustered, m03_n004/clustered, m03_n005/clustered, m03_n006/clustered, m03_n007/clustered]
> 17 12:04:11,000 TRACE [org.jgroups.protocols.VERIFY_SUSPECT] (INT-28,shared=udp) verifying that m03_n007/clustered is dead
> 18 12:04:12,000 TRACE [org.jgroups.protocols.VERIFY_SUSPECT] (VERIFY_SUSPECT.TimerThread,m05_n001/clustered) m03_n007/clustered is dead (passing up SUSPECT event)
> 19 12:04:16,000 TRACE [org.jgroups.protocols.FD_SOCK] (INT-28,shared=udp) m05_n001/clustered: received SUSPECT message from m06_n007/clustered: suspects=[m03_n003/clustered, m03_n004/clustered, m03_n005/clustered, m03_n002/clustered, m03_n001/clustered, m03_n007/clustered, m03_n006/clustered]
> 20 12:04:16,000 DEBUG [org.jgroups.protocols.FD_SOCK] (INT-28,shared=udp) m05_n001/clustered: suspecting [m03_n001/clustered, m03_n002/clustered, m03_n003/clustered, m03_n004/clustered, m03_n005/clustered, m03_n006/clustered, m03_n007/clustered]
> 21 12:04:16,000 TRACE [org.jgroups.protocols.VERIFY_SUSPECT] (INT-28,shared=udp) verifying that m03_n003/clustered is dead
> 22 12:04:16,000 TRACE [org.jgroups.protocols.VERIFY_SUSPECT] (INT-28,shared=udp) verifying that m03_n004/clustered is dead
> 23 12:04:16,001 TRACE [org.jgroups.protocols.VERIFY_SUSPECT] (INT-28,shared=udp) verifying that m03_n005/clustered is dead
> 24 12:04:16,001 TRACE [org.jgroups.protocols.VERIFY_SUSPECT] (INT-28,shared=udp) verifying that m03_n002/clustered is dead
> 25 12:04:16,001 TRACE [org.jgroups.protocols.VERIFY_SUSPECT] (INT-28,shared=udp) verifying that m03_n001/clustered is dead
> 26 12:04:16,001 TRACE [org.jgroups.protocols.VERIFY_SUSPECT] (INT-28,shared=udp) verifying that m03_n007/clustered is dead
> 27 12:04:16,001 TRACE [org.jgroups.protocols.VERIFY_SUSPECT] (INT-28,shared=udp) verifying that m03_n006/clustered is dead
> 28 12:04:17,001 TRACE [org.jgroups.protocols.VERIFY_SUSPECT] (VERIFY_SUSPECT.TimerThread,m05_n001/clustered) m03_n003/clustered is dead (passing up SUSPECT event)
> 29 12:04:17,001 TRACE [org.jgroups.protocols.VERIFY_SUSPECT] (VERIFY_SUSPECT.TimerThread,m05_n001/clustered) m03_n004/clustered is dead (passing up SUSPECT event)
> 30 12:04:17,002 TRACE [org.jgroups.protocols.VERIFY_SUSPECT] (VERIFY_SUSPECT.TimerThread,m05_n001/clustered) m03_n007/clustered is dead (passing up SUSPECT event)
> 31 12:04:17,002 TRACE [org.jgroups.protocols.VERIFY_SUSPECT] (VERIFY_SUSPECT.TimerThread,m05_n001/clustered) m03_n001/clustered is dead (passing up SUSPECT event)
> 32 12:04:17,002 TRACE [org.jgroups.protocols.VERIFY_SUSPECT] (VERIFY_SUSPECT.TimerThread,m05_n001/clustered) m03_n002/clustered is dead (passing up SUSPECT event)
> 33 12:04:17,003 TRACE [org.jgroups.protocols.VERIFY_SUSPECT] (VERIFY_SUSPECT.TimerThread,m05_n001/clustered) m03_n005/clustered is dead (passing up SUSPECT event)
> 34 12:04:17,003 TRACE [org.jgroups.protocols.VERIFY_SUSPECT] (VERIFY_SUSPECT.TimerThread,m05_n001/clustered) m03_n006/clustered is dead (passing up SUSPECT event)
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 8 months