Created ISPN JIRA

Mircea Markus <mmarkus@redhat.com> made a comment on jira ISPN-2577

This has more of a cosmetic impact, but nice to have for the final.

Michal Linhard <mlinhard@redhat.com> made a comment on jira ISPN-2577

I didn't want to create a new JIRA this kind of cosmetic task, but if we're doing this SuspectException silencing, let's sync it with behaviour on hotrod client. If we have a RetryOnFailureOperation should it log an error (in the retry mode) ? My proposal would be switching this to warning.

{code}
09:25:19,154 ERROR [org.jboss.smartfrog.jdg.loaddriver.DriverThread] (DriverThread-378) Error doing: PUT key655878 to node node0003, took 1395 ms
org.infinispan.client.hotrod.exceptions.RemoteNodeSuspecException:Request for message id[1981607] returned server error (status=0x85): org.infinispan.remoting.transport.jgroups.SuspectException: One or more nodes have left the cluster while replicating command SingleRpcCommand{cacheName='testCache', command=PutKeyValueCommand{key=ByteArrayKey{data=ByteArray{size=12, hashCode=727c8fa, array=0x033e096b65793635..}}, value=CacheValue{data=ByteArray{size=1029, array=0x034304002106020a..}, version=9007207845383422}, flags=[IGNORE_RETURN_VALUES], putIfAbsent=false, lifespanMillis=-1, maxIdleTimeMillis=-1, successful=true}}
	at org.infinispan.client.hotrod.impl.protocol.Codec10.checkForErrorsInResponseStatus(Codec10.java:153)
	at org.infinispan.client.hotrod.impl.protocol.Codec10.readHeader(Codec10.java:110)
	at org.infinispan.client.hotrod.impl.operations.HotRodOperation.readHeaderAndValidate(HotRodOperation.java:78)
	at org.infinispan.client.hotrod.impl.operations.AbstractKeyValueOperation.sendPutOperation(AbstractKeyValueOperation.java:72)
	at org.infinispan.client.hotrod.impl.operations.PutOperation.executeOperation(PutOperation.java:52)
	at org.infinispan.client.hotrod.impl.operations.PutOperation.executeOperation(PutOperation.java:41)
	at org.infinispan.client.hotrod.impl.operations.RetryOnFailureOperation.execute(RetryOnFailureOperation.java:68)
	at org.infinispan.client.hotrod.impl.RemoteCacheImpl.put(RemoteCacheImpl.java:231)
	at org.infinispan.CacheSupport.put(CacheSupport.java:53)
	at org.jboss.qa.jdg.adapter.HotRodAdapter$HotRodRemoteCacheAdapter.put(HotRodAdapter.java:247)
	at org.jboss.qa.jdg.adapter.HotRodAdapter$HotRodRemoteCacheAdapter.put(HotRodAdapter.java:232)
	at org.jboss.smartfrog.jdg.loaddriver.DriverThreadImpl.makeRequest(DriverThreadImpl.java:236)
	at org.jboss.smartfrog.jdg.loaddriver.DriverThreadImpl.run(DriverThreadImpl.java:331)

{code}

Galder Zamarreño <galder.zamarreno@redhat.com> made a comment on jira ISPN-2577

We should also silence situations like ISPN-2752. In that JIRA, a node is trying to establish a new view sending a cache topology control view, but the node is stopping.

Nominated for 6.2 release notes.

Still present in JDG 6.2.0.DR3

Anuj Shah <anujshahwork@gmail.com> made a comment on jira ISPN-2577

There's a discussion here:
https://community.jboss.org/message/846155

This issue may be more than cosmetic

Michal Linhard <mlinhard@redhat.com> made a comment on jira ISPN-2577

This issue is about silencing the SuspectExceptions - not displaying them as error level message, since it's not an exceptional situation that a node is suspected during topology changes.

Of course currently SuspectExceptions may accompany other serious errors, but those should be logged separately.

Still present in 6.2.0.ER4

Dan Berindei <dberinde@redhat.com> updated the status of jira ISPN-2577 to Resolved