[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, 1 month
[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, 1 month
[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, 1 month
[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, 1 month
[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, 1 month
[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, 1 month
[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, 1 month
[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, 1 month
[JBoss JIRA] (ISPN-7116) Test methods that use a TestNg dataProvider are duplicated in JUnit reports
by Dan Berindei (JIRA)
[ https://issues.jboss.org/browse/ISPN-7116?page=com.atlassian.jira.plugin.... ]
Dan Berindei commented on ISPN-7116:
------------------------------------
[~afield] If you look at the {{org.testng.reporters.TestHTMLReporter}} code, it uses {{TestResult.getParameters()}} to log the {{DataProvider}} parameters, but {{org.testng.reporters.JUnitXMLReporter}} only uses {{TestResult.getMethod().getMethodName()}}. So I think it's just a missing feature in the JUnit reporter.
You can add {{org.testng.reporters.JUnitXMLReporter}} as a TestNG listener in the debug configuration and set a breakpoint in the reporter itself. You can also look around in the other listeners, like the reporter set up by IntelliJ :)
And if you start working on the JUnit reporter, it would be nice if you changed {{org.infinispan.commons.test.TestNGTestListener.testName()}} to include the {{DataProvider}} parameters as well :)
> 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, 1 month