April 2020 - jboss-jira - Jboss List Archives

[JBoss JIRA] (SWSQE-1113) Smee client is ignoring some merge PR commits

by Filip Brychta (Jira)

Filip Brychta created SWSQE-1113: ------------------------------------ Summary: Smee client is ignoring some merge PR commits Key: SWSQE-1113 URL: https://issues.redhat.com/browse/SWSQE-1113 Project: Kiali QE Issue Type: QE Task Reporter: Filip Brychta Assignee: Filip Brychta Some push events from kiali and kiali-ui repos are missed. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 3 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-5231) Wrong BitMask created by a nested property in modify block

by Toshiya Kobayashi (Jira)

[ https://issues.redhat.com/browse/DROOLS-5231?page=com.atlassian.jira.plug... ] Toshiya Kobayashi reassigned DROOLS-5231: ----------------------------------------- Assignee: Toshiya Kobayashi (was: Luca Molteni) > Wrong BitMask created by a nested property in modify block > ---------------------------------------------------------- > > Key: DROOLS-5231 > URL: https://issues.redhat.com/browse/DROOLS-5231 > Project: Drools > Issue Type: Bug > Components: executable model > Affects Versions: 7.35.0.Final > Reporter: Toshiya Kobayashi > Assignee: Toshiya Kobayashi > Priority: Major > > When a nested property is modified in modify block like this: > {noformat} > rule R1 > when > $pet : Pet(age == 3) > then > modify ($pet) { getOwner().setLikes("Cookie") }; > end > {noformat} > executable model creates BitMask for "owner" and "likes" thus causes a build error. > {noformat} > [ERROR] testNestedPropInRHS[PATTERN_DSL](org.drools.modelcompiler.PropertyReactivityTest) Time elapsed: 2.702 s <<< ERROR! > java.lang.RuntimeException: Unknown property 'likes' for class class class org.drools.modelcompiler.domain.Pet > at org.drools.test.DomainClassesMetadata9429289867DBA6AE1EE0D6F3F6F68A4D$org_drools_modelcompiler_domain_Pet_Metadata.getPropertyIndex(DomainClassesMetadata9429289867DBA6AE1EE0D6F3F6F68A4D.java:24) > at org.drools.model.bitmask.BitMaskUtil.calculatePatternMask(BitMaskUtil.java:61) > at org.drools.model.BitMask.getPatternMask(BitMask.java:54) > at org.drools.test.Rules9429289867DBA6AE1EE0D6F3F6F68A4DRuleMethods0.rule_R1(Rules9429289867DBA6AE1EE0D6F3F6F68A4DRuleMethods0.java:24) > at org.drools.test.Rules9429289867DBA6AE1EE0D6F3F6F68A4D.getRulesList(Rules9429289867DBA6AE1EE0D6F3F6F68A4D.java:60) > at org.drools.test.Rules9429289867DBA6AE1EE0D6F3F6F68A4D.<init>(Rules9429289867DBA6AE1EE0D6F3F6F68A4D.java:64) > at java.base/jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) > at java.base/jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62) > at java.base/jdk.internal.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45) > at java.base/java.lang.reflect.Constructor.newInstance(Constructor.java:490) > at java.base/java.lang.Class.newInstance(Class.java:584) > at org.drools.modelcompiler.CanonicalKieModule.createInstance(CanonicalKieModule.java:410) > {noformat} -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 3 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-5231) Wrong BitMask created by a nested property in modify block

by Toshiya Kobayashi (Jira)

[ https://issues.redhat.com/browse/DROOLS-5231?page=com.atlassian.jira.plug... ] Toshiya Kobayashi updated DROOLS-5231: -------------------------------------- Description: When a nested property is modified in modify block like this: {noformat} rule R1 when $pet : Pet(age == 3) then modify ($pet) { getOwner().setLikes("Cookie") }; end {noformat} executable model creates BitMask for "owner" and "likes" thus causes a build error. {noformat} [ERROR] testNestedPropInRHS[PATTERN_DSL](org.drools.modelcompiler.PropertyReactivityTest) Time elapsed: 2.702 s <<< ERROR! java.lang.RuntimeException: Unknown property 'likes' for class class class org.drools.modelcompiler.domain.Pet at org.drools.test.DomainClassesMetadata9429289867DBA6AE1EE0D6F3F6F68A4D$org_drools_modelcompiler_domain_Pet_Metadata.getPropertyIndex(DomainClassesMetadata9429289867DBA6AE1EE0D6F3F6F68A4D.java:24) at org.drools.model.bitmask.BitMaskUtil.calculatePatternMask(BitMaskUtil.java:61) at org.drools.model.BitMask.getPatternMask(BitMask.java:54) at org.drools.test.Rules9429289867DBA6AE1EE0D6F3F6F68A4DRuleMethods0.rule_R1(Rules9429289867DBA6AE1EE0D6F3F6F68A4DRuleMethods0.java:24) at org.drools.test.Rules9429289867DBA6AE1EE0D6F3F6F68A4D.getRulesList(Rules9429289867DBA6AE1EE0D6F3F6F68A4D.java:60) at org.drools.test.Rules9429289867DBA6AE1EE0D6F3F6F68A4D.<init>(Rules9429289867DBA6AE1EE0D6F3F6F68A4D.java:64) at java.base/jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) at java.base/jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62) at java.base/jdk.internal.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45) at java.base/java.lang.reflect.Constructor.newInstance(Constructor.java:490) at java.base/java.lang.Class.newInstance(Class.java:584) at org.drools.modelcompiler.CanonicalKieModule.createInstance(CanonicalKieModule.java:410) {noformat} was: When a nested property is modified in modify block like this: {noformat} rule R1 when $pet : Pet(age == 3) then modify ($pet) { getOwner().setLikes("Cookie") }; end {noformat} executable model creates BitMask for "owner" and "likes" thus causes a build error. > Wrong BitMask created by a nested property in modify block > ---------------------------------------------------------- > > Key: DROOLS-5231 > URL: https://issues.redhat.com/browse/DROOLS-5231 > Project: Drools > Issue Type: Bug > Components: executable model > Affects Versions: 7.35.0.Final > Reporter: Toshiya Kobayashi > Assignee: Luca Molteni > Priority: Major > > When a nested property is modified in modify block like this: > {noformat} > rule R1 > when > $pet : Pet(age == 3) > then > modify ($pet) { getOwner().setLikes("Cookie") }; > end > {noformat} > executable model creates BitMask for "owner" and "likes" thus causes a build error. > {noformat} > [ERROR] testNestedPropInRHS[PATTERN_DSL](org.drools.modelcompiler.PropertyReactivityTest) Time elapsed: 2.702 s <<< ERROR! > java.lang.RuntimeException: Unknown property 'likes' for class class class org.drools.modelcompiler.domain.Pet > at org.drools.test.DomainClassesMetadata9429289867DBA6AE1EE0D6F3F6F68A4D$org_drools_modelcompiler_domain_Pet_Metadata.getPropertyIndex(DomainClassesMetadata9429289867DBA6AE1EE0D6F3F6F68A4D.java:24) > at org.drools.model.bitmask.BitMaskUtil.calculatePatternMask(BitMaskUtil.java:61) > at org.drools.model.BitMask.getPatternMask(BitMask.java:54) > at org.drools.test.Rules9429289867DBA6AE1EE0D6F3F6F68A4DRuleMethods0.rule_R1(Rules9429289867DBA6AE1EE0D6F3F6F68A4DRuleMethods0.java:24) > at org.drools.test.Rules9429289867DBA6AE1EE0D6F3F6F68A4D.getRulesList(Rules9429289867DBA6AE1EE0D6F3F6F68A4D.java:60) > at org.drools.test.Rules9429289867DBA6AE1EE0D6F3F6F68A4D.<init>(Rules9429289867DBA6AE1EE0D6F3F6F68A4D.java:64) > at java.base/jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) > at java.base/jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62) > at java.base/jdk.internal.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45) > at java.base/java.lang.reflect.Constructor.newInstance(Constructor.java:490) > at java.base/java.lang.Class.newInstance(Class.java:584) > at org.drools.modelcompiler.CanonicalKieModule.createInstance(CanonicalKieModule.java:410) > {noformat} -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 3 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-5231) Wrong BitMask created by a nested property in modify block

by Toshiya Kobayashi (Jira)

Toshiya Kobayashi created DROOLS-5231: ----------------------------------------- Summary: Wrong BitMask created by a nested property in modify block Key: DROOLS-5231 URL: https://issues.redhat.com/browse/DROOLS-5231 Project: Drools Issue Type: Bug Components: executable model Affects Versions: 7.35.0.Final Reporter: Toshiya Kobayashi Assignee: Luca Molteni When a nested property is modified in modify block like this: {noformat} rule R1 when $pet : Pet(age == 3) then modify ($pet) { getOwner().setLikes("Cookie") }; end {noformat} executable model creates BitMask for "owner" and "likes" thus causes a build error. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 3 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 moved JBERET-492 to WFLY-13357: ------------------------------------------ Project: WildFly (was: JBeret) Key: WFLY-13357 (was: JBERET-492) Component/s: Batch (was: jberet-core) Affects Version/s: 19.0.0.Final (was: 1.3.3.Final) > (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 > Priority: Major > > 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)

6 years, 3 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 reassigned WFLY-13357: --------------------------------- Assignee: Cheng Fang > (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 > > 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)

6 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFLY-13356) Add a Galleon layer for Webservices

by Brian Stansberry (Jira)

Brian Stansberry created WFLY-13356: --------------------------------------- Summary: Add a Galleon layer for Webservices Key: WFLY-13356 URL: https://issues.redhat.com/browse/WFLY-13356 Project: WildFly Issue Type: Feature Request Components: Build System, Web Services Reporter: Brian Stansberry Assignee: Brian Stansberry Fix For: 20.0.0.Beta1 -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFLY-13355) Add a Galleon layer for EE Concurrency

by Brian Stansberry (Jira)

Brian Stansberry created WFLY-13355: --------------------------------------- Summary: Add a Galleon layer for EE Concurrency Key: WFLY-13355 URL: https://issues.redhat.com/browse/WFLY-13355 Project: WildFly Issue Type: Feature Request Components: Build System, Concurrency Utilities Reporter: Brian Stansberry Assignee: Brian Stansberry Minor thing. The existing 'ee' layer adds the EE Concurrency resources, which is fine. Adding a layer specific to ee-concurrency, which the existing ee layer would optionally depend on, would allow users to *exclude* it. Doing so wouldn't do much in terms of disk footprint, probably well under 200K. The main reason I file this is when I provision some slim servers suddenly the amount of config going to the ee concurrency resources jumps out at you. Even if the real impact of those isn't much it gives a sense of bloat. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFLY-13354) Add Galleon layers for the EJB subsystem

by Brian Stansberry (Jira)

Brian Stansberry created WFLY-13354: --------------------------------------- Summary: Add Galleon layers for the EJB subsystem Key: WFLY-13354 URL: https://issues.redhat.com/browse/WFLY-13354 Project: WildFly Issue Type: Feature Request Components: Build System, EJB Reporter: Brian Stansberry Assignee: Cheng Fang -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFLY-13352) Add a Galleon layer for the sar subsystem

by Brian Stansberry (Jira)

Brian Stansberry created WFLY-13352: --------------------------------------- Summary: Add a Galleon layer for the sar subsystem Key: WFLY-13352 URL: https://issues.redhat.com/browse/WFLY-13352 Project: WildFly Issue Type: Feature Request Components: Build System, JMX Reporter: Brian Stansberry Assignee: Brian Stansberry Fix For: 20.0.0.Beta1 -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 3 months

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira April 2020