[JBoss JIRA] (DROOLS-5538) DMN strongly typed class compile errors for collection types
by Toshiya Kobayashi (Jira)
[ https://issues.redhat.com/browse/DROOLS-5538?page=com.atlassian.jira.plug... ]
Toshiya Kobayashi updated DROOLS-5538:
--------------------------------------
Description:
If we have an itemDefinition with isCollection="true", it will cause a compile error for InputSet and OutputSet when typesafe is enabled. Note that itemComponent with isCollection="true" works fine.
DMNRuntimeTypesTest.testCollectionType()
{code:xml}
<semantic:itemDefinition label="tPersonList" name="tPersonList" isCollection="true">
<semantic:typeRef>tPerson</semantic:typeRef>
</semantic:itemDefinition>
{code}
Consider separating TypeSafe specific tests:
https://github.com/kiegroup/drools/pull/2993#discussion_r463500865
was:
If we have an itemDefinition with isCollection="true", it will cause a compile error for InputSet and OutputSet when typesafe is enabled. Note that itemComponent with isCollection="true" works fine.
DMNRuntimeTypesTest.testCollectionType()
{code:xml}
<semantic:itemDefinition label="tPersonList" name="tPersonList" isCollection="true">
<semantic:typeRef>tPerson</semantic:typeRef>
</semantic:itemDefinition>
{code}
> DMN strongly typed class compile errors for collection types
> ------------------------------------------------------------
>
> Key: DROOLS-5538
> URL: https://issues.redhat.com/browse/DROOLS-5538
> Project: Drools
> Issue Type: Bug
> Components: dmn engine
> Affects Versions: 7.40.0.Final
> Reporter: Toshiya Kobayashi
> Assignee: Toshiya Kobayashi
> Priority: Major
>
> If we have an itemDefinition with isCollection="true", it will cause a compile error for InputSet and OutputSet when typesafe is enabled. Note that itemComponent with isCollection="true" works fine.
> DMNRuntimeTypesTest.testCollectionType()
> {code:xml}
> <semantic:itemDefinition label="tPersonList" name="tPersonList" isCollection="true">
> <semantic:typeRef>tPerson</semantic:typeRef>
> </semantic:itemDefinition>
> {code}
> Consider separating TypeSafe specific tests:
> https://github.com/kiegroup/drools/pull/2993#discussion_r463500865
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 9 months
[JBoss JIRA] (DROOLS-5555) Solve test dmn files duplication
by Toshiya Kobayashi (Jira)
Toshiya Kobayashi created DROOLS-5555:
-----------------------------------------
Summary: Solve test dmn files duplication
Key: DROOLS-5555
URL: https://issues.redhat.com/browse/DROOLS-5555
Project: Drools
Issue Type: Task
Components: dmn engine
Affects Versions: 7.40.0.Final
Reporter: Toshiya Kobayashi
Assignee: Toshiya Kobayashi
Solve duplicated dmn files in strongly typed test cases.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 9 months
[JBoss JIRA] (DROOLS-5554) Enhance generated sources annotation for DMNTypes
by Toshiya Kobayashi (Jira)
[ https://issues.redhat.com/browse/DROOLS-5554?page=com.atlassian.jira.plug... ]
Toshiya Kobayashi updated DROOLS-5554:
--------------------------------------
Description:
Add annotation to describe DMNTypes in generated sources (InputSet, OutputSet, composite types) for Swagger/OpenAPI. Especially, time related DMN types like time, duration are treated as Java interfaces like Temporal or TemporalAmount in order to accept several Java classes (for output purpose). So this kind of description is needed.
FYI)
https://github.com/kiegroup/drools/pull/2993#issuecomment-660898266
was:
Add annotation to describe DMNTypes to generated sources (InputSet, OutputSet, composite types) for Swagger/OpenAPI. Especially, time related DMN types like time, duration are treated as Java interfaces like Temporal or TemporalAmount in order to accept several Java classes (for output purpose). So this kind of description is needed.
FYI)
https://github.com/kiegroup/drools/pull/2993#issuecomment-660898266
> Enhance generated sources annotation for DMNTypes
> -------------------------------------------------
>
> Key: DROOLS-5554
> URL: https://issues.redhat.com/browse/DROOLS-5554
> Project: Drools
> Issue Type: Enhancement
> Components: dmn engine
> Affects Versions: 7.40.0.Final
> Reporter: Toshiya Kobayashi
> Assignee: Toshiya Kobayashi
> Priority: Major
>
> Add annotation to describe DMNTypes in generated sources (InputSet, OutputSet, composite types) for Swagger/OpenAPI. Especially, time related DMN types like time, duration are treated as Java interfaces like Temporal or TemporalAmount in order to accept several Java classes (for output purpose). So this kind of description is needed.
> FYI)
> https://github.com/kiegroup/drools/pull/2993#issuecomment-660898266
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 9 months
[JBoss JIRA] (AG-145) Active waiting deadlock in StampedCopyOnWriteArrayList
by Rene Böing (Jira)
[ https://issues.redhat.com/browse/AG-145?page=com.atlassian.jira.plugin.sy... ]
Rene Böing updated AG-145:
--------------------------
Issue Type: Bug (was: Enhancement)
> Active waiting deadlock in StampedCopyOnWriteArrayList
> ------------------------------------------------------
>
> Key: AG-145
> URL: https://issues.redhat.com/browse/AG-145
> Project: Agroal
> Issue Type: Bug
> Affects Versions: 1.8
> Reporter: Rene Böing
> Assignee: Luis Barreiro
> Priority: Critical
> Attachments: image-2020-07-31-08-39-28-630.png, image-2020-07-31-08-40-41-968.png
>
>
> While using agroal connection pool, we discovered some rare deadlock, which are causing 100% cpu on some threads. These deadlocks occur in the StampedCopyOnWriteArrayList class, when there is more than one thread trying to remove the same object.
>
> A simple reproducer in junit (fails nearly every time on my machine):
>
> {code:java}
> @Test
> public void testThis() {
> ExecutorService service = Executors.newFixedThreadPool(10);
> StampedCopyOnWriteArrayList<Object> list = new StampedCopyOnWriteArrayList<>(Object.class);
> Object o = new Object();
> list.add(new Object());
> list.add(new Object());
> list.add(new Object());
> list.add(new Object());
> list.add(o);
> list.add(new Object());
> List<Runnable> runnerList = new ArrayList<>(10);
> List<Future> futureList = new ArrayList<>(10);
> for (int i = 0; i < 10; i++) {
> runnerList.add(new Runnable() {
> @Override
> public void run() {
> list.remove(o);
> System.out.println("Removed success!");
> }
> });
> }
> for (Runnable r : runnerList) {
> futureList.add(service.submit(r));
> }
> for (Future r : futureList) {
> try {
> r.get(10000, TimeUnit.MILLISECONDS);
> } catch (InterruptedException e) {
> e.printStackTrace();
> } catch (ExecutionException e) {
> e.printStackTrace();
> } catch (TimeoutException e) {
> System.out.println("Seems like we have a deadlock!");
> }
> }
> }
> {code}
>
> Originally this deadlock seems to occur, when agroal tries to flush a connection due to the config parameter
> <property name="hibernate.agroal.maxLifetime_m">60</property>
> If at the same time another thread using this connection calls session.close there is a possibility in the ConnectionPool.class getting called twice. The parameter goes through the following path:
> !image-2020-07-31-08-39-28-630.png!
>
> The parallel session.close call does not find a checked_out connection and tries to flush it instead, hence two Threads are getting into the deadlock situation:
> !image-2020-07-31-08-40-41-968.png!
>
> Kind regards,
> Rene
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 9 months
[JBoss JIRA] (WFLY-13719) Error deploying EJB in WildFly when using @EJB
by Chao Wang (Jira)
Chao Wang created WFLY-13719:
--------------------------------
Summary: Error deploying EJB in WildFly when using @EJB
Key: WFLY-13719
URL: https://issues.redhat.com/browse/WFLY-13719
Project: WildFly
Issue Type: Bug
Components: EE, EJB
Affects Versions: 20.0.1.Final
Reporter: Chao Wang
Attachments: reproducer.zip
The following example does *not* get deployed on Wildfly 20.0.1.Final (since WFLY 13.0.0.Final):
~~~
public class PleaseIgnoreMeThanks
{ @EJB private NonExistentEjbExampleLocal nonExistentEjbExample; }
~~~
The issue seems to be on the @EJB annotation.
Generated error:
{code:xml}
10:19:19,025 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-5) MSC000001: Failed to start service jboss.deployment.unit."ejb-in-war.war".INSTALL: org.jboss.msc.service.StartException in service jboss.deployment.unit."ejb-in-war.war".INSTALL: WFLYSRV0153: Failed to process phase INSTALL of deployment "ejb-in-war.war"
at org.jboss.as.server@12.0.3.Final//org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:189)
at org.jboss.msc@1.4.11.Final//org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1739)
at org.jboss.msc@1.4.11.Final//org.jboss.msc.service.ServiceControllerImpl$StartTask.execute(ServiceControllerImpl.java:1701)
at org.jboss.msc@1.4.11.Final//org.jboss.msc.service.ServiceControllerImpl$ControllerTask.run(ServiceControllerImpl.java:1559)
at org.jboss.threads@2.3.3.Final//org.jboss.threads.ContextClassLoaderSavingRunnable.run(ContextClassLoaderSavingRunnable.java:35)
at org.jboss.threads@2.3.3.Final//org.jboss.threads.EnhancedQueueExecutor.safeRun(EnhancedQueueExecutor.java:1982)
at org.jboss.threads@2.3.3.Final//org.jboss.threads.EnhancedQueueExecutor$ThreadBody.doRunTask(EnhancedQueueExecutor.java:1486)
at org.jboss.threads@2.3.3.Final//org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1363)
at java.base/java.lang.Thread.run(Thread.java:834)
Caused by: org.jboss.as.server.deployment.DeploymentUnitProcessingException: WFLYEJB0406: No EJB found with interface of type 'org.jboss.as.quickstarts.ejbTimer.NonExistentEjbExampleLocal' for binding org.jboss.as.quickstarts.ejbTimer.PleaseIgnoreMeThanks/nonExistentEjbExample
at org.jboss.as.ejb3@20.0.1.Final//org.jboss.as.ejb3.deployment.processors.EjbInjectionSource.getResourceValue(EjbInjectionSource.java:90)
at org.jboss.as.ee@20.0.1.Final//org.jboss.as.ee.component.deployers.ModuleJndiBindingProcessor.addJndiBinding(ModuleJndiBindingProcessor.java:269)
at org.jboss.as.ee@20.0.1.Final//org.jboss.as.ee.component.deployers.ModuleJndiBindingProcessor.deploy(ModuleJndiBindingProcessor.java:200)
at org.jboss.as.server@12.0.3.Final//org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:182)
... 8 more
~~{code}
!moz-extension://4f9dc55f-98eb-44f6-97f9-1c9d85f3a188/icons/logo.png!
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 9 months
[JBoss JIRA] (AG-145) Active waiting deadlock in StampedCopyOnWriteArrayList
by Rene Böing (Jira)
[ https://issues.redhat.com/browse/AG-145?page=com.atlassian.jira.plugin.sy... ]
Rene Böing updated AG-145:
--------------------------
Description:
While using agroal connection pool, we discovered some rare deadlock, which are causing 100% cpu on some threads. These deadlocks occur in the StampedCopyOnWriteArrayList class, when there is more than one thread trying to remove the same object.
A simple reproducer in junit (fails nearly every time on my machine):
{code:java}
@Test
public void testThis() {
ExecutorService service = Executors.newFixedThreadPool(10);
StampedCopyOnWriteArrayList<Object> list = new StampedCopyOnWriteArrayList<>(Object.class);
Object o = new Object();
list.add(new Object());
list.add(new Object());
list.add(new Object());
list.add(new Object());
list.add(o);
list.add(new Object());
List<Runnable> runnerList = new ArrayList<>(10);
List<Future> futureList = new ArrayList<>(10);
for (int i = 0; i < 10; i++) {
runnerList.add(new Runnable() {
@Override
public void run() {
list.remove(o);
System.out.println("Removed success!");
}
});
}
for (Runnable r : runnerList) {
futureList.add(service.submit(r));
}
for (Future r : futureList) {
try {
r.get(10000, TimeUnit.MILLISECONDS);
} catch (InterruptedException e) {
e.printStackTrace();
} catch (ExecutionException e) {
e.printStackTrace();
} catch (TimeoutException e) {
System.out.println("Seems like we have a deadlock!");
}
}
}
{code}
Originally this deadlock seems to occur, when agroal tries to flush a connection due to the config parameter
<property name="hibernate.agroal.maxLifetime_m">60</property>
If at the same time another thread using this connection calls session.close there is a possibility in the ConnectionPool.class getting called twice. The parameter goes through the following path:
!image-2020-07-31-08-39-28-630.png!
The parallel session.close call does not find a checked_out connection and tries to flush it instead, hence two Threads are getting into the deadlock situation:
!image-2020-07-31-08-40-41-968.png!
Kind regards,
Rene
was:
While using agroal connection pool, we discovered some rare deadlock, which are causing 100% cpu on some threads. These deadlocks occur in the StampedCopyOnWriteArrayList class, when there is more than one thread trying to remove the same object.
A simple reproduce in junit (fails nearly every time on my machine):
{code:java}
@Test
public void testThis() {
ExecutorService service = Executors.newFixedThreadPool(10);
StampedCopyOnWriteArrayList<Object> list = new StampedCopyOnWriteArrayList<>(Object.class);
Object o = new Object();
list.add(new Object());
list.add(new Object());
list.add(new Object());
list.add(new Object());
list.add(o);
list.add(new Object());
List<Runnable> runnerList = new ArrayList<>(10);
List<Future> futureList = new ArrayList<>(10);
for (int i = 0; i < 10; i++) {
runnerList.add(new Runnable() {
@Override
public void run() {
list.remove(o);
System.out.println("Removed success!");
}
});
}
for (Runnable r : runnerList) {
futureList.add(service.submit(r));
}
for (Future r : futureList) {
try {
r.get(10000, TimeUnit.MILLISECONDS);
} catch (InterruptedException e) {
e.printStackTrace();
} catch (ExecutionException e) {
e.printStackTrace();
} catch (TimeoutException e) {
System.out.println("Seems like we have a deadlock!");
}
}
}
{code}
Originally this deadlock seems to occur, when agroal tries to flush a connection due to the config parameter
<property name="hibernate.agroal.maxLifetime_m">60</property>
If at the same time another thread using this connection calls session.close there is a possibility in the ConnectionPool.class getting called twice. The parameter goes through the following path:
!image-2020-07-31-08-39-28-630.png!
The parallel session.close call does not find a checked_out connection and tries to flush it instead, hence two Threads are getting into the deadlock situation:
!image-2020-07-31-08-40-41-968.png!
Kind regards,
Rene
> Active waiting deadlock in StampedCopyOnWriteArrayList
> ------------------------------------------------------
>
> Key: AG-145
> URL: https://issues.redhat.com/browse/AG-145
> Project: Agroal
> Issue Type: Enhancement
> Affects Versions: 1.8
> Reporter: Rene Böing
> Assignee: Luis Barreiro
> Priority: Critical
> Attachments: image-2020-07-31-08-39-28-630.png, image-2020-07-31-08-40-41-968.png
>
>
> While using agroal connection pool, we discovered some rare deadlock, which are causing 100% cpu on some threads. These deadlocks occur in the StampedCopyOnWriteArrayList class, when there is more than one thread trying to remove the same object.
>
> A simple reproducer in junit (fails nearly every time on my machine):
>
> {code:java}
> @Test
> public void testThis() {
> ExecutorService service = Executors.newFixedThreadPool(10);
> StampedCopyOnWriteArrayList<Object> list = new StampedCopyOnWriteArrayList<>(Object.class);
> Object o = new Object();
> list.add(new Object());
> list.add(new Object());
> list.add(new Object());
> list.add(new Object());
> list.add(o);
> list.add(new Object());
> List<Runnable> runnerList = new ArrayList<>(10);
> List<Future> futureList = new ArrayList<>(10);
> for (int i = 0; i < 10; i++) {
> runnerList.add(new Runnable() {
> @Override
> public void run() {
> list.remove(o);
> System.out.println("Removed success!");
> }
> });
> }
> for (Runnable r : runnerList) {
> futureList.add(service.submit(r));
> }
> for (Future r : futureList) {
> try {
> r.get(10000, TimeUnit.MILLISECONDS);
> } catch (InterruptedException e) {
> e.printStackTrace();
> } catch (ExecutionException e) {
> e.printStackTrace();
> } catch (TimeoutException e) {
> System.out.println("Seems like we have a deadlock!");
> }
> }
> }
> {code}
>
> Originally this deadlock seems to occur, when agroal tries to flush a connection due to the config parameter
> <property name="hibernate.agroal.maxLifetime_m">60</property>
> If at the same time another thread using this connection calls session.close there is a possibility in the ConnectionPool.class getting called twice. The parameter goes through the following path:
> !image-2020-07-31-08-39-28-630.png!
>
> The parallel session.close call does not find a checked_out connection and tries to flush it instead, hence two Threads are getting into the deadlock situation:
> !image-2020-07-31-08-40-41-968.png!
>
> Kind regards,
> Rene
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 9 months
[JBoss JIRA] (AG-145) Active waiting deadlock in StampedCopyOnWriteArrayList
by Rene Böing (Jira)
Rene Böing created AG-145:
-----------------------------
Summary: Active waiting deadlock in StampedCopyOnWriteArrayList
Key: AG-145
URL: https://issues.redhat.com/browse/AG-145
Project: Agroal
Issue Type: Enhancement
Affects Versions: 1.8
Reporter: Rene Böing
Assignee: Luis Barreiro
Attachments: image-2020-07-31-08-39-28-630.png, image-2020-07-31-08-40-41-968.png
While using agroal connection pool, we discovered some rare deadlock, which are causing 100% cpu on some threads. These deadlocks occur in the StampedCopyOnWriteArrayList class, when there is more than one thread trying to remove the same object.
A simple reproduce in junit (fails nearly every time on my machine):
{code:java}
@Test
public void testThis() {
ExecutorService service = Executors.newFixedThreadPool(10);
StampedCopyOnWriteArrayList<Object> list = new StampedCopyOnWriteArrayList<>(Object.class);
Object o = new Object();
list.add(new Object());
list.add(new Object());
list.add(new Object());
list.add(new Object());
list.add(o);
list.add(new Object());
List<Runnable> runnerList = new ArrayList<>(10);
List<Future> futureList = new ArrayList<>(10);
for (int i = 0; i < 10; i++) {
runnerList.add(new Runnable() {
@Override
public void run() {
list.remove(o);
System.out.println("Removed success!");
}
});
}
for (Runnable r : runnerList) {
futureList.add(service.submit(r));
}
for (Future r : futureList) {
try {
r.get(10000, TimeUnit.MILLISECONDS);
} catch (InterruptedException e) {
e.printStackTrace();
} catch (ExecutionException e) {
e.printStackTrace();
} catch (TimeoutException e) {
System.out.println("Seems like we have a deadlock!");
}
}
}
{code}
Originally this deadlock seems to occur, when agroal tries to flush a connection due to the config parameter
<property name="hibernate.agroal.maxLifetime_m">60</property>
If at the same time another thread using this connection calls session.close there is a possibility in the ConnectionPool.class getting called twice. The parameter goes through the following path:
!image-2020-07-31-08-39-28-630.png!
The parallel session.close call does not find a checked_out connection and tries to flush it instead, hence two Threads are getting into the deadlock situation:
!image-2020-07-31-08-40-41-968.png!
Kind regards,
Rene
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 9 months
[JBoss JIRA] (DROOLS-5550) Drools model compiler fails when assigning salience from a static constant
by Mario Fusco (Jira)
[ https://issues.redhat.com/browse/DROOLS-5550?page=com.atlassian.jira.plug... ]
Mario Fusco updated DROOLS-5550:
--------------------------------
Sprint: 2020 Week 31-33 (from Jul 27)
> Drools model compiler fails when assigning salience from a static constant
> --------------------------------------------------------------------------
>
> Key: DROOLS-5550
> URL: https://issues.redhat.com/browse/DROOLS-5550
> Project: Drools
> Issue Type: Bug
> Affects Versions: 7.31.0.Final, 7.32.0.Final, 7.33.0.Final, 7.34.0.Final, 7.35.0.Final, 7.36.0.Final, 7.37.0.Final, 7.38.0.Final, 7.39.0.Final, 7.40.0.Final
> Reporter: Ciprian Chiru
> Assignee: Mario Fusco
> Priority: Major
>
> Given the example rule:
> {code:java}
> global java.util.Set controlSet;
> rule "will execute per each Measurement having ID color"
> salience Salience.NORMAL
> no-loop
> when
> Measurement( id == "color", $colorVal : val )
> then
> controlSet.add($colorVal);
> end{code}
> when compiling the rules, the _org.apache.maven.plugins:maven-compiler-plugin:3.8.0:compile_ throws:
> {code:java}
> Compilation failure
> [ERROR] .../target/generated-sources/drools-model-compiler/main/java/rules/Rules1b5c9512461f45df875fa525fff06227RuleMethods0.java:[28,109] no suitable method found for supply(int)
> [ERROR] method org.drools.model.DSL.<A,R>supply(org.drools.model.Variable<A>,org.drools.model.functions.Function1<A,R>) is not applicable
> [ERROR] (cannot infer type-variable(s) A,R
> [ERROR] (actual and formal argument lists differ in length))
> [ERROR] method org.drools.model.DSL.<A,B,R>supply(org.drools.model.Variable<A>,org.drools.model.Variable<B>,org.drools.model.functions.Function2<A,B,R>) is not applicable
> [ERROR] (cannot infer type-variable(s) A,B,R
> [ERROR] (actual and formal argument lists differ in length)){code}
>
> The same rule works fine when the rule is not pre-compiled.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 9 months