April 2020 - jboss-jira - Jboss List Archives

[JBoss JIRA] (DROOLS-5280) List Filter expression returning single item and nested within arithmetic expression fails to evaluate

by Tracy Hires (Jira)

[ https://issues.redhat.com/browse/DROOLS-5280?page=com.atlassian.jira.plug... ] Tracy Hires commented on DROOLS-5280: ------------------------------------- Yes, you're right. I see that the dmn spec in v1.3 made it clear that the FEEL that I've expected to work is not supported. I had missed both the update in the dmn spec and that the reported version of the dmn engine comforms with v1.3. (I'm not positive whether that semantic did work in earlier versions of the redhat dmn engine, but I suspect it did, as I remember finding the automatic conversion of a singleton list to a single instance to be a convenient shorthand) Thank you for taking the time to offer a complete explanation. > List Filter expression returning single item and nested within arithmetic expression fails to evaluate > ------------------------------------------------------------------------------------------------------ > > Key: DROOLS-5280 > URL: https://issues.redhat.com/browse/DROOLS-5280 > Project: Drools > Issue Type: Bug > Components: dmn engine > Affects Versions: 7.34.0.Final, 7.36.0.Final > Reporter: Tracy Hires > Assignee: Matteo Mortari > Priority: Major > Attachments: MySpace_Relation.zip, screenshot-1.png, screenshot-2.png, screenshot-3.png > > > the expression `addend + listOfStructure[field1="some value"].numberField`, where `field1="some value"` filters `listOfStructure` to a single item and `addend` and `numberField` are both non-null numbers, fails to evaluate. It's possible to work around this by placing `listOfStructure[field1="some value"]` into a separate decision. -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFLY-13417) Optimize marshalling of EnumMap and EnumSet

by Paul Ferraro (Jira)

[ https://issues.redhat.com/browse/WFLY-13417?page=com.atlassian.jira.plugi... ] Paul Ferraro updated WFLY-13417: -------------------------------- Summary: Optimize marshalling of EnumMap and EnumSet (was: Optimize marshalling of EnumSet) > Optimize marshalling of EnumMap and EnumSet > ------------------------------------------- > > Key: WFLY-13417 > URL: https://issues.redhat.com/browse/WFLY-13417 > Project: WildFly > Issue Type: Task > Components: Clustering > Affects Versions: 19.0.0.Final > Reporter: Paul Ferraro > Assignee: Paul Ferraro > Priority: Major > -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFLY-5097) @Startup @Singleton Beans Constructed Multiple Times

by Panagiotis Sotiropoulos (Jira)

[ https://issues.redhat.com/browse/WFLY-5097?page=com.atlassian.jira.plugin... ] Panagiotis Sotiropoulos commented on WFLY-5097: ----------------------------------------------- Adding the mvtc : https://github.com/jboss-set/eap-additional-testsuite/pull/138 > @Startup @Singleton Beans Constructed Multiple Times > ---------------------------------------------------- > > Key: WFLY-5097 > URL: https://issues.redhat.com/browse/WFLY-5097 > Project: WildFly > Issue Type: Bug > Components: EJB > Affects Versions: 9.0.1.Final > Environment: All > Reporter: Davide Crudo > Assignee: Panagiotis Sotiropoulos > Priority: Major > Attachments: singleton.zip > > > When using @Startup and/or @Singleton to start a Bean on server startup, everytime a method is accessed or the bean is injected with @EJB, both Constructor and @Postconstruct are executed. > This happens multiple times, each time any component uses the Singleton bean. > This seems similar to an issue reported for JBOSS AS 7.x (see forum link reference below) -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFLY-13418) Optimize marshalling of blocking queues

by Paul Ferraro (Jira)

Paul Ferraro created WFLY-13418: ----------------------------------- Summary: Optimize marshalling of blocking queues Key: WFLY-13418 URL: https://issues.redhat.com/browse/WFLY-13418 Project: WildFly Issue Type: Task Components: Clustering Affects Versions: 19.0.0.Final Reporter: Paul Ferraro Assignee: Paul Ferraro -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFLY-13417) Optimize marshalling of EnumSet

by Paul Ferraro (Jira)

Paul Ferraro created WFLY-13417: ----------------------------------- Summary: Optimize marshalling of EnumSet Key: WFLY-13417 URL: https://issues.redhat.com/browse/WFLY-13417 Project: WildFly Issue Type: Task Components: Clustering Affects Versions: 19.0.0.Final Reporter: Paul Ferraro Assignee: Paul Ferraro -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFLY-13416) Upgrade jberet-core from 1.3.5.Final to 1.3.6.Final

by Cheng Fang (Jira)

[ https://issues.redhat.com/browse/WFLY-13416?page=com.atlassian.jira.plugi... ] Cheng Fang updated WFLY-13416: ------------------------------ Description: Diff between jberet-core 1.3.5.Final and 1.3.6.Final: https://github.com/jberet/jsr352/compare/1.3.5.Final...1.3.6.Final The issue fixed in this release: was:Diff between jberet-core 1.3.5.Final and 1.3.6.Final: https://github.com/jberet/jsr352/compare/1.3.5.Final...1.3.6.Final > Upgrade jberet-core from 1.3.5.Final to 1.3.6.Final > --------------------------------------------------- > > Key: WFLY-13416 > URL: https://issues.redhat.com/browse/WFLY-13416 > Project: WildFly > Issue Type: Component Upgrade > Components: Batch > Reporter: Cheng Fang > Assignee: Cheng Fang > Priority: Major > > Diff between jberet-core 1.3.5.Final and 1.3.6.Final: https://github.com/jberet/jsr352/compare/1.3.5.Final...1.3.6.Final > The issue fixed in this release: -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFLY-13416) Upgrade jberet-core from 1.3.5.Final to 1.3.6.Final

by Cheng Fang (Jira)

[ https://issues.redhat.com/browse/WFLY-13416?page=com.atlassian.jira.plugi... ] Cheng Fang updated WFLY-13416: ------------------------------ Description: Diff between jberet-core 1.3.5.Final and 1.3.6.Final: https://github.com/jberet/jsr352/compare/1.3.5.Final...1.3.6.Final The issue fixed in this release: JBERET-493 org.jberet.spi.JobExecutor#wrap method should allow override by subclass The above fix is needed for fixing the following issue: WFLY-13357 (Regression) Execution of concurrent batch jobs containg partitioned steps causes deadlock was: Diff between jberet-core 1.3.5.Final and 1.3.6.Final: https://github.com/jberet/jsr352/compare/1.3.5.Final...1.3.6.Final The issue fixed in this release: > Upgrade jberet-core from 1.3.5.Final to 1.3.6.Final > --------------------------------------------------- > > Key: WFLY-13416 > URL: https://issues.redhat.com/browse/WFLY-13416 > Project: WildFly > Issue Type: Component Upgrade > Components: Batch > Reporter: Cheng Fang > Assignee: Cheng Fang > Priority: Major > > Diff between jberet-core 1.3.5.Final and 1.3.6.Final: https://github.com/jberet/jsr352/compare/1.3.5.Final...1.3.6.Final > The issue fixed in this release: > JBERET-493 org.jberet.spi.JobExecutor#wrap method should allow override by subclass > The above fix is needed for fixing the following issue: > WFLY-13357 (Regression) Execution of concurrent batch jobs containg partitioned steps causes deadlock -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFLY-13416) Upgrade jberet-core from 1.3.5.Final to 1.3.6.Final

by Cheng Fang (Jira)

[ https://issues.redhat.com/browse/WFLY-13416?page=com.atlassian.jira.plugi... ] Cheng Fang updated WFLY-13416: ------------------------------ Description: Diff between jberet-core 1.3.5.Final and 1.3.6.Final: https://github.com/jberet/jsr352/compare/1.3.5.Final...1.3.6.Final > Upgrade jberet-core from 1.3.5.Final to 1.3.6.Final > --------------------------------------------------- > > Key: WFLY-13416 > URL: https://issues.redhat.com/browse/WFLY-13416 > Project: WildFly > Issue Type: Component Upgrade > Components: Batch > Reporter: Cheng Fang > Assignee: Cheng Fang > Priority: Major > > Diff between jberet-core 1.3.5.Final and 1.3.6.Final: https://github.com/jberet/jsr352/compare/1.3.5.Final...1.3.6.Final -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 8 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-5250) [Scesim editor] Wrong context type scesim generation

by Anna Dupliak (Jira)

[ https://issues.redhat.com/browse/DROOLS-5250?page=com.atlassian.jira.plug... ] Anna Dupliak updated DROOLS-5250: --------------------------------- Attachment: CollectionsDoesNotWork.webm > [Scesim editor] Wrong context type scesim generation > ----------------------------------------------------- > > Key: DROOLS-5250 > URL: https://issues.redhat.com/browse/DROOLS-5250 > Project: Drools > Issue Type: Bug > Components: Test Scenarios Editor > Affects Versions: 7.37.0.Final > Reporter: Anna Dupliak > Assignee: Yeser Amer > Priority: Major > Labels: drools-tools > Fix For: 7.37.0.Final > > Attachments: CollectionsDoesNotWork.webm, TestPossible types.dmn, image-2020-04-03-11-47-11-708.png > > > When I create a data type in dmn like: > -tDriver (Structure) > --tNested (Structure) > ---nested (string) > --contextType(context) > Then fact is generated as tNested.contextType.value but expect contextType.value > !image-2020-04-03-11-47-11-708.png|thumbnail! -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFLY-13357) (Regression) Execution of concurrent batch jobs containg partitioned steps causes deadlock

by Cheng Fang (Jira)

[ https://issues.redhat.com/browse/WFLY-13357?page=com.atlassian.jira.plugi... ] Cheng Fang commented on WFLY-13357: ----------------------------------- To reproduce it, see https://github.com/jberet/jberet-wildfly-samples/tree/master/throttle > (Regression) Execution of concurrent batch jobs containg partitioned steps causes deadlock > ------------------------------------------------------------------------------------------ > > Key: WFLY-13357 > URL: https://issues.redhat.com/browse/WFLY-13357 > Project: WildFly > Issue Type: Bug > Components: Batch > Affects Versions: 19.0.0.Final > Reporter: Felix König > Assignee: Cheng Fang > Priority: Major > Fix For: 20.0.0.Beta1 > > > Hello, > the issue described in JBERET-180 seems to have reappeared. I am running Wildfly 16 with jberet-1.3.3. Given that there is a default batch-thread count of 10 I was able to produce a deadlock by starting 10 instances of a partitioned job simultaneously. None of the job runs fast enough to finish before all 10 jobs have been started. All 10 Batch-threads are stuck here: > {code} > "Batch Thread - 1@33537" prio=5 tid=0x109 nid=NA waiting > java.lang.Thread.State: WAITING > at jdk.internal.misc.Unsafe.park(Unknown Source:-1) > at java.util.concurrent.locks.LockSupport.park(Unknown Source:-1) > at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(Unknown Source:-1) > at java.util.concurrent.ArrayBlockingQueue.take(Unknown Source:-1) > at org.jberet.runtime.runner.StepExecutionRunner.beginPartition(StepExecutionRunner.java:350) > at org.jberet.runtime.runner.StepExecutionRunner.runBatchletOrChunk(StepExecutionRunner.java:222) > at org.jberet.runtime.runner.StepExecutionRunner.run(StepExecutionRunner.java:144) > at org.jberet.runtime.runner.CompositeExecutionRunner.runStep(CompositeExecutionRunner.java:164) > at org.jberet.runtime.runner.CompositeExecutionRunner.runFromHeadOrRestartPoint(CompositeExecutionRunner.java:88) > at org.jberet.runtime.runner.JobExecutionRunner.run(JobExecutionRunner.java:60) > at org.wildfly.extension.batch.jberet.deployment.BatchEnvironmentService$WildFlyBatchEnvironment$1.run(BatchEnvironmentService.java:180) > at org.wildfly.extension.requestcontroller.RequestController$QueuedTask$1.run(RequestController.java:494) > at org.jberet.spi.JobExecutor$2.run(JobExecutor.java:149) > at org.jberet.spi.JobExecutor$1.run(JobExecutor.java:99) > at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source:-1) > at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source:-1) > at java.lang.Thread.run(Unknown Source:-1) > at org.jboss.threads.JBossThread.run(JBossThread.java:485) > {code} > which is this line of code: > {code:java} > completedPartitionThreads.take(); > {code} > Rarely some threads also get stuck at line 364 instead, which is > {code:java} > final Serializable data = collectorDataQueue.take(); > {code} -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 8 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira April 2020