[JBoss JIRA] (DROOLS-2373) BRL "is contained in the (comma separated) list" does not produce multiselect dropdown
by Michael Anstis (JIRA)
[ https://issues.jboss.org/browse/DROOLS-2373?page=com.atlassian.jira.plugi... ]
Michael Anstis commented on DROOLS-2373:
----------------------------------------
Sweet... OK, so the problem is when we extract Template Keys from the {{RuleModel}} we only store Fact and Field information; not Operator. Then when we use the Template Key information to build the {{BRLConditionVariableColumn}} we don't have the operator and hence it is always {{null}}. {{RuleModelVisitor}} needs enhancing, as does {{InterpolationVariable}} to hold an optional operator that can then be used by {{BRLConditionColumnPlugin#convertInterpolationVariables()}}.
> BRL "is contained in the (comma separated) list" does not produce multiselect dropdown
> --------------------------------------------------------------------------------------
>
> Key: DROOLS-2373
> URL: https://issues.jboss.org/browse/DROOLS-2373
> Project: Drools
> Issue Type: Bug
> Components: Guided Decision Table Editor, Guided Rule Editor
> Affects Versions: 7.6.0.Final
> Environment: Tomcat 8.5 / RHEL 7
> Reporter: Yannick Geerts
> Assignee: Michael Anstis
>
> Google groups link: https://groups.google.com/forum/#!topic/drools-usage/VElZ3KAZMIs
> *Edited*
> The problem is that in the piece of code below the expression {{column.getOperator()}} returns null.
> {{BRLConditionVariableColumnConverter#convertColumn}}
> {code:java}
> if (OperatorsOracle.operatorRequiresList(column.getOperator())) {
> return newMultipleSelectEnumColumn(factType,
> factField,
> column,
> access,
> gridWidget);
> } else {
> return newSingleSelectionEnumColumn(factType,
> factField,
> dataType,
> column,
> access,
> gridWidget);
> }
> {code}
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 2 months
[JBoss JIRA] (WFCORE-3676) LegacyResourceDefinition does not register override models correctly
by Paul Ferraro (JIRA)
Paul Ferraro created WFCORE-3676:
------------------------------------
Summary: LegacyResourceDefinition does not register override models correctly
Key: WFCORE-3676
URL: https://issues.jboss.org/browse/WFCORE-3676
Project: WildFly Core
Issue Type: Bug
Components: Domain Management
Affects Versions: 4.0.0.Final
Reporter: Paul Ferraro
Assignee: Paul Ferraro
The JGroups subsystem uses override registrations for certain protocols.
e.g.
/protocol=JDBC_PING
overrides
/protocol=*
And adds additional attributes, capabilities, etc.
When the subsystem test framework attempts to create LegacyResourceDefinitions for JDBC_PING, it thinks there are duplicates.
e.g.
{noformat}
java.lang.IllegalArgumentException: WFLYCTL0218: A node is already registered at '/channel=*/fork=*/protocol=*/property=*'
at org.jboss.as.controller.registry.ConcreteResourceRegistration.registerSubModel(ConcreteResourceRegistration.java:228)
at org.jboss.as.controller.registry.LegacyResourceDefinition.registerChildren(LegacyResourceDefinition.java:144)
at org.jboss.as.controller.registry.NodeSubregistry.registerChild(NodeSubregistry.java:111)
at org.jboss.as.controller.registry.ConcreteResourceRegistration.registerSubModel(ConcreteResourceRegistration.java:231)
at org.jboss.as.controller.registry.LegacyResourceDefinition.registerChildren(LegacyResourceDefinition.java:144)
at org.jboss.as.controller.registry.NodeSubregistry.registerChild(NodeSubregistry.java:111)
at org.jboss.as.controller.registry.ConcreteResourceRegistration.registerSubModel(ConcreteResourceRegistration.java:231)
at org.jboss.as.controller.registry.LegacyResourceDefinition.registerChildren(LegacyResourceDefinition.java:144)
at org.jboss.as.controller.registry.NodeSubregistry.registerChild(NodeSubregistry.java:111)
at org.jboss.as.controller.registry.ConcreteResourceRegistration.registerSubModel(ConcreteResourceRegistration.java:231)
at org.jboss.as.controller.registry.LegacyResourceDefinition.registerChildren(LegacyResourceDefinition.java:144)
at org.jboss.as.controller.registry.ManagementResourceRegistration$Factory.createRegistration(ManagementResourceRegistration.java:383)
at org.jboss.as.controller.registry.ManagementResourceRegistration$Factory.createRegistration(ManagementResourceRegistration.java:361)
at org.jboss.as.subsystem.test.SubsystemTestDelegate.checkSubsystemModelTransformation(SubsystemTestDelegate.java:435)
at org.jboss.as.subsystem.test.AbstractSubsystemTest.checkSubsystemModelTransformation(AbstractSubsystemTest.java:222)
at org.jboss.as.clustering.jgroups.subsystem.JGroupsTransformersTestCase.testTransformation(JGroupsTransformersTestCase.java:160)
at org.jboss.as.clustering.jgroups.subsystem.JGroupsTransformersTestCase.testTransformerEAP710(JGroupsTransformersTestCase.java:133)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
at org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
at org.junit.runners.Suite.runChild(Suite.java:128)
at org.junit.runners.Suite.runChild(Suite.java:27)
at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
at org.apache.maven.surefire.junitcore.JUnitCore.run(JUnitCore.java:55)
at org.apache.maven.surefire.junitcore.JUnitCoreWrapper.createRequestAndRun(JUnitCoreWrapper.java:137)
at org.apache.maven.surefire.junitcore.JUnitCoreWrapper.executeEager(JUnitCoreWrapper.java:107)
at org.apache.maven.surefire.junitcore.JUnitCoreWrapper.execute(JUnitCoreWrapper.java:83)
at org.apache.maven.surefire.junitcore.JUnitCoreWrapper.execute(JUnitCoreWrapper.java:75)
at org.apache.maven.surefire.junitcore.JUnitCoreProvider.invoke(JUnitCoreProvider.java:161)
at org.apache.maven.surefire.booter.ForkedBooter.invokeProviderInSameClassLoader(ForkedBooter.java:290)
at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:242)
at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:121)
{noformat}
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 2 months
[JBoss JIRA] (WFLY-9984) jaxws-retail fails to build with jdk-9
by R Searls (JIRA)
R Searls created WFLY-9984:
------------------------------
Summary: jaxws-retail fails to build with jdk-9
Key: WFLY-9984
URL: https://issues.jboss.org/browse/WFLY-9984
Project: WildFly
Issue Type: Bug
Components: Quickstarts
Affects Versions: 13.0.0.Beta1
Reporter: R Searls
Assignee: R Searls
When building jaxws-retail with jdk-9 the jaxws-tools-maven-plugin fails to run successfully.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 2 months
[JBoss JIRA] (LOGMGR-191) Amend NullPointerException in regex filters
by James Perkins (JIRA)
[ https://issues.jboss.org/browse/LOGMGR-191?page=com.atlassian.jira.plugin... ]
James Perkins reassigned LOGMGR-191:
------------------------------------
Assignee: James Perkins (was: Toshiya Kobayashi)
> Amend NullPointerException in regex filters
> -------------------------------------------
>
> Key: LOGMGR-191
> URL: https://issues.jboss.org/browse/LOGMGR-191
> Project: JBoss Log Manager
> Issue Type: Bug
> Components: core
> Affects Versions: 2.1.0.Alpha5
> Reporter: Toshiya Kobayashi
> Assignee: James Perkins
> Labels: support
> Fix For: 1.3.3.Final, 1.4.4.Final, 1.5.10.Final, 2.0.10.Final, 2.1.0.Alpha6
>
>
> When log message is null, RegexFilter.isLoggable() throws NullPointerException.
> https://github.com/jboss-logging/jboss-logmanager/blob/master/src/main/ja...
> It often results in unexpected outcomes. For example, assuming you have a filter-spec with "not(match(xxx))" to suppress some messages in your logger configuration:
> {code:xml}
> <subsystem xmlns="urn:jboss:domain:logging:3.0">
> <console-handler name="CONSOLE">
> <level name="INFO"/>
> <filter-spec value="not(match("SOME_MESSAGE"))"/>
> <formatter>
> <named-formatter name="COLOR-PATTERN"/>
> </formatter>
> </console-handler>
> {code}
> and an application has a code like this:
> {code:java}
> try {
> ...
> } catch (Exception e) {
> logger.error(e.getMessage(), e);
> }
> {code}
> "e.getMessage()" could be null. But you want to log the stacktrace 'e' anyway.
> In this case, NullPointerException is thrown from RegexFilter and reaches to LoggerNode and disappears. ConsoleHandler cannot publish the log at all.
> https://github.com/jboss-logging/jboss-logmanager/blob/master/src/main/ja...
> I think 'null' message should simply return 'false' in RegexFilter.isLoggable().
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 2 months
[JBoss JIRA] (LOGMGR-191) Amend NullPointerException in regex filters
by James Perkins (JIRA)
[ https://issues.jboss.org/browse/LOGMGR-191?page=com.atlassian.jira.plugin... ]
James Perkins updated LOGMGR-191:
---------------------------------
Fix Version/s: 1.3.3.Final
1.4.4.Final
1.5.10.Final
2.0.10.Final
2.1.0.Alpha6
> Amend NullPointerException in regex filters
> -------------------------------------------
>
> Key: LOGMGR-191
> URL: https://issues.jboss.org/browse/LOGMGR-191
> Project: JBoss Log Manager
> Issue Type: Bug
> Components: core
> Affects Versions: 2.1.0.Alpha5
> Reporter: Toshiya Kobayashi
> Assignee: James Perkins
> Labels: support
> Fix For: 1.3.3.Final, 1.4.4.Final, 1.5.10.Final, 2.0.10.Final, 2.1.0.Alpha6
>
>
> When log message is null, RegexFilter.isLoggable() throws NullPointerException.
> https://github.com/jboss-logging/jboss-logmanager/blob/master/src/main/ja...
> It often results in unexpected outcomes. For example, assuming you have a filter-spec with "not(match(xxx))" to suppress some messages in your logger configuration:
> {code:xml}
> <subsystem xmlns="urn:jboss:domain:logging:3.0">
> <console-handler name="CONSOLE">
> <level name="INFO"/>
> <filter-spec value="not(match("SOME_MESSAGE"))"/>
> <formatter>
> <named-formatter name="COLOR-PATTERN"/>
> </formatter>
> </console-handler>
> {code}
> and an application has a code like this:
> {code:java}
> try {
> ...
> } catch (Exception e) {
> logger.error(e.getMessage(), e);
> }
> {code}
> "e.getMessage()" could be null. But you want to log the stacktrace 'e' anyway.
> In this case, NullPointerException is thrown from RegexFilter and reaches to LoggerNode and disappears. ConsoleHandler cannot publish the log at all.
> https://github.com/jboss-logging/jboss-logmanager/blob/master/src/main/ja...
> I think 'null' message should simply return 'false' in RegexFilter.isLoggable().
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 2 months
[JBoss JIRA] (LOGMGR-191) Amend NullPointerException in regex filters
by James Perkins (JIRA)
[ https://issues.jboss.org/browse/LOGMGR-191?page=com.atlassian.jira.plugin... ]
James Perkins commented on LOGMGR-191:
--------------------------------------
This could also happen in the {{SubstituteFilter}}. I'm going to handle the PR a little differently so that it will handle {{null}} values.
> Amend NullPointerException in regex filters
> -------------------------------------------
>
> Key: LOGMGR-191
> URL: https://issues.jboss.org/browse/LOGMGR-191
> Project: JBoss Log Manager
> Issue Type: Bug
> Components: core
> Affects Versions: 2.1.0.Alpha5
> Reporter: Toshiya Kobayashi
> Assignee: Toshiya Kobayashi
> Labels: support
>
> When log message is null, RegexFilter.isLoggable() throws NullPointerException.
> https://github.com/jboss-logging/jboss-logmanager/blob/master/src/main/ja...
> It often results in unexpected outcomes. For example, assuming you have a filter-spec with "not(match(xxx))" to suppress some messages in your logger configuration:
> {code:xml}
> <subsystem xmlns="urn:jboss:domain:logging:3.0">
> <console-handler name="CONSOLE">
> <level name="INFO"/>
> <filter-spec value="not(match("SOME_MESSAGE"))"/>
> <formatter>
> <named-formatter name="COLOR-PATTERN"/>
> </formatter>
> </console-handler>
> {code}
> and an application has a code like this:
> {code:java}
> try {
> ...
> } catch (Exception e) {
> logger.error(e.getMessage(), e);
> }
> {code}
> "e.getMessage()" could be null. But you want to log the stacktrace 'e' anyway.
> In this case, NullPointerException is thrown from RegexFilter and reaches to LoggerNode and disappears. ConsoleHandler cannot publish the log at all.
> https://github.com/jboss-logging/jboss-logmanager/blob/master/src/main/ja...
> I think 'null' message should simply return 'false' in RegexFilter.isLoggable().
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 2 months
[JBoss JIRA] (LOGMGR-191) Amend NullPointerException in regex filters
by James Perkins (JIRA)
[ https://issues.jboss.org/browse/LOGMGR-191?page=com.atlassian.jira.plugin... ]
James Perkins updated LOGMGR-191:
---------------------------------
Summary: Amend NullPointerException in regex filters (was: Amend NullPointerException in RegexFilter.isLoggable())
> Amend NullPointerException in regex filters
> -------------------------------------------
>
> Key: LOGMGR-191
> URL: https://issues.jboss.org/browse/LOGMGR-191
> Project: JBoss Log Manager
> Issue Type: Bug
> Components: core
> Affects Versions: 2.1.0.Alpha5
> Reporter: Toshiya Kobayashi
> Assignee: Toshiya Kobayashi
> Labels: support
>
> When log message is null, RegexFilter.isLoggable() throws NullPointerException.
> https://github.com/jboss-logging/jboss-logmanager/blob/master/src/main/ja...
> It often results in unexpected outcomes. For example, assuming you have a filter-spec with "not(match(xxx))" to suppress some messages in your logger configuration:
> {code:xml}
> <subsystem xmlns="urn:jboss:domain:logging:3.0">
> <console-handler name="CONSOLE">
> <level name="INFO"/>
> <filter-spec value="not(match("SOME_MESSAGE"))"/>
> <formatter>
> <named-formatter name="COLOR-PATTERN"/>
> </formatter>
> </console-handler>
> {code}
> and an application has a code like this:
> {code:java}
> try {
> ...
> } catch (Exception e) {
> logger.error(e.getMessage(), e);
> }
> {code}
> "e.getMessage()" could be null. But you want to log the stacktrace 'e' anyway.
> In this case, NullPointerException is thrown from RegexFilter and reaches to LoggerNode and disappears. ConsoleHandler cannot publish the log at all.
> https://github.com/jboss-logging/jboss-logmanager/blob/master/src/main/ja...
> I think 'null' message should simply return 'false' in RegexFilter.isLoggable().
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 2 months
[JBoss JIRA] (WFLY-9890) "ISPN000476: Timed out waiting for responses for request X from node Y" immediately after node Y rejoins the cluster (failover)
by Michal Vinkler (JIRA)
[ https://issues.jboss.org/browse/WFLY-9890?page=com.atlassian.jira.plugin.... ]
Michal Vinkler commented on WFLY-9890:
--------------------------------------
new run with build from today:
https://jenkins.hosts.mwqe.eng.bos.redhat.com/hudson/job/mvinkler_perflab...
the issue is still there
> "ISPN000476: Timed out waiting for responses for request X from node Y" immediately after node Y rejoins the cluster (failover)
> -------------------------------------------------------------------------------------------------------------------------------
>
> Key: WFLY-9890
> URL: https://issues.jboss.org/browse/WFLY-9890
> Project: WildFly
> Issue Type: Bug
> Components: Clustering
> Affects Versions: 12.0.0.Beta1
> Reporter: Michal Vinkler
> Assignee: Paul Ferraro
> Priority: Critical
> Fix For: 13.0.0.Beta1
>
>
> Seen in SF failover tests - scenarios:
> failover-http-granular-shutdown-repl-sync (replication granularity is set to ATTRIBUTE level)
> failover-http-session-jvmkill-repl-sync (replication granularity is set to SESSION level)
> Description: In the failover test, each server is shut down and after some time it rejoins the cluster. After joining the cluster again, the load is distributed to this node. It seems that first request for some session handled by that node produces ERROR in the log of some other server until the time another cluster topology change occurs.
> Stacktrace of the error:
> {code}
> [JBossINF] [0m[31m10:18:00,256 ERROR [org.infinispan.interceptors.impl.InvocationContextInterceptor] (timeout-thread--p12-t1) ISPN000136: Error executing command PrepareCommand, writing keys [SessionCreationMetaDataKey(f25_wwXXpvtNC9QTHZUtSwhmEUmg-wI77RL_17b9), SessionAccessMetaDataKey(f25_wwXXpvtNC9QTHZUtSwhmEUmg-wI77RL_17b9), SessionAttributeKey(f25_wwXXpvtNC9QTHZUtSwhmEUmg-wI77RL_17b9[1])]: org.infinispan.util.concurrent.TimeoutException: ISPN000476: Timed out waiting for responses for request 30250 from perf18
> [JBossINF] at org.infinispan.remoting.transport.impl.MultiTargetRequest.onTimeout(MultiTargetRequest.java:163)
> [JBossINF] at org.infinispan.remoting.transport.AbstractRequest.call(AbstractRequest.java:86)
> [JBossINF] at org.infinispan.remoting.transport.AbstractRequest.call(AbstractRequest.java:21)
> [JBossINF] at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> [JBossINF] at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:180)
> [JBossINF] at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293)
> [JBossINF] at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> [JBossINF] at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> [JBossINF] at java.lang.Thread.run(Thread.java:748)
> {code}
> Client gets the stale data:
> {code}
> 2018/02/21 10:18:00:272 EST [WARN ][Runner - 16] HOST perf17.mw.lab.eng.bos.redhat.com:rootProcess:c - Error sampling data: <org.jboss.smartfrog.loaddriver.RequestProcessingException: Stale session data received. Expected 60, received 59, Runner: 16>
> org.jboss.smartfrog.loaddriver.RequestProcessingException: Stale session data received. Expected 60, received 59, Runner: 16
> at org.jboss.smartfrog.loaddriver.http.AbstractSerialNumberValidatorFactoryImpl$SerialNumberValidator.processRequest(AbstractSerialNumberValidatorFactoryImpl.java:133)
> at org.jboss.smartfrog.loaddriver.CompoundRequestProcessorFactoryImpl$CompoundRequestProcessor.processRequest(CompoundRequestProcessorFactoryImpl.java:52)
> at org.jboss.smartfrog.loaddriver.Runner.run(Runner.java:103)
> at java.lang.Thread.run(Thread.java:748)
> {code}
> Example - timeline:
> {code}
> 4 servers are running, 2000 clients, no issue in the beggining
> 2018/02/21 10:16:43:234 EST [INFO ][TestController] HOST perf17.mw.lab.eng.bos.redhat.com:rootProcess:c - Node 0 (perf18) is down.
> - still no issues
> 2018/02/21 10:17:43:234 EST [INFO ][TestController] HOST perf17.mw.lab.eng.bos.redhat.com:rootProcess:c - Bringing back node 0 (perf18)
> 2018/02/21 10:17:55:611 EST [INFO ][TestController] HOST perf17.mw.lab.eng.bos.redhat.com:rootProcess:c - Node 0 (perf18) is up.
> 2018/02/21 10:18:00:272 EST [WARN ][Runner - 16] HOST perf17.mw.lab.eng.bos.redhat.com:rootProcess:c - Error sampling data: <org.jboss.smartfrog.loaddriver.RequestProcessingException: Stale session data received. Expected 60, received 59, Runner: 16>
> {code}
> perf20 started logging the errors meanwhile and stopped only after perf19 was shut down:
> {code}
> [JBossINF] [0m[0m10:17:50,227 INFO [org.infinispan.CLUSTER] (thread-19,ejb,perf20) ISPN000094: Received new cluster view for channel ejb: [perf19|5] (4) [perf19, perf20, perf21, perf18]
> [JBossINF] [0m[0m10:17:50,228 INFO [org.infinispan.CLUSTER] (thread-19,ejb,perf20) ISPN100000: Node perf18 joined the cluster
> [JBossINF] [0m[31m10:18:00,256 ERROR [org.infinispan.interceptors.impl.InvocationContextInterceptor] (timeout-thread--p12-t1) ISPN000136: Error executing command PrepareCommand, writing keys [SessionCreationMetaDataKey(f25_wwXXpvtNC9QTHZUtSwhmEUmg-wI77RL_17b9), SessionAccessMetaDataKey(f25_wwXXpvtNC9QTHZUtSwhmEUmg-wI77RL_17b9), SessionAttributeKey(f25_wwXXpvtNC9QTHZUtSwhmEUmg-wI77RL_17b9[1])]: org.infinispan.util.concurrent.TimeoutException: ISPN000476: Timed out waiting for responses for request 30250 from perf18
> [JBossINF] at org.infinispan.remoting.transport.impl.MultiTargetRequest.onTimeout(MultiTargetRequest.java:163)
> [JBossINF] at org.infinispan.remoting.transport.AbstractRequest.call(AbstractRequest.java:86)
> [JBossINF] at org.infinispan.remoting.transport.AbstractRequest.call(AbstractRequest.java:21)
> [JBossINF] at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> [JBossINF] at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:180)
> [JBossINF] at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293)
> [JBossINF] at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> [JBossINF] at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> [JBossINF] at java.lang.Thread.run(Thread.java:748)
> [JBossINF]
> {code}
> There were no issues in this scenario in EAP 7.1.0.GA.
> Links:
> Clients: http://jenkins.hosts.mwqe.eng.bos.redhat.com/hudson/job/perflab_eap-7x-fa...
> perf18: http://jenkins.hosts.mwqe.eng.bos.redhat.com/hudson/job/perflab_eap-7x-fa...
> perf20: http://jenkins.hosts.mwqe.eng.bos.redhat.com/hudson/job/perflab_eap-7x-fa...
> Another test:
> perf19: http://jenkins.hosts.mwqe.eng.bos.redhat.com/hudson/job/perflab_eap-7x-fa...
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 2 months