[JBoss JIRA] (WFLY-13051) provide setRemoveOnCancelPolicy on ManagedScheduledExecutorService
by Eduardo Martins (Jira)
[ https://issues.redhat.com/browse/WFLY-13051?page=com.atlassian.jira.plugi... ]
Eduardo Martins edited comment on WFLY-13051 at 6/1/20 10:42 AM:
-----------------------------------------------------------------
[~nimo22] Such object is the ManagedScheduledExecutorServiceAdapter, which locks the lifecycle methods according to the spec, and even if it was the ManagedScheduledExecutorService impl itself (which actually comes from the spec Reference Implementation), it's not an extension of a ScheduledThreadPoolExecutor either (it uses one internally tho).
was (Author: emmartins):
[~nimo22] Such object is the scheduled executor adapter, which locks the lifecycle methods according to the spec, and even if it was the executor itself (which ours actually comes from the spec Reference Implementation), it's not an extension of a ScheduledThreadPoolExecutor either (it uses one internally tho).
> provide setRemoveOnCancelPolicy on ManagedScheduledExecutorService
> ------------------------------------------------------------------
>
> Key: WFLY-13051
> URL: https://issues.redhat.com/browse/WFLY-13051
> Project: WildFly
> Issue Type: Enhancement
> Components: Concurrency Utilities
> Affects Versions: 19.0.0.Beta1
> Reporter: nimo stephan
> Assignee: Eduardo Martins
> Priority: Major
>
> Using
> {code:java}
> @Resource
> private ManagedScheduledExecutorService executor;
> {code}
> provides no possiblity to setRemoveOnCancelPolicy to true.
> A casting within a method:
> {code:java}
> ((ScheduledThreadPoolExecutor) executor).setRemoveOnCancelPolicy(true);
> {code}
> throws the error:
> {code:java}
> Caused by: javax.ejb.EJBException: java.lang.ClassCastException: class org.glassfish.enterprise.concurrent.ManagedScheduledExecutorServiceAdapter cannot be cast to class java.util.concurrent.ScheduledThreadPoolExecutor (org.glassfish.enterprise.concurrent.ManagedScheduledExecutorServiceAdapter is in unnamed module of loader 'org.glassfish.javax.enterprise.concurrent' @a93b7af; java.util.concurrent.ScheduledThreadPoolExecutor is in module java.base of loader 'bootstrap')
> at org.jboss.as.ejb3@17.0.1.Final//org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInOurTx(CMTTxInterceptor.java:246)
> at org.jboss.as.ejb3@17.0.1.Final//org.jboss.as.ejb3.tx.CMTTxInterceptor.requiresNew(CMTTxInterceptor.java:388)
> at org.jboss.as.ejb3@17.0.1.Final//org.jboss.as.ejb3.tx.LifecycleCMTTxInterceptor.processInvocation(LifecycleCMTTxInterceptor.java:68)
> {code}
> Please provide option to cast or if not possible to add the property
> {code:java}
> setRemoveOnCancelPolicy()
> {code}
> within the object ManagedScheduledExecutorService. Because without it, we cannot remove a task from the queue with "future.cancel(false)".
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 6 months
[JBoss JIRA] (WFLY-13051) provide setRemoveOnCancelPolicy on ManagedScheduledExecutorService
by Eduardo Martins (Jira)
[ https://issues.redhat.com/browse/WFLY-13051?page=com.atlassian.jira.plugi... ]
Eduardo Martins commented on WFLY-13051:
----------------------------------------
[~nimo22] Such object is the scheduled executor adapter, which locks the lifecycle methods according to the spec, and even if it was the executor itself (which ours actually comes from the spec Reference Implementation), it's not an extension of a ScheduledThreadPoolExecutor either (it uses one internally tho).
> provide setRemoveOnCancelPolicy on ManagedScheduledExecutorService
> ------------------------------------------------------------------
>
> Key: WFLY-13051
> URL: https://issues.redhat.com/browse/WFLY-13051
> Project: WildFly
> Issue Type: Enhancement
> Components: Concurrency Utilities
> Affects Versions: 19.0.0.Beta1
> Reporter: nimo stephan
> Assignee: Eduardo Martins
> Priority: Major
>
> Using
> {code:java}
> @Resource
> private ManagedScheduledExecutorService executor;
> {code}
> provides no possiblity to setRemoveOnCancelPolicy to true.
> A casting within a method:
> {code:java}
> ((ScheduledThreadPoolExecutor) executor).setRemoveOnCancelPolicy(true);
> {code}
> throws the error:
> {code:java}
> Caused by: javax.ejb.EJBException: java.lang.ClassCastException: class org.glassfish.enterprise.concurrent.ManagedScheduledExecutorServiceAdapter cannot be cast to class java.util.concurrent.ScheduledThreadPoolExecutor (org.glassfish.enterprise.concurrent.ManagedScheduledExecutorServiceAdapter is in unnamed module of loader 'org.glassfish.javax.enterprise.concurrent' @a93b7af; java.util.concurrent.ScheduledThreadPoolExecutor is in module java.base of loader 'bootstrap')
> at org.jboss.as.ejb3@17.0.1.Final//org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInOurTx(CMTTxInterceptor.java:246)
> at org.jboss.as.ejb3@17.0.1.Final//org.jboss.as.ejb3.tx.CMTTxInterceptor.requiresNew(CMTTxInterceptor.java:388)
> at org.jboss.as.ejb3@17.0.1.Final//org.jboss.as.ejb3.tx.LifecycleCMTTxInterceptor.processInvocation(LifecycleCMTTxInterceptor.java:68)
> {code}
> Please provide option to cast or if not possible to add the property
> {code:java}
> setRemoveOnCancelPolicy()
> {code}
> within the object ManagedScheduledExecutorService. Because without it, we cannot remove a task from the queue with "future.cancel(false)".
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 6 months
[JBoss JIRA] (DROOLS-5078) can't test against bigdecimal value in test scenario in business central
by Anna Dupliak (Jira)
[ https://issues.redhat.com/browse/DROOLS-5078?page=com.atlassian.jira.plug... ]
Anna Dupliak updated DROOLS-5078:
---------------------------------
Steps to Reproduce:
Create fact with a *Bigdecimal* datatype field. [^Applicant.java]
Create test scenario with this field in the given part of the test. [^Permille.scesim]
Run test.
Expected: message like *"Impossible to parse ..... is not natively supported. Please use an MVEL expression to use it"*
Actual: the test will fail, highlighting the field value with the error message ''class java.math.bigdecimal is not supported'
was:
Create fact with a *Bigdecimal* datatype field. [^Applicant.java]
Create test scenario with this field in the given part of the test. [^Permille.scesim]
Run test.
Expected: message like * "Impossible to parse ..... is not natively supported. Please use an MVEL expression to use it"*
Actual: the test will fail, highlighting the field value with the error message ''class java.math.bigdecimal is not supported'
> can't test against bigdecimal value in test scenario in business central
> ------------------------------------------------------------------------
>
> Key: DROOLS-5078
> URL: https://issues.redhat.com/browse/DROOLS-5078
> Project: Drools
> Issue Type: Bug
> Components: Scenario Simulation and Testing, Test Scenarios Editor
> Reporter: Werner Van Herrewegen
> Assignee: Yeser Amer
> Priority: Major
> Labels: drools-tools
> Fix For: 7.39.0.Final
>
> Attachments: Applicant.java, Permille.scesim, image-2020-02-19-10-13-01-440.png
>
>
> I get the error : test failed with reason
> !image-2020-02-19-10-13-01-440.png|thumbnail!
> see screenshot
> 'class.java.math.bigdecimal is not supported'
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 6 months
[JBoss JIRA] (DROOLS-5078) can't test against bigdecimal value in test scenario in business central
by Anna Dupliak (Jira)
[ https://issues.redhat.com/browse/DROOLS-5078?page=com.atlassian.jira.plug... ]
Anna Dupliak updated DROOLS-5078:
---------------------------------
Steps to Reproduce:
Create fact with a *Bigdecimal* datatype field. [^Applicant.java]
Create test scenario with this field in the given part of the test. [^Permille.scesim]
Run test.
Expected: message like * "Impossible to parse ..... is not natively supported. Please use an MVEL expression to use it"*
Actual: the test will fail, highlighting the field value with the error message ''class java.math.bigdecimal is not supported'
was:
create fact with a bigdecimal datatype field.
create test scenario with this field in the given part of the test
run test
the test will fail, highlighting the field value with the error message ''class java.math.bigdecimal is not supported'
> can't test against bigdecimal value in test scenario in business central
> ------------------------------------------------------------------------
>
> Key: DROOLS-5078
> URL: https://issues.redhat.com/browse/DROOLS-5078
> Project: Drools
> Issue Type: Bug
> Components: Scenario Simulation and Testing, Test Scenarios Editor
> Reporter: Werner Van Herrewegen
> Assignee: Yeser Amer
> Priority: Major
> Labels: drools-tools
> Fix For: 7.39.0.Final
>
> Attachments: Applicant.java, Permille.scesim, image-2020-02-19-10-13-01-440.png
>
>
> I get the error : test failed with reason
> !image-2020-02-19-10-13-01-440.png|thumbnail!
> see screenshot
> 'class.java.math.bigdecimal is not supported'
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 6 months
[JBoss JIRA] (WFLY-13444) Observing High CPU in EPollArrayWrapper.epollCtl default I/O thread
by Srinivas ev (Jira)
[ https://issues.redhat.com/browse/WFLY-13444?page=com.atlassian.jira.plugi... ]
Srinivas ev commented on WFLY-13444:
------------------------------------
HI [~flavia.rainone], any update on this JIRA. Can you please have a look, as this is blocking one of our delivery.
> Observing High CPU in EPollArrayWrapper.epollCtl default I/O thread
> -------------------------------------------------------------------
>
> Key: WFLY-13444
> URL: https://issues.redhat.com/browse/WFLY-13444
> Project: WildFly
> Issue Type: Bug
> Components: Remoting
> Affects Versions: 10.1.0.Final
> Reporter: Srinivas ev
> Assignee: Flavia Rainone
> Priority: Critical
> Attachments: IO thread memory.PNG, IO thread.PNG, Thread consuming high CPU.PNG, ThreadDump1set.zip, ThreadDump2set.zip, default IO thread 73.PNG, default io consuming snapshot.PNG, default io consuming.PNG, stack trace from snapshot.PNG, stack trace in thread dump.PNG, threaddump-1589514505334.tdump, top command output.PNG
>
>
> Facing high CPU by one of the default I/O thread In Wildfly 10.1.0 Final. Looks none of our application component thread is consuming.
> Can somebody check what is triggering this issue? I attached the thread stack to this Jira. This is blocking our releases. When the CPU cores are high in number, multiple default I/O threads will kick in consuming the CPU in 90~100% range continuously.
> Wildfly 10.1.0 Final
> Java -
> openjdk version "1.8.0_232"
> OpenJDK Runtime Environment (build 1.8.0_232-b09)
> OpenJDK 64-Bit Server VM (build 25.232-b09, mixed mode
> ---------------------------------------------------------------------------------------------------
> at java.lang.Throwable.fillInStackTrace(Native Method)
> at java.lang.Throwable.fillInStackTrace(Throwable.java:784)
> at java.lang.Throwable.<init>(Throwable.java:251)
> at java.lang.Exception.<init>(Exception.java:54)
> at java.io.IOException.<init>(IOException.java:47)
> at java.nio.channels.ClosedChannelException.<init>(ClosedChannelException.java:52)
> at org.xnio.ssl.JsseStreamConduit.write(JsseStreamConduit.java:1022)
> at org.xnio.conduits.ConduitStreamSinkChannel.write(ConduitStreamSinkChannel.java:150)
> at org.xnio.http.HttpUpgrade$HttpUpgradeState$StringWriteListener.handleEvent(HttpUpgrade.java:385)
> at org.xnio.http.HttpUpgrade$HttpUpgradeState$StringWriteListener.handleEvent(HttpUpgrade.java:372)
> at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92)
> at org.xnio.conduits.WriteReadyHandler$ChannelListenerHandler.writeReady(WriteReadyHandler.java:65)
> at org.xnio.ssl.JsseStreamConduit.run(JsseStreamConduit.java:393)
> at org.xnio.ssl.JsseStreamConduit.readReady(JsseStreamConduit.java:547)
> at org.xnio.ssl.JsseStreamConduit$2.readReady(JsseStreamConduit.java:319)
> at org.xnio.nio.NioSocketConduit.handleReady(NioSocketConduit.java:89)
> at org.xnio.nio.WorkerThread.run(WorkerThread.java:567)
> -------------------------------------------------------------------------------------------
> at sun.nio.ch.EPollArrayWrapper.epollCtl(Native Method)
> at sun.nio.ch.EPollArrayWrapper.updateRegistrations(EPollArrayWrapper.java:299)
> at sun.nio.ch.EPollArrayWrapper.poll(EPollArrayWrapper.java:268)
> at sun.nio.ch.EPollSelectorImpl.doSelect(EPollSelectorImpl.java:93)
> at sun.nio.ch.SelectorImpl.lockAndDoSelect(SelectorImpl.java:86)
> at sun.nio.ch.SelectorImpl.select(SelectorImpl.java:97)
> at sun.nio.ch.SelectorImpl.select(SelectorImpl.java:101)
> at org.xnio.nio.WorkerThread.run(WorkerThread.java:515)
> -----------------------------------------------------------------------------------
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 6 months
[JBoss JIRA] (WFLY-13132) Wrong/Incomplete CLUSTER_TOPOLOGY update sent to EJB client
by Richard Achmatowicz (Jira)
[ https://issues.redhat.com/browse/WFLY-13132?page=com.atlassian.jira.plugi... ]
Richard Achmatowicz edited comment on WFLY-13132 at 6/1/20 9:24 AM:
--------------------------------------------------------------------
[~cfang] Thanks, Cheng. This change also needs to go into 4.0.x branch as the current version of ejb-client in WF is 4.0.32.
Yes, the bulk of the work has to be merged to WF, we'll queue it up this morning.
was (Author: rachmato):
[~cfang] Thanks, Cheng. This change also needs to go into 4.0.x branch as the current version of ejb-client in WF is 4.0.33.
Yes, the bulk of the work has to be merged to WF, we'll queue it up this morning.
> Wrong/Incomplete CLUSTER_TOPOLOGY update sent to EJB client
> -----------------------------------------------------------
>
> Key: WFLY-13132
> URL: https://issues.redhat.com/browse/WFLY-13132
> Project: WildFly
> Issue Type: Bug
> Components: EJB
> Affects Versions: 19.0.0.Beta2
> Reporter: Joerg Baesner
> Assignee: Cheng Fang
> Priority: Major
> Labels: downstream_dependency
> Attachments: playground.zip
>
>
> h2. +Issue+
> h3. +General Client setup:+
> {code:java}
> Properties p = new Properties();
> p.put(Context.INITIAL_CONTEXT_FACTORY, "org.wildfly.naming.client.WildFlyInitialContextFactory");
> p.put(Context.PROVIDER_URL, {see below});
> p.put(Context.SECURITY_PRINCIPAL, USER);
> p.put(Context.SECURITY_CREDENTIALS, PWD);
> Context context = new InitialContext(p);
> {code}
> ----
> h3. +Standard server configuration:+
> {code:xml}
> <subsystem xmlns="urn:jboss:domain:ejb3:5.0">
> ...
> <remote connector-ref="http-remoting-connector" thread-pool-name="default">
> <channel-creation-options>
> <option name="READ_TIMEOUT" value="${prop.remoting-connector.read.timeout:20}" type="xnio"/>
> <option name="MAX_OUTBOUND_MESSAGES" value="1234" type="remoting"/>
> </channel-creation-options>
> </remote>
> ...
> </subsystem>
> ...
> <subsystem xmlns="urn:jboss:domain:remoting:4.0">
> <connector name="remoting-connector" socket-binding="remoting" security-realm="ApplicationRealm">
> <properties>
> <property name="SSL_ENABLED" value="false"/>
> </properties>
> </connector>
> <http-connector name="http-remoting-connector" connector-ref="default" security-realm="ApplicationRealm"/>
> </subsystem>
> {code}
> h5. +invocation from remote client to server with:+
> * {{remote://localhost:4447}}
> * {{remote+http://localhost:8080}}
> h5. +Client side topology update always:+
> {noformat}
> DEBUG (XNIO-1 task-2) [org.jboss.ejb.client.invocation] Received CLUSTER_TOPOLOGY(15) message from node master:app-cluster-node0, registering cluster ejb to node master:app-cluster-node0
> DEBUG (XNIO-1 task-2) [org.jboss.ejb.client.invocation] Received CLUSTER_TOPOLOGY(15) message block from master:app-cluster-node0, registering block ::/0 to address 127.0.0.1:8080
> DEBUG (XNIO-1 task-2) [org.jboss.ejb.client.invocation] Received CLUSTER_TOPOLOGY(15) message from node master:app-cluster-node0, registering cluster ejb to node master:app-cluster-node1
> DEBUG (XNIO-1 task-2) [org.jboss.ejb.client.invocation] Received CLUSTER_TOPOLOGY(15) message block from master:app-cluster-node0, registering block ::/0 to address 127.0.0.1:8180
> DEBUG (XNIO-1 task-1) [org.jboss.ejb.client.invocation] Received MODULE_AVAILABLE(8) message from node master:app-cluster-node0 for module playground-app/playground-app-web
> DEBUG (XNIO-1 task-1) [org.jboss.ejb.client.invocation] Received MODULE_AVAILABLE(8) message from node master:app-cluster-node0 for module playground-app/playground-app-ejb
> {noformat}
> ----
> h3. +Legacy server configuration:+
> {code:xml}
> <subsystem xmlns="urn:jboss:domain:ejb3:5.0">
> ...
> <remote connector-ref="remoting-connector" thread-pool-name="default">
> <channel-creation-options>
> <option name="READ_TIMEOUT" value="${prop.remoting-connector.read.timeout:20}" type="xnio"/>
> <option name="MAX_OUTBOUND_MESSAGES" value="1234" type="remoting"/>
> </channel-creation-options>
> </remote>
> ...
> </subsystem>
> ...
> <subsystem xmlns="urn:jboss:domain:remoting:4.0">
> <connector name="remoting-connector" socket-binding="remoting" security-realm="ApplicationRealm">
> <properties>
> <property name="SSL_ENABLED" value="false"/>
> </properties>
> </connector>
> <http-connector name="http-remoting-connector" connector-ref="default" security-realm="ApplicationRealm"/>
> </subsystem>
> {code}
> h5. +invocation from remote client to server with:+
> * {{remote://localhost:4447}}
> * {{remote+http://localhost:8080}}
> h5. +Client side topology update always:+
> {noformat}
> DEBUG (XNIO-1 task-2) [org.jboss.ejb.client.invocation] Received CLUSTER_TOPOLOGY(15) message from node master:app-cluster-node0, registering cluster ejb to node master:app-cluster-node0
> DEBUG (XNIO-1 task-2) [org.jboss.ejb.client.invocation] Received CLUSTER_TOPOLOGY(15) message block from master:app-cluster-node0, registering block ::/0 to address 127.0.0.1:4447
> DEBUG (XNIO-1 task-2) [org.jboss.ejb.client.invocation] Received CLUSTER_TOPOLOGY(15) message from node master:app-cluster-node0, registering cluster ejb to node master:app-cluster-node1
> DEBUG (XNIO-1 task-2) [org.jboss.ejb.client.invocation] Received CLUSTER_TOPOLOGY(15) message block from master:app-cluster-node0, registering block ::/0 to address 127.0.0.1:4547
> DEBUG (XNIO-1 task-1) [org.jboss.ejb.client.invocation] Received MODULE_AVAILABLE(8) message from node master:app-cluster-node0 for module playground-app/playground-app-web
> DEBUG (XNIO-1 task-1) [org.jboss.ejb.client.invocation] Received MODULE_AVAILABLE(8) message from node master:app-cluster-node0 for module playground-app/playground-app-ejb
> {noformat}
> h2. +Conclusion+
> Depending on what is configured as {{connector-ref}} in the {{remote}} of the _ejb3_ subsystem the {{CLUSTER_TOPOLOGY}} update is different. From a client perspective it would be expected that either the {{CLUSTER_TOPOLOGY}} update would _only_ contain destinations that are applicable for the _connector/protocol_ that has been used, or maybe even _ALL_ available destinations, as the client could potentially run a mix of protocols between invocations...
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 6 months