[JBoss JIRA] (WFLY-13177) ManagedExecutorService: Wrong RequestCount on Exception
by Guido Jäkel (Jira)
Guido Jäkel created WFLY-13177:
----------------------------------
Summary: ManagedExecutorService: Wrong RequestCount on Exception
Key: WFLY-13177
URL: https://issues.redhat.com/browse/WFLY-13177
Project: WildFly
Issue Type: Bug
Components: EE, Server
Affects Versions: 16.0.0.Final, 10.1.0.Final
Reporter: Guido Jäkel
Assignee: Brian Stansberry
On WF-10 and WF-16 we observe a serious bug of the RequestCount of the RequestController while using ManagedExecutorService.submit() or ...execute() in the edge case of a full queue. In this case, the caller gets a RejectedExecutionException, but in the RequestController, the number of active requests is erroneously incremented.
This will lead to a false and monotonously increasing number of active requests. And in case of a limitation configured by the maxRequestCount feature, which is best practice for production environments, over the time this will lead to deadlock of the RequestController and herewith the complete activity of the Wildfly at all.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 8 months
[JBoss JIRA] (WFLY-13175) Expressions in jboss-ejb-client.xml don't work for client-context invocation-timeout
by Cheng Fang (Jira)
[ https://issues.redhat.com/browse/WFLY-13175?page=com.atlassian.jira.plugi... ]
Cheng Fang commented on WFLY-13175:
-----------------------------------
Looks like another {{client-context}} attribute, {{deployment-node-selector}} does not honor expression either.
> Expressions in jboss-ejb-client.xml don't work for client-context invocation-timeout
> ------------------------------------------------------------------------------------
>
> Key: WFLY-13175
> URL: https://issues.redhat.com/browse/WFLY-13175
> Project: WildFly
> Issue Type: Bug
> Components: EJB
> Reporter: Cheng Fang
> Assignee: Cheng Fang
> Priority: Minor
>
> [WFLY-4303] made it possible to use expressions in jboss-ejb-client.xml
> However that doesn't seem to work everywhere. We tried to make several especially timeout related properties configurable and while expressions work at most places, in the case of {{client-context invocation-timeout}} they don't and we get a java.lang.NumberFormatException for the string specified as the value of the invocation-timeout.
> Would it be possible to make the {{client-context invocation-timeout}} work with expressions as well?
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 8 months
[JBoss JIRA] (WFLY-13176) Add jboss-ejb-client_1_3.xsd schema
by Cheng Fang (Jira)
Cheng Fang created WFLY-13176:
---------------------------------
Summary: Add jboss-ejb-client_1_3.xsd schema
Key: WFLY-13176
URL: https://issues.redhat.com/browse/WFLY-13176
Project: WildFly
Issue Type: Bug
Components: EJB
Reporter: Cheng Fang
Assignee: Cheng Fang
WildFly currently (2020-02-28) includes schemas 1.0, 1.1, 1.2, but not 1.3:
{code}
./src/main/resources/schema/jboss-ejb-client_1_1.xsd
./src/main/resources/schema/jboss-ejb-client_1_0.xsd
./src/main/resources/schema/jboss-ejb-client_1_2.xsd
{code}
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 8 months
[JBoss JIRA] (WFLY-13175) Expressions in jboss-ejb-client.xml don't work for client-context invocation-timeout
by Cheng Fang (Jira)
[ https://issues.redhat.com/browse/WFLY-13175?page=com.atlassian.jira.plugi... ]
Cheng Fang moved JBEAP-18837 to WFLY-13175:
-------------------------------------------
Project: WildFly (was: JBoss Enterprise Application Platform)
Key: WFLY-13175 (was: JBEAP-18837)
Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1)
Component/s: EJB
(was: EJB)
Affects Version/s: (was: 7.2.4.GA)
> Expressions in jboss-ejb-client.xml don't work for client-context invocation-timeout
> ------------------------------------------------------------------------------------
>
> Key: WFLY-13175
> URL: https://issues.redhat.com/browse/WFLY-13175
> Project: WildFly
> Issue Type: Bug
> Components: EJB
> Reporter: Cheng Fang
> Assignee: Cheng Fang
> Priority: Minor
>
> [WFLY-4303] made it possible to use expressions in jboss-ejb-client.xml
> However that doesn't seem to work everywhere. We tried to make several especially timeout related properties configurable and while expressions work at most places, in the case of {{client-context invocation-timeout}} they don't and we get a java.lang.NumberFormatException for the string specified as the value of the invocation-timeout.
> Would it be possible to make the {{client-context invocation-timeout}} work with expressions as well?
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 8 months
[JBoss JIRA] (WFLY-13174) Improve the WFLYSRV0002 error message
by Carlo de Wolf (Jira)
Carlo de Wolf created WFLY-13174:
------------------------------------
Summary: Improve the WFLYSRV0002 error message
Key: WFLY-13174
URL: https://issues.redhat.com/browse/WFLY-13174
Project: WildFly
Issue Type: Enhancement
Reporter: Carlo de Wolf
Assignee: Brian Stansberry
Currently WFLYSRV0002 is reported as an error and the associated exception is swallowed.
{noformat}
WFLYSRV0002: Could not read provided index
{noformat}
It should really be a warning with details of the exception.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 8 months
[JBoss JIRA] (WFLY-13031) EAP quickstart 'messaging-clustering-singleton' shows errors after import
by Zbyněk Červinka (Jira)
[ https://issues.redhat.com/browse/WFLY-13031?page=com.atlassian.jira.plugi... ]
Zbyněk Červinka commented on WFLY-13031:
----------------------------------------
Update - after testing the 7.2.0.GA version I can say, there are the same issues as mentioned in the description. I am really looking forward to test the new version where the issues will be fixed :D
> EAP quickstart 'messaging-clustering-singleton' shows errors after import
> -------------------------------------------------------------------------
>
> Key: WFLY-13031
> URL: https://issues.redhat.com/browse/WFLY-13031
> Project: WildFly
> Issue Type: Bug
> Components: Quickstarts
> Reporter: Zbyněk Červinka
> Assignee: Parul Sharma
> Priority: Major
> Fix For: 19.0.0.Beta2
>
> Attachments: Problems view.png, Project Explorer.png, jboss-ejb3.xml file.png
>
>
> h1. EAP quickstart 'messaging-clustering-singleton' shows 3 errors in the jboss-ejb3.xml file after import:
> * Referenced file contains errors (jar:file:/Applications/codereadystudio-eap-8/studio/codereadystudio.app/Contents/Eclipse/plugins/org.jboss.tools.as.catalog_3.7.0.v20190624-1620.jar!/schema/xsd/jboss-ejb-delivery-active_1_1.xsd). For more information, right click on the message in the Problems View and select "Show Details..."
> * Referenced file contains errors (jar:file:/Applications/codereadystudio-eap-8/studio/codereadystudio.app/Contents/Eclipse/plugins/org.jboss.tools.as.catalog_3.7.0.v20190624-1620.jar!/schema/xsd/jboss-ejb3-2_0.xsd). For more information, right click on the message in the Problems View and select "Show Details..."
> * Referenced file contains errors (jar:file:/Applications/codereadystudio-eap-8/studio/codereadystudio.app/Contents/Eclipse/plugins/org.jboss.tools.as.catalog_3.7.0.v20190624-1620.jar!/schema/xsd/jboss-ejb3-spec-2_0.xsd). For more information, right click on the message in the Problems View and select "Show Details..."
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 8 months
[JBoss JIRA] (REMJMX-166) IllegalThreadStateException after idle jmx connection
by Brad Maxwell (Jira)
[ https://issues.redhat.com/browse/REMJMX-166?page=com.atlassian.jira.plugi... ]
Brad Maxwell updated REMJMX-166:
--------------------------------
Git Pull Request: https://github.com/jbossas/remoting-jmx/pull/43, https://github.com/jbossas/remoting-jmx/pull/42
> IllegalThreadStateException after idle jmx connection
> -----------------------------------------------------
>
> Key: REMJMX-166
> URL: https://issues.redhat.com/browse/REMJMX-166
> Project: Remoting JMX
> Issue Type: Bug
> Components: Connection
> Affects Versions: 3.0.2.Final, 3.0.3.Final
> Environment: org.jboss.remotingjmx:remoting-jmx:3.0.3.Final + java8
> Reporter: Märt Bakhoff
> Assignee: Darran Lofthouse
> Priority: Blocker
> Attachments: REMJMX-160.jar, REMJMX-166.jar
>
>
> Start wildfly-17.0.1/bin/standalone.sh, then run this code snippet:
> {noformat}
> JMXServiceURL url = new JMXServiceURL("service:jmx:remote+http://127.0.0.1:9990");
> try (JMXConnector connector = new RemotingConnectorProvider().newJMXConnector(url, Collections.emptyMap())) {
> connector.connect();
> MBeanServerConnection beanServer = connector.getMBeanServerConnection();
> RuntimeMXBean bean = ManagementFactory.newPlatformMXBeanProxy(beanServer, ManagementFactory.RUNTIME_MXBEAN_NAME, RuntimeMXBean.class);
> Thread.sleep(70_000);
> System.out.println("uptime: " + bean.getUptime());
> }
> {noformat}
> The following exception is always thrown:
> {noformat}
> Exception in thread "XNIO-1 task-12" java.lang.IllegalThreadStateException
> at java.lang.ThreadGroup.addUnstarted(ThreadGroup.java:867)
> at java.lang.Thread.init(Thread.java:405)
> at java.lang.Thread.init(Thread.java:349)
> at java.lang.Thread.<init>(Thread.java:599)
> at org.jboss.remotingjmx.protocol.v2.ClientExecutorManager$1.newThread(ClientExecutorManager.java:56)
> at java.util.concurrent.ThreadPoolExecutor$Worker.<init>(ThreadPoolExecutor.java:619)
> at java.util.concurrent.ThreadPoolExecutor.addWorker(ThreadPoolExecutor.java:932)
> at java.util.concurrent.ThreadPoolExecutor.execute(ThreadPoolExecutor.java:1378)
> at org.jboss.remotingjmx.protocol.v2.ClientExecutorManager.execute(ClientExecutorManager.java:64)
> at org.jboss.remotingjmx.protocol.v2.ClientCommon$MessageReceiver.handleMessage(ClientCommon.java:118)
> at org.jboss.remoting3.remote.RemoteConnectionChannel.lambda$handleMessageData$3(RemoteConnectionChannel.java:430)
> at org.jboss.remoting3.EndpointImpl$TrackingExecutor.lambda$execute$0(EndpointImpl.java:926)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> at java.lang.Thread.run(Thread.java:748)
> {noformat}
> The cause is in org.jboss.remotingjmx.protocol.v2.ClientExecutorManager.<init>. It creates a thread pool with Executors.newCachedThreadPool that has the default keepAliveTime of 60s.
> The thread factory is using a daemon thread group REMOTING_JMX that will self-destruct when the cached thread is terminated.
> The same code works when using older org.jboss.remotingjmx:remoting-jmx:3.0.1.Final. The regression is likely caused by commit https://github.com/jbossas/remoting-jmx/commit/2d6ae6c26da43304b752fc48f1...
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 8 months
[JBoss JIRA] (REMJMX-166) IllegalThreadStateException after idle jmx connection
by Brad Maxwell (Jira)
[ https://issues.redhat.com/browse/REMJMX-166?page=com.atlassian.jira.plugi... ]
Brad Maxwell updated REMJMX-166:
--------------------------------
Attachment: REMJMX-166.jar
REMJMX-160.jar
> IllegalThreadStateException after idle jmx connection
> -----------------------------------------------------
>
> Key: REMJMX-166
> URL: https://issues.redhat.com/browse/REMJMX-166
> Project: Remoting JMX
> Issue Type: Bug
> Components: Connection
> Affects Versions: 3.0.2.Final, 3.0.3.Final
> Environment: org.jboss.remotingjmx:remoting-jmx:3.0.3.Final + java8
> Reporter: Märt Bakhoff
> Assignee: Darran Lofthouse
> Priority: Blocker
> Attachments: REMJMX-160.jar, REMJMX-166.jar
>
>
> Start wildfly-17.0.1/bin/standalone.sh, then run this code snippet:
> {noformat}
> JMXServiceURL url = new JMXServiceURL("service:jmx:remote+http://127.0.0.1:9990");
> try (JMXConnector connector = new RemotingConnectorProvider().newJMXConnector(url, Collections.emptyMap())) {
> connector.connect();
> MBeanServerConnection beanServer = connector.getMBeanServerConnection();
> RuntimeMXBean bean = ManagementFactory.newPlatformMXBeanProxy(beanServer, ManagementFactory.RUNTIME_MXBEAN_NAME, RuntimeMXBean.class);
> Thread.sleep(70_000);
> System.out.println("uptime: " + bean.getUptime());
> }
> {noformat}
> The following exception is always thrown:
> {noformat}
> Exception in thread "XNIO-1 task-12" java.lang.IllegalThreadStateException
> at java.lang.ThreadGroup.addUnstarted(ThreadGroup.java:867)
> at java.lang.Thread.init(Thread.java:405)
> at java.lang.Thread.init(Thread.java:349)
> at java.lang.Thread.<init>(Thread.java:599)
> at org.jboss.remotingjmx.protocol.v2.ClientExecutorManager$1.newThread(ClientExecutorManager.java:56)
> at java.util.concurrent.ThreadPoolExecutor$Worker.<init>(ThreadPoolExecutor.java:619)
> at java.util.concurrent.ThreadPoolExecutor.addWorker(ThreadPoolExecutor.java:932)
> at java.util.concurrent.ThreadPoolExecutor.execute(ThreadPoolExecutor.java:1378)
> at org.jboss.remotingjmx.protocol.v2.ClientExecutorManager.execute(ClientExecutorManager.java:64)
> at org.jboss.remotingjmx.protocol.v2.ClientCommon$MessageReceiver.handleMessage(ClientCommon.java:118)
> at org.jboss.remoting3.remote.RemoteConnectionChannel.lambda$handleMessageData$3(RemoteConnectionChannel.java:430)
> at org.jboss.remoting3.EndpointImpl$TrackingExecutor.lambda$execute$0(EndpointImpl.java:926)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> at java.lang.Thread.run(Thread.java:748)
> {noformat}
> The cause is in org.jboss.remotingjmx.protocol.v2.ClientExecutorManager.<init>. It creates a thread pool with Executors.newCachedThreadPool that has the default keepAliveTime of 60s.
> The thread factory is using a daemon thread group REMOTING_JMX that will self-destruct when the cached thread is terminated.
> The same code works when using older org.jboss.remotingjmx:remoting-jmx:3.0.1.Final. The regression is likely caused by commit https://github.com/jbossas/remoting-jmx/commit/2d6ae6c26da43304b752fc48f1...
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 8 months
[JBoss JIRA] (DROOLS-5113) Do not compile exec model classes in RAM
by Luca Molteni (Jira)
[ https://issues.redhat.com/browse/DROOLS-5113?page=com.atlassian.jira.plug... ]
Luca Molteni updated DROOLS-5113:
---------------------------------
Description:
Currently executable model classes are compiled in RAM
at org.drools.compiler.commons.jci.compilers.AbstractJavaCompiler.compile(AbstractJavaCompiler.java:49)
at org.drools.modelcompiler.builder.CanonicalModelKieProject.writeProjectOutput(CanonicalModelKieProject.java:81)
at org.drools.compiler.kie.builder.impl.KieBuilderImpl.buildKieProject(KieBuilderImpl.java:285)
at org.drools.compiler.kie.builder.impl.KieBuilderImpl.buildAll(KieBuilderImpl.java:247)
at org.drools.compiler.kie.builder.impl.KieBuilderImpl.buildAll(KieBuilderImpl.java:204)
This kie-benchmark fails when running with 10000 rules with the exec model and the lambda externalization activated
mvn clean install -DskipTests=true && java -jar ./target/drools-benchmarks.jar -jvmArgs "-Xms10000m -Xmx10000m -Ddrools.externaliseCanonicalModelLambda=true -XX:+UseG1GC -XX:MetaspaceSize=1000m -XX:MaxMetaspaceSize=1000m -XX:+PrintGCDetails -Xloggc:/tmp/g1-dedup-metaspace4-maxpause.log" -foe true -rf csv -rff results.csv org.drools.benchmarks.turtle.buildtime.BuildKieBaseFromContainerBenchmark
Probably we could start bringing the benchmark code into Drools so that we can debug it with idea (in JMH you can't) with the OpenJDK source code attached
was:
Currently executable model classes are compiled in RAM
at org.drools.compiler.commons.jci.compilers.AbstractJavaCompiler.compile(AbstractJavaCompiler.java:49)
at org.drools.modelcompiler.builder.CanonicalModelKieProject.writeProjectOutput(CanonicalModelKieProject.java:81)
at org.drools.compiler.kie.builder.impl.KieBuilderImpl.buildKieProject(KieBuilderImpl.java:285)
at org.drools.compiler.kie.builder.impl.KieBuilderImpl.buildAll(KieBuilderImpl.java:247)
at org.drools.compiler.kie.builder.impl.KieBuilderImpl.buildAll(KieBuilderImpl.java:204)
This kie-benchmark fails when running with 10000 rules with the exec model and the lambda externalization activated
mvn clean install -DskipTests=true && java -jar ./target/drools-benchmarks.jar -jvmArgs "-Xms10000m -Xmx10000m -Ddrools.externaliseCanonicalModelLambda=true -XX:+UseG1GC -XX:MetaspaceSize=1000m -XX:MaxMetaspaceSize=1000m -XX:+PrintGCDetails -Xloggc:/tmp/g1-dedup-metaspace4-maxpause.log" -foe true -rf csv -rff results.csv org.drools.benchmarks.turtle.buildtime.BuildKieBaseFromContainerBenchmark
> Do not compile exec model classes in RAM
> ----------------------------------------
>
> Key: DROOLS-5113
> URL: https://issues.redhat.com/browse/DROOLS-5113
> Project: Drools
> Issue Type: Enhancement
> Components: executable model
> Reporter: Luca Molteni
> Assignee: Luca Molteni
> Priority: Major
>
> Currently executable model classes are compiled in RAM
> at org.drools.compiler.commons.jci.compilers.AbstractJavaCompiler.compile(AbstractJavaCompiler.java:49)
> at org.drools.modelcompiler.builder.CanonicalModelKieProject.writeProjectOutput(CanonicalModelKieProject.java:81)
> at org.drools.compiler.kie.builder.impl.KieBuilderImpl.buildKieProject(KieBuilderImpl.java:285)
> at org.drools.compiler.kie.builder.impl.KieBuilderImpl.buildAll(KieBuilderImpl.java:247)
> at org.drools.compiler.kie.builder.impl.KieBuilderImpl.buildAll(KieBuilderImpl.java:204)
> This kie-benchmark fails when running with 10000 rules with the exec model and the lambda externalization activated
> mvn clean install -DskipTests=true && java -jar ./target/drools-benchmarks.jar -jvmArgs "-Xms10000m -Xmx10000m -Ddrools.externaliseCanonicalModelLambda=true -XX:+UseG1GC -XX:MetaspaceSize=1000m -XX:MaxMetaspaceSize=1000m -XX:+PrintGCDetails -Xloggc:/tmp/g1-dedup-metaspace4-maxpause.log" -foe true -rf csv -rff results.csv org.drools.benchmarks.turtle.buildtime.BuildKieBaseFromContainerBenchmark
> Probably we could start bringing the benchmark code into Drools so that we can debug it with idea (in JMH you can't) with the OpenJDK source code attached
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 8 months