April 2020 - jboss-jira - Jboss List Archives

[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)

5 years, 7 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)

5 years, 7 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)

5 years, 7 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)

5 years, 7 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)

5 years, 7 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)

5 years, 7 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)

5 years, 7 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)

Cheng Fang created WFLY-13416: --------------------------------- Summary: 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 -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 7 months

1
0
0 / 0

[JBoss JIRA] (ELY-1519) Make restore of SecurityIdentity on replicated session configurable

by Farah Juma (Jira)

[ https://issues.redhat.com/browse/ELY-1519?page=com.atlassian.jira.plugin.... ] Farah Juma updated ELY-1519: ---------------------------- Fix Version/s: 1.12.0.CR1 > Make restore of SecurityIdentity on replicated session configurable > ------------------------------------------------------------------- > > Key: ELY-1519 > URL: https://issues.redhat.com/browse/ELY-1519 > Project: WildFly Elytron > Issue Type: Bug > Components: Authentication Mechanisms > Affects Versions: 1.2.0.Final > Reporter: Martin Choma > Assignee: Ilia Vassilev > Priority: Major > Fix For: 1.12.0.CR1 > > > Currently in clustered environment Security Identity is restored during > * failover > * load balancer change node (not sticky behaviour) > * session passivation/activation > This is mainly expected and good. It ensures performance gain because no additional SPNEGO negotiation is performed. But it can make troubles for kerberos ticket propagation, as kerberos ticket can't be serialized and restored. > So idea is to have flag to turn this default behaviour off. When user authenticate to app1 on serverA and then wants to access app1 on serverB, SPNEGO authentication will be activated and kerberos ticket will be negotiated and will be available on serverB as well. -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 7 months

1
0
0 / 0

[JBoss JIRA] (ELY-1838) Differentiate actions and parameters

by Farah Juma (Jira)

[ https://issues.redhat.com/browse/ELY-1838?page=com.atlassian.jira.plugin.... ] Farah Juma updated ELY-1838: ---------------------------- Fix Version/s: 1.12.0.CR1 > Differentiate actions and parameters > ------------------------------------ > > Key: ELY-1838 > URL: https://issues.redhat.com/browse/ELY-1838 > Project: WildFly Elytron > Issue Type: Feature Request > Components: Command-Line Tool, Credential Store > Reporter: Darran Lofthouse > Assignee: Ilia Vassilev > Priority: Major > Fix For: 1.12.0.CR1 > > > The help information in the tool lists all parameters for a specific command, however some are general parameters and some are mutually exclusive actions - the output from the tool should make this distinction clear. -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 7 months

1
0
0 / 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira April 2020