[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)
6 years, 2 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)
6 years, 2 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)
6 years, 2 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)
6 years, 2 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)
6 years, 2 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)
6 years, 2 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)
6 years, 2 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)
6 years, 2 months
[JBoss JIRA] (DROOLS-5113) Do not compile exec model classes in RAM
by Luca Molteni (Jira)
Luca Molteni created DROOLS-5113:
------------------------------------
Summary: 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
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
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 2 months