[JBoss JIRA] (ISPN-4213) clustered Wildfly unexpected nodes SuspectException
by Dan Berindei (JIRA)
[ https://issues.jboss.org/browse/ISPN-4213?page=com.atlassian.jira.plugin.... ]
Dan Berindei resolved ISPN-4213.
--------------------------------
Fix Version/s: 8.2.2.Final
Resolution: Done
The suspect exceptions should be fixed by ISPN-6599.
> clustered Wildfly unexpected nodes SuspectException
> ---------------------------------------------------
>
> Key: ISPN-4213
> URL: https://issues.jboss.org/browse/ISPN-4213
> Project: Infinispan
> Issue Type: Bug
> Components: Core
> Affects Versions: 6.0.1.Final
> Environment: ubuntu 13.04, jboss wildfly 8.0.1, infinispan 6.0.1.Final, jgroups 3.4.3.Final
> Reporter: Hielke Hoeve
> Fix For: 8.2.2.Final
>
>
> Our current production system has a cluster of 2 nodes using Wildfly 8.0.1. We have used the "ha" profile and "ha" socket-binding-group as a baseline to create the profile for the clusters. The cluster has a REST application deployed. This application uses 2 infinispan cache containers (hibernate and application). In total these views have 5 local caches, 3 invalidation caches and 7 replicated caches. The cache containers use udp as transport. Our hibernate container is the default config as provided by the "ha" profile.
> Last thursday and yesterday the one of the nodes started throwing SuspectException during a hibernate flush. The applications had only a few active users.
> Node 1 says:
> -----------------
> 2014-04-15 17:40:53,380 ERROR [org.jboss.as.ejb3.invocation] (default task-22) JBAS014134: EJB Invocation failed on component ConversatieResourceRESTService
> for method public javax.ws.rs.core.Response ...ConversatieResourceRESTService.setStatus(...event.Con
> versatieStatusObject): javax.ejb.EJBTransactionRolledbackException: Transaction rolled back
> ...
> ...
> at org.infinispan.commands.AbstractVisitor.visitPutKeyValueCommand(AbstractVisitor.java:32) [infinispan-core-6.0.1.Final.jar:6.0.1.Final]
> at org.infinispan.commands.write.PutKeyValueCommand.acceptVisitor(PutKeyValueCommand.java:70) [infinispan-core-6.0.1.Final.jar:6.0.1.Final]
> at org.infinispan.interceptors.InterceptorChain.invoke(InterceptorChain.java:333) [infinispan-core-6.0.1.Final.jar:6.0.1.Final]
> at org.infinispan.CacheImpl.executeCommandAndCommitIfNeeded(CacheImpl.java:1306) [infinispan-core-6.0.1.Final.jar:6.0.1.Final]
> at org.infinispan.CacheImpl.putInternal(CacheImpl.java:878) [infinispan-core-6.0.1.Final.jar:6.0.1.Final]
> at org.infinispan.CacheImpl.put(CacheImpl.java:870) [infinispan-core-6.0.1.Final.jar:6.0.1.Final]
> at org.infinispan.DecoratedCache.put(DecoratedCache.java:401) [infinispan-core-6.0.1.Final.jar:6.0.1.Final]
> at org.infinispan.AbstractDelegatingCache.put(AbstractDelegatingCache.java:276) [infinispan-core-6.0.1.Final.jar:6.0.1.Final]
> at org.hibernate.cache.infinispan.access.TransactionalAccessDelegate.update(TransactionalAccessDelegate.java:192) [hibernate-infinispan-4.3.4.Final.j
> ar:4.3.4.Final]
> at org.hibernate.cache.infinispan.entity.TransactionalAccess.update(TransactionalAccess.java:89) [hibernate-infinispan-4.3.4.Final.jar:4.3.4.Final]
> at org.hibernate.action.internal.EntityUpdateAction.cacheUpdate(EntityUpdateAction.java:234) [hibernate-core-4.3.4.Final.jar:4.3.4.Final]
> at org.hibernate.action.internal.EntityUpdateAction.execute(EntityUpdateAction.java:209) [hibernate-core-4.3.4.Final.jar:4.3.4.Final]
> at org.hibernate.engine.spi.ActionQueue.executeActions(ActionQueue.java:461) [hibernate-core-4.3.4.Final.jar:4.3.4.Final]
> at org.hibernate.engine.spi.ActionQueue.executeActions(ActionQueue.java:347) [hibernate-core-4.3.4.Final.jar:4.3.4.Final]
> at org.hibernate.event.internal.AbstractFlushingEventListener.performExecutions(AbstractFlushingEventListener.java:350) [hibernate-core-4.3.4.Final.j
> ar:4.3.4.Final]
> at org.hibernate.event.internal.DefaultFlushEventListener.onFlush(DefaultFlushEventListener.java:56) [hibernate-core-4.3.4.Final.jar:4.3.4.Final]
> at org.hibernate.internal.SessionImpl.flush(SessionImpl.java:1222) [hibernate-core-4.3.4.Final.jar:4.3.4.Final]
> at org.hibernate.internal.SessionImpl.managedFlush(SessionImpl.java:425) [hibernate-core-4.3.4.Final.jar:4.3.4.Final]
> at org.hibernate.engine.transaction.synchronization.internal.SynchronizationCallbackCoordinatorNonTrackingImpl.beforeCompletion(SynchronizationCallba
> ckCoordinatorNonTrackingImpl.java:110) [hibernate-core-4.3.4.Final.jar:4.3.4.Final]
> ... 117 more
> Caused by: SuspectedException
> at org.jgroups.blocks.MessageDispatcher.sendMessage(MessageDispatcher.java:406)
> at org.infinispan.remoting.transport.jgroups.CommandAwareRpcDispatcher.processSingleCall(CommandAwareRpcDispatcher.java:353) [infinispan-core-6.0.1.F
> inal.jar:6.0.1.Final]
> at org.infinispan.remoting.transport.jgroups.CommandAwareRpcDispatcher.invokeRemoteCommand(CommandAwareRpcDispatcher.java:167) [infinispan-core-6.0.1
> .Final.jar:6.0.1.Final]
> ... 161 more
> 2014-04-15 17:40:53,707 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (Incoming-7,shared=udp) ISPN000094: Received new cluster view: [node1:rest1-even/hibernate-even|2] (1) [node1:rest1-even/hibernate-even]
> 2014-04-15 17:40:53,707 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (Incoming-14,shared=udp) ISPN000094: Received new cluster view: [node1:rest1-even/application-even|2] (1) [node1:rest1-even/application-even]
> Node 2 says:
> -----------------
> 2014-04-15 17:40:17,934 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (Incoming-19,shared=udp) ISPN000094: Received new cluster view: [node2:rest2-even/hibernate-even|2] (1) [node2:rest2-even/hibernate-even]
> 2014-04-15 17:40:17,934 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (Incoming-17,shared=udp) ISPN000094: Received new cluster view: [node2:rest2-even/application-even|2] (1) [node2:rest2-even/application-even]
> ...
> ...
> 2014-04-15 17:40:50,737 WARN [org.jgroups.protocols.UDP] (Timer-2,shared=udp) JGRP000032: null: no physical address for node1:rest1-even/hibernate-even, dropping message
> 2014-04-15 17:40:52,543 WARN [org.jgroups.protocols.UDP] (Timer-5,shared=udp) JGRP000032: null: no physical address for node1:rest1-even/application-even, dropping message
> (repeats 100 times)
> ...
> Is there any way I can get more logging than the WARNs above? Does anyone have pointers how or when this SuspectException is thrown?
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 5 months
[JBoss JIRA] (ISPN-6753) Ignore cache not found on remote when using invalidation caches
by Dan Berindei (JIRA)
[ https://issues.jboss.org/browse/ISPN-6753?page=com.atlassian.jira.plugin.... ]
Dan Berindei resolved ISPN-6753.
--------------------------------
Resolution: Duplicate Issue
Duplicate of ISPN-6721. Ignoring {{SuspectException}} and {{CacheNotFoundResponse}} should be the default since 8.2.2.Final, so there's no need for a new option.
> Ignore cache not found on remote when using invalidation caches
> ---------------------------------------------------------------
>
> Key: ISPN-6753
> URL: https://issues.jboss.org/browse/ISPN-6753
> Project: Infinispan
> Issue Type: Enhancement
> Components: Core
> Affects Versions: 8.2.2.Final
> Reporter: Karl von Randow
>
> We are using Infinispan as a 2LC for Hibernate. Cache regions are dynamically created, named for Hibernate entities. They clone the {{entity}} cache configuration and create new regions. This works great.
> We have a cluster of five application servers, each running the same stack and participating in the invalidation cluster.
> When we roll out a new version across our application servers we sometimes add, remove or rename entities. If we've removed an entity this causes that cache to not exist on the newly updated application server. This causes the other application servers, not yet updated, to try to send invalidation messages to the new one and when they discover that the cache isn't running they throw a {{SuspectException}} and start to fail.
> In {{AbstractTransport}} there is an option to ignore the {{CacheNotFoundResponse}}. That does not appear to be set in my case. I haven't found a configuration option to have this set. With apologies if it is already available: Would it be possible to add an option to ignore the cache not found responses?
> If it is something that should be added I am happy to attempt to supply a PR.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 5 months
[JBoss JIRA] (ISPN-6721) SuspectException when stopping and starting nodes in an embedded cluster using invalidation
by Dan Berindei (JIRA)
[ https://issues.jboss.org/browse/ISPN-6721?page=com.atlassian.jira.plugin.... ]
Dan Berindei updated ISPN-6721:
-------------------------------
Attachment: SyncInvalidationLeaveTest.java
> SuspectException when stopping and starting nodes in an embedded cluster using invalidation
> -------------------------------------------------------------------------------------------
>
> Key: ISPN-6721
> URL: https://issues.jboss.org/browse/ISPN-6721
> Project: Infinispan
> Issue Type: Bug
> Components: Core
> Affects Versions: 8.2.2.Final
> Reporter: Karl von Randow
> Attachments: SyncInvalidationLeaveTest.java
>
>
> We run a cluster of four app servers on Tomcat with embedded Infinispan for Hibernate L2. When we bring down one of the app servers it shuts down that cache and then exits. On other nodes we frequently, although not consistently, receive SuspectExceptions from other nodes stating that the cache isn't running on the shutting down node. Similarly when starting a new app server we get the same.
> We are using synchronous invalidation.
> This feels like a race condition during startup and shutdown of the caches. Does that sound likely?
> I note in this wiki article https://github.com/infinispan/infinispan/wiki/Consistency-guarantees-in-I... there is a note "TODO Create an issue in JIRA to ignore suspect exceptions.". I'm not sure if this is related!
> There are two stacktraces below. I note that the shutdown example fails in {{JGroupsTransport.java:798}} which is when the response was suspected. While the startup example fails in {{JGroupsTransport.java:795}}, which is a {{CacheNotFoundResponse}} response.
> Here is a shutdown exception:
> {code:java}
> May 27, 2016 3:05:01 PM org.apache.catalina.core.StandardWrapperValve invoke
> SEVERE: Servlet.service() for servlet [default] in context with path [] threw exception
> org.infinispan.remoting.transport.jgroups.SuspectException: Cache not running on node app1-12786
> at org.infinispan.remoting.transport.AbstractTransport.checkResponse(AbstractTransport.java:46)
> at org.infinispan.remoting.transport.jgroups.JGroupsTransport.checkRsp(JGroupsTransport.java:798)
> 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.RspListFuture.futureDone(RspListFuture.java:31)
> at org.jgroups.blocks.Request.checkCompletion(Request.java:162)
> at org.jgroups.blocks.GroupRequest.viewChange(GroupRequest.java:250)
> at org.jgroups.blocks.RequestCorrelator.receiveView(RequestCorrelator.java:316)
> at org.jgroups.blocks.RequestCorrelator.receive(RequestCorrelator.java:229)
> at org.jgroups.blocks.MessageDispatcher$ProtocolAdapter.up(MessageDispatcher.java:695)
> at org.jgroups.JChannel.up(JChannel.java:738)
> at org.jgroups.stack.ProtocolStack.up(ProtocolStack.java:1030)
> at org.jgroups.protocols.FRAG2.up(FRAG2.java:165)
> at org.jgroups.protocols.FlowControl.up(FlowControl.java:392)
> at org.jgroups.protocols.pbcast.GMS.installView(GMS.java:733)
> at org.jgroups.protocols.pbcast.ParticipantGmsImpl.handleViewChange(ParticipantGmsImpl.java:140)
> at org.jgroups.protocols.pbcast.GMS.up(GMS.java:923)
> at org.jgroups.stack.Protocol.up(Protocol.java:417)
> at org.jgroups.protocols.pbcast.STABLE.up(STABLE.java:294)
> at org.jgroups.protocols.UNICAST3.up(UNICAST3.java:474)
> at org.jgroups.protocols.pbcast.NAKACK2.deliverBatch(NAKACK2.java:982)
> at org.jgroups.protocols.pbcast.NAKACK2.removeAndPassUp(NAKACK2.java:912)
> at org.jgroups.protocols.pbcast.NAKACK2.handleMessage(NAKACK2.java:846)
> at org.jgroups.protocols.pbcast.NAKACK2.up(NAKACK2.java:618)
> at org.jgroups.protocols.VERIFY_SUSPECT.up(VERIFY_SUSPECT.java:155)
> at org.jgroups.protocols.FD_ALL.up(FD_ALL.java:200)
> at org.jgroups.protocols.FD_SOCK.up(FD_SOCK.java:310)
> at org.jgroups.protocols.MERGE3.up(MERGE3.java:285)
> at org.jgroups.protocols.Discovery.up(Discovery.java:296)
> at org.jgroups.protocols.TP.passMessageUp(TP.java:1590)
> at org.jgroups.protocols.TP$SingleMessageHandler.run(TP.java:1802)
> 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)
> {code}
> And a startup exception:
> {code:java}
> org.infinispan.remoting.transport.jgroups.SuspectException: Cache not running on node app1-46933
> at org.infinispan.remoting.transport.AbstractTransport.checkResponse(AbstractTransport.java:46)
> at org.infinispan.remoting.transport.jgroups.JGroupsTransport.checkRsp(JGroupsTransport.java:795)
> 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.RspListFuture.futureDone(RspListFuture.java:31)
> at org.jgroups.blocks.Request.checkCompletion(Request.java:162)
> at org.jgroups.blocks.GroupRequest.receiveResponse(GroupRequest.java:136)
> at org.jgroups.blocks.RequestCorrelator.receiveMessage(RequestCorrelator.java:373)
> at org.jgroups.blocks.RequestCorrelator.receive(RequestCorrelator.java:237)
> at org.jgroups.blocks.MessageDispatcher$ProtocolAdapter.up(MessageDispatcher.java:695)
> at org.jgroups.JChannel.up(JChannel.java:738)
> at org.jgroups.stack.ProtocolStack.up(ProtocolStack.java:1030)
> at org.jgroups.protocols.FRAG2.up(FRAG2.java:165)
> at org.jgroups.protocols.FlowControl.up(FlowControl.java:392)
> at org.jgroups.protocols.pbcast.GMS.up(GMS.java:1043)
> at org.jgroups.protocols.pbcast.STABLE.up(STABLE.java:234)
> at org.jgroups.protocols.UNICAST3.deliverMessage(UNICAST3.java:1064)
> at org.jgroups.protocols.UNICAST3.handleDataReceived(UNICAST3.java:779)
> at org.jgroups.protocols.UNICAST3.up(UNICAST3.java:426)
> at org.jgroups.protocols.pbcast.NAKACK2.up(NAKACK2.java:652)
> at org.jgroups.protocols.VERIFY_SUSPECT.up(VERIFY_SUSPECT.java:155)
> at org.jgroups.protocols.FD_ALL.up(FD_ALL.java:200)
> at org.jgroups.protocols.FD_SOCK.up(FD_SOCK.java:310)
> at org.jgroups.protocols.MERGE3.up(MERGE3.java:285)
> at org.jgroups.protocols.Discovery.up(Discovery.java:296)
> at org.jgroups.protocols.TP.passMessageUp(TP.java:1590)
> at org.jgroups.protocols.TP$SingleMessageHandler.run(TP.java:1802)
> 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)
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 5 months
[JBoss JIRA] (ISPN-6721) SuspectException when stopping and starting nodes in an embedded cluster using invalidation
by Dan Berindei (JIRA)
[ https://issues.jboss.org/browse/ISPN-6721?page=com.atlassian.jira.plugin.... ]
Dan Berindei commented on ISPN-6721:
------------------------------------
[~karlvr] yes, the TODO in the consistency guarantees document is definitely related. However, the {{SuspectException}} should never appear in 8.2.2.Final because a fix for it was included in the ISPN-6599 pull request (https://github.com/infinispan/infinispan/pull/4351).
Can you reproduce this with 8.2.4.Final, with TRACE logging enabled for org.infinispan? It would be even better if you could modify the attached test so that it fails.
> SuspectException when stopping and starting nodes in an embedded cluster using invalidation
> -------------------------------------------------------------------------------------------
>
> Key: ISPN-6721
> URL: https://issues.jboss.org/browse/ISPN-6721
> Project: Infinispan
> Issue Type: Bug
> Components: Core
> Affects Versions: 8.2.2.Final
> Reporter: Karl von Randow
>
> We run a cluster of four app servers on Tomcat with embedded Infinispan for Hibernate L2. When we bring down one of the app servers it shuts down that cache and then exits. On other nodes we frequently, although not consistently, receive SuspectExceptions from other nodes stating that the cache isn't running on the shutting down node. Similarly when starting a new app server we get the same.
> We are using synchronous invalidation.
> This feels like a race condition during startup and shutdown of the caches. Does that sound likely?
> I note in this wiki article https://github.com/infinispan/infinispan/wiki/Consistency-guarantees-in-I... there is a note "TODO Create an issue in JIRA to ignore suspect exceptions.". I'm not sure if this is related!
> There are two stacktraces below. I note that the shutdown example fails in {{JGroupsTransport.java:798}} which is when the response was suspected. While the startup example fails in {{JGroupsTransport.java:795}}, which is a {{CacheNotFoundResponse}} response.
> Here is a shutdown exception:
> {code:java}
> May 27, 2016 3:05:01 PM org.apache.catalina.core.StandardWrapperValve invoke
> SEVERE: Servlet.service() for servlet [default] in context with path [] threw exception
> org.infinispan.remoting.transport.jgroups.SuspectException: Cache not running on node app1-12786
> at org.infinispan.remoting.transport.AbstractTransport.checkResponse(AbstractTransport.java:46)
> at org.infinispan.remoting.transport.jgroups.JGroupsTransport.checkRsp(JGroupsTransport.java:798)
> 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.RspListFuture.futureDone(RspListFuture.java:31)
> at org.jgroups.blocks.Request.checkCompletion(Request.java:162)
> at org.jgroups.blocks.GroupRequest.viewChange(GroupRequest.java:250)
> at org.jgroups.blocks.RequestCorrelator.receiveView(RequestCorrelator.java:316)
> at org.jgroups.blocks.RequestCorrelator.receive(RequestCorrelator.java:229)
> at org.jgroups.blocks.MessageDispatcher$ProtocolAdapter.up(MessageDispatcher.java:695)
> at org.jgroups.JChannel.up(JChannel.java:738)
> at org.jgroups.stack.ProtocolStack.up(ProtocolStack.java:1030)
> at org.jgroups.protocols.FRAG2.up(FRAG2.java:165)
> at org.jgroups.protocols.FlowControl.up(FlowControl.java:392)
> at org.jgroups.protocols.pbcast.GMS.installView(GMS.java:733)
> at org.jgroups.protocols.pbcast.ParticipantGmsImpl.handleViewChange(ParticipantGmsImpl.java:140)
> at org.jgroups.protocols.pbcast.GMS.up(GMS.java:923)
> at org.jgroups.stack.Protocol.up(Protocol.java:417)
> at org.jgroups.protocols.pbcast.STABLE.up(STABLE.java:294)
> at org.jgroups.protocols.UNICAST3.up(UNICAST3.java:474)
> at org.jgroups.protocols.pbcast.NAKACK2.deliverBatch(NAKACK2.java:982)
> at org.jgroups.protocols.pbcast.NAKACK2.removeAndPassUp(NAKACK2.java:912)
> at org.jgroups.protocols.pbcast.NAKACK2.handleMessage(NAKACK2.java:846)
> at org.jgroups.protocols.pbcast.NAKACK2.up(NAKACK2.java:618)
> at org.jgroups.protocols.VERIFY_SUSPECT.up(VERIFY_SUSPECT.java:155)
> at org.jgroups.protocols.FD_ALL.up(FD_ALL.java:200)
> at org.jgroups.protocols.FD_SOCK.up(FD_SOCK.java:310)
> at org.jgroups.protocols.MERGE3.up(MERGE3.java:285)
> at org.jgroups.protocols.Discovery.up(Discovery.java:296)
> at org.jgroups.protocols.TP.passMessageUp(TP.java:1590)
> at org.jgroups.protocols.TP$SingleMessageHandler.run(TP.java:1802)
> 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)
> {code}
> And a startup exception:
> {code:java}
> org.infinispan.remoting.transport.jgroups.SuspectException: Cache not running on node app1-46933
> at org.infinispan.remoting.transport.AbstractTransport.checkResponse(AbstractTransport.java:46)
> at org.infinispan.remoting.transport.jgroups.JGroupsTransport.checkRsp(JGroupsTransport.java:795)
> 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.RspListFuture.futureDone(RspListFuture.java:31)
> at org.jgroups.blocks.Request.checkCompletion(Request.java:162)
> at org.jgroups.blocks.GroupRequest.receiveResponse(GroupRequest.java:136)
> at org.jgroups.blocks.RequestCorrelator.receiveMessage(RequestCorrelator.java:373)
> at org.jgroups.blocks.RequestCorrelator.receive(RequestCorrelator.java:237)
> at org.jgroups.blocks.MessageDispatcher$ProtocolAdapter.up(MessageDispatcher.java:695)
> at org.jgroups.JChannel.up(JChannel.java:738)
> at org.jgroups.stack.ProtocolStack.up(ProtocolStack.java:1030)
> at org.jgroups.protocols.FRAG2.up(FRAG2.java:165)
> at org.jgroups.protocols.FlowControl.up(FlowControl.java:392)
> at org.jgroups.protocols.pbcast.GMS.up(GMS.java:1043)
> at org.jgroups.protocols.pbcast.STABLE.up(STABLE.java:234)
> at org.jgroups.protocols.UNICAST3.deliverMessage(UNICAST3.java:1064)
> at org.jgroups.protocols.UNICAST3.handleDataReceived(UNICAST3.java:779)
> at org.jgroups.protocols.UNICAST3.up(UNICAST3.java:426)
> at org.jgroups.protocols.pbcast.NAKACK2.up(NAKACK2.java:652)
> at org.jgroups.protocols.VERIFY_SUSPECT.up(VERIFY_SUSPECT.java:155)
> at org.jgroups.protocols.FD_ALL.up(FD_ALL.java:200)
> at org.jgroups.protocols.FD_SOCK.up(FD_SOCK.java:310)
> at org.jgroups.protocols.MERGE3.up(MERGE3.java:285)
> at org.jgroups.protocols.Discovery.up(Discovery.java:296)
> at org.jgroups.protocols.TP.passMessageUp(TP.java:1590)
> at org.jgroups.protocols.TP$SingleMessageHandler.run(TP.java:1802)
> 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)
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 5 months
[JBoss JIRA] (ISPN-7137) Rest logging NumberFormatException
by Galder Zamarreño (JIRA)
Galder Zamarreño created ISPN-7137:
--------------------------------------
Summary: Rest logging NumberFormatException
Key: ISPN-7137
URL: https://issues.jboss.org/browse/ISPN-7137
Project: Infinispan
Issue Type: Bug
Affects Versions: 9.0.0.Alpha4
Reporter: Galder Zamarreño
Assignee: William Burns
When starting 9.0.0.Alpha4 on domain mode, I see this error:
{code}
[Server:server-one] 09:20:27,504 SEVERE [org.jboss.resteasy.plugins.server.netty.RequestHandler] (nioEventLoopGroup-6-1) Unexpected: org.jboss.resteasy.spi.UnhandledException: java.lang.NumberFormatException: null
[Server:server-one] at org.jboss.resteasy.core.SynchronousDispatcher.writeException(SynchronousDispatcher.java:187)
[Server:server-one] at org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:206)
[Server:server-one] at org.jboss.resteasy.plugins.server.netty.RequestDispatcher.service(RequestDispatcher.java:83)
[Server:server-one] at org.jboss.resteasy.plugins.server.netty.RequestHandler.channelRead0(RequestHandler.java:53)
[Server:server-one] at io.netty.channel.SimpleChannelInboundHandler.channelRead(SimpleChannelInboundHandler.java:105)
[Server:server-one] at io.netty.channel.ChannelHandlerInvokerUtil.invokeChannelReadNow(ChannelHandlerInvokerUtil.java:83)
[Server:server-one] at io.netty.channel.DefaultChannelHandlerInvoker$7.run(DefaultChannelHandlerInvoker.java:159)
[Server:server-one] at io.netty.util.concurrent.SingleThreadEventExecutor.runAllTasks(SingleThreadEventExecutor.java:339)
[Server:server-one] at io.netty.channel.nio.NioEventLoop.run(NioEventLoop.java:373)
[Server:server-one] at io.netty.util.concurrent.SingleThreadEventExecutor$5.run(SingleThreadEventExecutor.java:742)
[Server:server-one] at io.netty.util.concurrent.DefaultThreadFactory$DefaultRunnableDecorator.run(DefaultThreadFactory.java:145)
[Server:server-one] at java.lang.Thread.run(Thread.java:745)
[Server:server-one] Caused by: java.lang.NumberFormatException: null
[Server:server-one] at java.lang.Long.parseLong(Long.java:552)
[Server:server-one] at java.lang.Long.parseLong(Long.java:631)
[Server:server-one] at org.infinispan.rest.logging.RestAccessLoggingHandler.filter(RestAccessLoggingHandler.java:36)
[Server:server-one] at org.jboss.resteasy.core.ServerResponseWriter.executeFilters(ServerResponseWriter.java:121)
[Server:server-one] at org.jboss.resteasy.core.ServerResponseWriter.writeNomapResponse(ServerResponseWriter.java:48)
[Server:server-one] at org.jboss.resteasy.core.SynchronousDispatcher.writeException(SynchronousDispatcher.java:183)
[Server:server-one] ... 11 more
{code}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 5 months
[JBoss JIRA] (ISPN-7137) Rest logging NumberFormatException
by Galder Zamarreño (JIRA)
[ https://issues.jboss.org/browse/ISPN-7137?page=com.atlassian.jira.plugin.... ]
Galder Zamarreño updated ISPN-7137:
-----------------------------------
Component/s: Remote Protocols
> Rest logging NumberFormatException
> ----------------------------------
>
> Key: ISPN-7137
> URL: https://issues.jboss.org/browse/ISPN-7137
> Project: Infinispan
> Issue Type: Bug
> Components: Remote Protocols
> Affects Versions: 9.0.0.Alpha4
> Reporter: Galder Zamarreño
> Assignee: William Burns
>
> When starting 9.0.0.Alpha4 on domain mode, I see this error:
> {code}
> [Server:server-one] 09:20:27,504 SEVERE [org.jboss.resteasy.plugins.server.netty.RequestHandler] (nioEventLoopGroup-6-1) Unexpected: org.jboss.resteasy.spi.UnhandledException: java.lang.NumberFormatException: null
> [Server:server-one] at org.jboss.resteasy.core.SynchronousDispatcher.writeException(SynchronousDispatcher.java:187)
> [Server:server-one] at org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:206)
> [Server:server-one] at org.jboss.resteasy.plugins.server.netty.RequestDispatcher.service(RequestDispatcher.java:83)
> [Server:server-one] at org.jboss.resteasy.plugins.server.netty.RequestHandler.channelRead0(RequestHandler.java:53)
> [Server:server-one] at io.netty.channel.SimpleChannelInboundHandler.channelRead(SimpleChannelInboundHandler.java:105)
> [Server:server-one] at io.netty.channel.ChannelHandlerInvokerUtil.invokeChannelReadNow(ChannelHandlerInvokerUtil.java:83)
> [Server:server-one] at io.netty.channel.DefaultChannelHandlerInvoker$7.run(DefaultChannelHandlerInvoker.java:159)
> [Server:server-one] at io.netty.util.concurrent.SingleThreadEventExecutor.runAllTasks(SingleThreadEventExecutor.java:339)
> [Server:server-one] at io.netty.channel.nio.NioEventLoop.run(NioEventLoop.java:373)
> [Server:server-one] at io.netty.util.concurrent.SingleThreadEventExecutor$5.run(SingleThreadEventExecutor.java:742)
> [Server:server-one] at io.netty.util.concurrent.DefaultThreadFactory$DefaultRunnableDecorator.run(DefaultThreadFactory.java:145)
> [Server:server-one] at java.lang.Thread.run(Thread.java:745)
> [Server:server-one] Caused by: java.lang.NumberFormatException: null
> [Server:server-one] at java.lang.Long.parseLong(Long.java:552)
> [Server:server-one] at java.lang.Long.parseLong(Long.java:631)
> [Server:server-one] at org.infinispan.rest.logging.RestAccessLoggingHandler.filter(RestAccessLoggingHandler.java:36)
> [Server:server-one] at org.jboss.resteasy.core.ServerResponseWriter.executeFilters(ServerResponseWriter.java:121)
> [Server:server-one] at org.jboss.resteasy.core.ServerResponseWriter.writeNomapResponse(ServerResponseWriter.java:48)
> [Server:server-one] at org.jboss.resteasy.core.SynchronousDispatcher.writeException(SynchronousDispatcher.java:183)
> [Server:server-one] ... 11 more
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 5 months
[JBoss JIRA] (ISPN-7116) Test methods that use a TestNg dataProvider are duplicated in JUnit reports
by Alan Field (JIRA)
[ https://issues.jboss.org/browse/ISPN-7116?page=com.atlassian.jira.plugin.... ]
Alan Field edited comment on ISPN-7116 at 10/24/16 3:50 PM:
------------------------------------------------------------
Hey [~dan.berindei], thanks for the detailed pointer! I'll work on this and send a PR when I can get both of the reporters to work!
Actually, I have already tried to get `org.infinispan.commons.test.TestNGTestListener.testName()` working without luck. At least I was trying to tweak the right method! :-)
was (Author: afield):
Hey [~dan.berindei], thanks for the detailed pointer! I'll work on this and send a PR when I can get both of the reporters to work!
> Test methods that use a TestNg dataProvider are duplicated in JUnit reports
> ---------------------------------------------------------------------------
>
> Key: ISPN-7116
> URL: https://issues.jboss.org/browse/ISPN-7116
> Project: Infinispan
> Issue Type: Enhancement
> Components: Test Suite - Core
> Reporter: Alan Field
> Assignee: Alan Field
>
> TestNg test methods that use a {{dataProvider}} are reported as multiple duplicate test cases in the surefire results reports:
> {noformat}
> <testcase name="testDistExecPutGet" classname="org.infinispan.client.hotrod.ExecTest" time="0.424"/>
> <testcase name="testDistExecPutGet" classname="org.infinispan.client.hotrod.ExecTest" time="0.015"/>
> <testcase name="testEmbeddedScriptRemoteExecution" classname="org.infinispan.client.hotrod.ExecTest" time="0.132"/>
> <testcase name="testEmbeddedScriptRemoteExecution" classname="org.infinispan.client.hotrod.ExecTest" time="0.086"/>
> <testcase name="testExecPutConstantGet" classname="org.infinispan.client.hotrod.ExecTest" time="0.016"/>
> <testcase name="testExecPutConstantGet" classname="org.infinispan.client.hotrod.ExecTest" time="0.009"/>
> <testcase name="testExecReturnNull" classname="org.infinispan.client.hotrod.ExecTest" time="0.015"/>
> <testcase name="testExecReturnNull" classname="org.infinispan.client.hotrod.ExecTest" time="0.008"/>
> <testcase name="testLocalExecPutGet" classname="org.infinispan.client.hotrod.ExecTest" time="0.022"/>
> <testcase name="testLocalExecPutGet" classname="org.infinispan.client.hotrod.ExecTest" time="0.013"/>
> <testcase name="testLocalExecPutGetWithListener" classname="org.infinispan.client.hotrod.ExecTest" time="0.037"/>
> <testcase name="testLocalExecPutGetWithListener" classname="org.infinispan.client.hotrod.ExecTest" time="0.025"/>
> <testcase name="testRemoteScriptRemoteExecution" classname="org.infinispan.client.hotrod.ExecTest" time="0.074"/>
> <testcase name="testRemoteScriptRemoteExecution" classname="org.infinispan.client.hotrod.ExecTest" time="0.06"/>
> <testcase name="testRemovingNonExistentScript" classname="org.infinispan.client.hotrod.ExecTest" time="0.002"/>
> {noformat}
> The {{name}} property should include the parameters passed to the method to differentiate the results.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 5 months
[JBoss JIRA] (ISPN-7116) Test methods that use a TestNg dataProvider are duplicated in JUnit reports
by Alan Field (JIRA)
[ https://issues.jboss.org/browse/ISPN-7116?page=com.atlassian.jira.plugin.... ]
Alan Field edited comment on ISPN-7116 at 10/24/16 3:50 PM:
------------------------------------------------------------
Hey [~dan.berindei], thanks for the detailed pointer! I'll work on this and send a PR when I can get both of the reporters to work!
Actually, I have already tried to get {{org.infinispan.commons.test.TestNGTestListener.testName()}} working without luck. At least I was trying to tweak the right method! :-)
was (Author: afield):
Hey [~dan.berindei], thanks for the detailed pointer! I'll work on this and send a PR when I can get both of the reporters to work!
Actually, I have already tried to get `org.infinispan.commons.test.TestNGTestListener.testName()` working without luck. At least I was trying to tweak the right method! :-)
> Test methods that use a TestNg dataProvider are duplicated in JUnit reports
> ---------------------------------------------------------------------------
>
> Key: ISPN-7116
> URL: https://issues.jboss.org/browse/ISPN-7116
> Project: Infinispan
> Issue Type: Enhancement
> Components: Test Suite - Core
> Reporter: Alan Field
> Assignee: Alan Field
>
> TestNg test methods that use a {{dataProvider}} are reported as multiple duplicate test cases in the surefire results reports:
> {noformat}
> <testcase name="testDistExecPutGet" classname="org.infinispan.client.hotrod.ExecTest" time="0.424"/>
> <testcase name="testDistExecPutGet" classname="org.infinispan.client.hotrod.ExecTest" time="0.015"/>
> <testcase name="testEmbeddedScriptRemoteExecution" classname="org.infinispan.client.hotrod.ExecTest" time="0.132"/>
> <testcase name="testEmbeddedScriptRemoteExecution" classname="org.infinispan.client.hotrod.ExecTest" time="0.086"/>
> <testcase name="testExecPutConstantGet" classname="org.infinispan.client.hotrod.ExecTest" time="0.016"/>
> <testcase name="testExecPutConstantGet" classname="org.infinispan.client.hotrod.ExecTest" time="0.009"/>
> <testcase name="testExecReturnNull" classname="org.infinispan.client.hotrod.ExecTest" time="0.015"/>
> <testcase name="testExecReturnNull" classname="org.infinispan.client.hotrod.ExecTest" time="0.008"/>
> <testcase name="testLocalExecPutGet" classname="org.infinispan.client.hotrod.ExecTest" time="0.022"/>
> <testcase name="testLocalExecPutGet" classname="org.infinispan.client.hotrod.ExecTest" time="0.013"/>
> <testcase name="testLocalExecPutGetWithListener" classname="org.infinispan.client.hotrod.ExecTest" time="0.037"/>
> <testcase name="testLocalExecPutGetWithListener" classname="org.infinispan.client.hotrod.ExecTest" time="0.025"/>
> <testcase name="testRemoteScriptRemoteExecution" classname="org.infinispan.client.hotrod.ExecTest" time="0.074"/>
> <testcase name="testRemoteScriptRemoteExecution" classname="org.infinispan.client.hotrod.ExecTest" time="0.06"/>
> <testcase name="testRemovingNonExistentScript" classname="org.infinispan.client.hotrod.ExecTest" time="0.002"/>
> {noformat}
> The {{name}} property should include the parameters passed to the method to differentiate the results.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 5 months
[JBoss JIRA] (ISPN-7116) Test methods that use a TestNg dataProvider are duplicated in JUnit reports
by Alan Field (JIRA)
[ https://issues.jboss.org/browse/ISPN-7116?page=com.atlassian.jira.plugin.... ]
Alan Field commented on ISPN-7116:
----------------------------------
Hey [~dan.berindei], thanks for the detailed pointer! I'll work on this and send a PR when I can get both of the reporters to work!
> Test methods that use a TestNg dataProvider are duplicated in JUnit reports
> ---------------------------------------------------------------------------
>
> Key: ISPN-7116
> URL: https://issues.jboss.org/browse/ISPN-7116
> Project: Infinispan
> Issue Type: Enhancement
> Components: Test Suite - Core
> Reporter: Alan Field
> Assignee: Alan Field
>
> TestNg test methods that use a {{dataProvider}} are reported as multiple duplicate test cases in the surefire results reports:
> {noformat}
> <testcase name="testDistExecPutGet" classname="org.infinispan.client.hotrod.ExecTest" time="0.424"/>
> <testcase name="testDistExecPutGet" classname="org.infinispan.client.hotrod.ExecTest" time="0.015"/>
> <testcase name="testEmbeddedScriptRemoteExecution" classname="org.infinispan.client.hotrod.ExecTest" time="0.132"/>
> <testcase name="testEmbeddedScriptRemoteExecution" classname="org.infinispan.client.hotrod.ExecTest" time="0.086"/>
> <testcase name="testExecPutConstantGet" classname="org.infinispan.client.hotrod.ExecTest" time="0.016"/>
> <testcase name="testExecPutConstantGet" classname="org.infinispan.client.hotrod.ExecTest" time="0.009"/>
> <testcase name="testExecReturnNull" classname="org.infinispan.client.hotrod.ExecTest" time="0.015"/>
> <testcase name="testExecReturnNull" classname="org.infinispan.client.hotrod.ExecTest" time="0.008"/>
> <testcase name="testLocalExecPutGet" classname="org.infinispan.client.hotrod.ExecTest" time="0.022"/>
> <testcase name="testLocalExecPutGet" classname="org.infinispan.client.hotrod.ExecTest" time="0.013"/>
> <testcase name="testLocalExecPutGetWithListener" classname="org.infinispan.client.hotrod.ExecTest" time="0.037"/>
> <testcase name="testLocalExecPutGetWithListener" classname="org.infinispan.client.hotrod.ExecTest" time="0.025"/>
> <testcase name="testRemoteScriptRemoteExecution" classname="org.infinispan.client.hotrod.ExecTest" time="0.074"/>
> <testcase name="testRemoteScriptRemoteExecution" classname="org.infinispan.client.hotrod.ExecTest" time="0.06"/>
> <testcase name="testRemovingNonExistentScript" classname="org.infinispan.client.hotrod.ExecTest" time="0.002"/>
> {noformat}
> The {{name}} property should include the parameters passed to the method to differentiate the results.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 5 months