[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)
7 years, 6 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)
7 years, 6 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)
7 years, 6 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)
7 years, 6 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)
7 years, 6 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)
7 years, 6 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)
7 years, 6 months
[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)
7 years, 6 months
[JBoss JIRA] (ISPN-7129) Duplicate cache names shouldn't be allowed
by Jakub Markos (JIRA)
[ https://issues.jboss.org/browse/ISPN-7129?page=com.atlassian.jira.plugin.... ]
Jakub Markos updated ISPN-7129:
-------------------------------
Description:
Multiple caches with the same name can be defined without a WARN/ERROR message.
It's also unclear which one will be used, for example with this configuration
{code}
<distributed-cache name="testCache"/>
<distributed-cache name="testCache">
<eviction max-entries="100" />
</distributed-cache>
<distributed-cache name="testCache"/>
{code}
-the cache with eviction will be used.- Actually the configurations are merged...
was:
Multiple caches with the same name can be defined without a WARN/ERROR message.
It's also unclear which one will be used, for example with this configuration
{code}
<distributed-cache name="testCache"/>
<distributed-cache name="testCache">
<eviction max-entries="100" />
</distributed-cache>
<distributed-cache name="testCache"/>
{code}
the cache with eviction will be used.
> Duplicate cache names shouldn't be allowed
> ------------------------------------------
>
> Key: ISPN-7129
> URL: https://issues.jboss.org/browse/ISPN-7129
> Project: Infinispan
> Issue Type: Bug
> Components: Configuration
> Affects Versions: 9.0.0.Alpha2
> Reporter: Jakub Markos
>
> Multiple caches with the same name can be defined without a WARN/ERROR message.
> It's also unclear which one will be used, for example with this configuration
> {code}
> <distributed-cache name="testCache"/>
> <distributed-cache name="testCache">
> <eviction max-entries="100" />
> </distributed-cache>
> <distributed-cache name="testCache"/>
> {code}
> -the cache with eviction will be used.- Actually the configurations are merged...
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
7 years, 6 months