[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:
---------------------------------
Summary: Can't test against bigdecimal value in test scenario in business central (was: can't test against bigdecimal value in test scenario in business central)
> 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)
3 years, 10 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 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)
3 years, 10 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)
3 years, 10 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)
3 years, 10 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)
3 years, 10 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)
3 years, 10 months