[JBoss JIRA] (WFLY-13721) Transaction JTS module misses dependencies to proper handling context propagation async calls
by Kabir Khan (Jira)
Kabir Khan created WFLY-13721:
---------------------------------
Summary: Transaction JTS module misses dependencies to proper handling context propagation async calls
Key: WFLY-13721
URL: https://issues.redhat.com/browse/WFLY-13721
Project: WildFly
Issue Type: Bug
Components: Transactions
Affects Versions: 20.0.0.Beta1
Reporter: Ondrej Chaloupka
Assignee: Ondrej Chaloupka
Fix For: 20.0.0.Final
The transaction JTS module misses the dependency with libraries which manage the reactive asynchronous handling for context propagation.
This is connected to JBTM-3246 which added the context propagation async handling capabilities to Narayana codebase.
The Narayana CDI interceptor is capable to handle reactive async code but it's dependent on reactive streams classes which have to be added as optional dependencies for `jts` module.
When the context propagation feature pack (https://github.com/kabir/wildfly-mp-reactive-feature-pack/) is deployed then these modules are provided into WildFly and the `jts` module will be then capable to use them and provide the context propagation capabilities managed in the feature pack.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 4 months
[JBoss JIRA] (WFLY-13719) Error deploying EJB in WildFly when using @EJB
by Eduardo Martins (Jira)
[ https://issues.redhat.com/browse/WFLY-13719?page=com.atlassian.jira.plugi... ]
Eduardo Martins commented on WFLY-13719:
----------------------------------------
Assuming that the old behaviour was not correct I believe the system property solution makes more sense. We could also defer resolving the EJB to when needed but not sure that would not imply major changes and performance hit for the proper use cases.
> 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
> Priority: Major
> 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, 4 months
[JBoss JIRA] (WFLY-13720) ee global-modules should not allow duplicates
by Bartosz Spyrko-Smietanko (Jira)
[ https://issues.redhat.com/browse/WFLY-13720?page=com.atlassian.jira.plugi... ]
Bartosz Spyrko-Smietanko moved JBEAP-20012 to WFLY-13720:
---------------------------------------------------------
Project: WildFly (was: JBoss Enterprise Application Platform)
Key: WFLY-13720 (was: JBEAP-20012)
Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1)
Component/s: EE
(was: EE)
Fix Version/s: (was: 7.3.3.GA)
> ee global-modules should not allow duplicates
> ---------------------------------------------
>
> Key: WFLY-13720
> URL: https://issues.redhat.com/browse/WFLY-13720
> Project: WildFly
> Issue Type: Bug
> Components: EE
> Reporter: Bartosz Spyrko-Smietanko
> Assignee: Bartosz Spyrko-Smietanko
> Priority: Minor
>
> ee global-modules should not allow duplicates since once it is added once, it does not make sense to add a duplicate.
>
> {code:java}
> [standalone@embedded /] /subsystem=ee:list-add(name=global-modules, value={name=javax.api}) {code}
> Resulting in:
> {code:java}
> <subsystem xmlns="urn:jboss:domain:ee:4.0">
> <global-modules>
> <module name="javax.api"/>
> <module name="javax.api"/>
> </global-modules> {code}
>
> Or
> {code:java}
> [standalone@embedded /] /subsystem=ee:write-attribute(name=global-modules,value=[{name=javax.api},{name=javax.api}, {name=javax.api}])
> {code}
> Resulting in:
> {code:java}
> <subsystem xmlns="urn:jboss:domain:ee:4.0">
> <global-modules>
> <module name="javax.api"/>
> <module name="javax.api"/>
> <module name="javax.api"/>
> </global-modules> {code}
>
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 4 months
[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, 4 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, 4 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, 4 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, 4 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, 4 months