November 2018 - jboss-jira - Jboss List Archives

[JBoss JIRA] (DROOLS-3324) Update persistence.xml with properties needed for Narayana

by Tibor Zimányi (Jira)

[ https://issues.jboss.org/browse/DROOLS-3324?page=com.atlassian.jira.plugi... ] Tibor Zimányi updated DROOLS-3324: ---------------------------------- Priority: Blocker (was: Major) > Update persistence.xml with properties needed for Narayana > ---------------------------------------------------------- > > Key: DROOLS-3324 > URL: https://issues.jboss.org/browse/DROOLS-3324 > Project: Drools > Issue Type: Bug > Components: core engine > Affects Versions: 7.14.0.Final > Reporter: Tibor Zimányi > Assignee: Tibor Zimányi > Priority: Blocker > Fix For: 7.15.0.Final > > > With Narayana changes there is a need for additional properties in persistence.xml file from drools-persistence-jpa module. -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 8 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-3331) Update persistence.xml with properties needed for Narayana

by Tibor Zimányi (Jira)

Tibor Zimányi created DROOLS-3331: ------------------------------------- Summary: Update persistence.xml with properties needed for Narayana Key: DROOLS-3331 URL: https://issues.jboss.org/browse/DROOLS-3331 Project: Drools Issue Type: Bug Components: core engine Affects Versions: 7.14.0.Final Reporter: Tibor Zimányi Assignee: Tibor Zimányi Fix For: 7.15.0.Final With Narayana changes there is a need for additional properties in persistence.xml file from drools-persistence-jpa module. -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFLY-11198) Session draining on stopped worker won't complete if further requests are made on balancer

by Jan Kašík (Jira)

[ https://issues.jboss.org/browse/WFLY-11198?page=com.atlassian.jira.plugin... ] Jan Kašík commented on WFLY-11198: ---------------------------------- [~rhusar] I attached logs with modcluster's debug output from a case where I hit this issue. Nodes 1-3 are cluster nodes. Node 5 is a balancer. > Session draining on stopped worker won't complete if further requests are made on balancer > ------------------------------------------------------------------------------------------ > > Key: WFLY-11198 > URL: https://issues.jboss.org/browse/WFLY-11198 > Project: WildFly > Issue Type: Bug > Components: mod_cluster > Affects Versions: 15.0.0.Beta1 > Reporter: Jan Kašík > Assignee: Radoslav Husar > Priority: Major > Attachments: logs.zip > > > When disabling worker with {{/subsystem=modcluster/proxy=default:stop(waittime=0)}}, the contexts are switched to {{disabled}} state. If there no further requests (on the same context which session currently times out) are made on a balancer, session correctly times out, contexts switch to {{stopped}} state and everything is OK. > However, when I run same stop operation, wait until contexts are switched into {{disabled}} state and in time in which sessions time out I make more requests on balancer, contexts will never switch to {{stopped}} state and session draining never completes. This happens intermittently (~60% of cases with 10 requests made after {{disabled}} state is in place). -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFLY-11198) Session draining on stopped worker won't complete if further requests are made on balancer

by Jan Kašík (Jira)

[ https://issues.jboss.org/browse/WFLY-11198?page=com.atlassian.jira.plugin... ] Jan Kašík updated WFLY-11198: ----------------------------- Attachment: logs.zip > Session draining on stopped worker won't complete if further requests are made on balancer > ------------------------------------------------------------------------------------------ > > Key: WFLY-11198 > URL: https://issues.jboss.org/browse/WFLY-11198 > Project: WildFly > Issue Type: Bug > Components: mod_cluster > Affects Versions: 15.0.0.Beta1 > Reporter: Jan Kašík > Assignee: Radoslav Husar > Priority: Major > Attachments: logs.zip > > > When disabling worker with {{/subsystem=modcluster/proxy=default:stop(waittime=0)}}, the contexts are switched to {{disabled}} state. If there no further requests (on the same context which session currently times out) are made on a balancer, session correctly times out, contexts switch to {{stopped}} state and everything is OK. > However, when I run same stop operation, wait until contexts are switched into {{disabled}} state and in time in which sessions time out I make more requests on balancer, contexts will never switch to {{stopped}} state and session draining never completes. This happens intermittently (~60% of cases with 10 requests made after {{disabled}} state is in place). -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFLY-11371) [EAT] : Make resources distributable.

by Panagiotis Sotiropoulos (Jira)

[ https://issues.jboss.org/browse/WFLY-11371?page=com.atlassian.jira.plugin... ] Panagiotis Sotiropoulos moved JBEAP-15862 to WFLY-11371: -------------------------------------------------------- Project: WildFly (was: JBoss Enterprise Application Platform) Key: WFLY-11371 (was: JBEAP-15862) Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1) Component/s: Test Suite (was: Test Suite) > [EAT] : Make resources distributable. > ------------------------------------- > > Key: WFLY-11371 > URL: https://issues.jboss.org/browse/WFLY-11371 > Project: WildFly > Issue Type: Task > Components: Test Suite > Reporter: Panagiotis Sotiropoulos > Assignee: Panagiotis Sotiropoulos > Priority: Major > > All the resources should be distributable in order to be used multiple times for different test sets. -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFLY-11370) [GSS](7.1.z) Lock is not released when JTS is enabled and a timer is cancelled inside a transaction

by Brad Maxwell (Jira)

Brad Maxwell created WFLY-11370: ----------------------------------- Summary: [GSS](7.1.z) Lock is not released when JTS is enabled and a timer is cancelled inside a transaction Key: WFLY-11370 URL: https://issues.jboss.org/browse/WFLY-11370 Project: WildFly Issue Type: Bug Components: EJB Environment: EAP 6.4.18 Reporter: Brad Maxwell Description of problem: Lock is held by EJB timer (TimerServiceImpl) and in case JTS transaction is cancelled the lock won't be released correctly . This code is the problem: https://github.com/wildfly/wildfly/blob/78dee79dd0f49c6cbd2b8db5d8640980f... Basically it holds the timer lock until the transaction completes, and then attempts to release it in afterCompletion. The problem is that when JTS is enabled afterCompletion will be called by a seperate thread, which can't call unlock as it is not the owner. A simple fix could be to just change the lock to a semaphore, so that the other thread can release it. Version-Release number of selected component (if applicable): How reproducible: Always Steps to Reproduce: 1. Start a JTA/JTS tx and call an EJB timer inside it 2. Make the transaction timeout 3. Capture a thread dump and see a thread like below (0a0818b80 is locked object) --------------------------------------------------------------------------------------------------------- "Incoming-2,RouterPoliciesClusterGroup,svc-3-comecimpolicy-59228 (, payload=52 bytes)" #661 prio=5 os_prio=0 tid=0x00007f5214c2d000 nid=0x1e67 waiting on condition [0x00007f520ac97000] java.lang.Thread.State: WAITING (parking) at sun.misc.Unsafe.park(Native Method) - parking to wait for <0x00000000a0818b80> (a java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject) at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175) at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2039) at java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:442) at java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1074) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1134) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) at java.lang.Thread.run(Thread.java:748) Locked ownable synchronizers: - <0x00000000ea1f4c48> (a java.util.concurrent.locks.ReentrantLock$NonfairSync) --------------------------------------------------------------------------------------------------------- Actual results: Lock being held forever Expected results: Lock getting released -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFLY-11262) violation of call-by-value if a outbound connection is configured

by Flavia Rainone (Jira)

[ https://issues.jboss.org/browse/WFLY-11262?page=com.atlassian.jira.plugin... ] Flavia Rainone reassigned WFLY-11262: ------------------------------------- Assignee: Flavia Rainone > violation of call-by-value if a outbound connection is configured > ----------------------------------------------------------------- > > Key: WFLY-11262 > URL: https://issues.jboss.org/browse/WFLY-11262 > Project: WildFly > Issue Type: Bug > Components: EJB > Reporter: Wolf-Dieter Fink > Assignee: Flavia Rainone > Priority: Blocker > Labels: Regression, spec_violation > > If the server default configuration is used an EJB invocation via @Remote interface is, according to the specification, with call-by-value. > But if the application is configured with jboss-ejb-client.xml to have a remote-outbound-connection the EJB invocation via @Remote is done as call-by-reference no matter whether the configuration is default or > <in-vm-remote-interface-invocation pass-by-value="true"/> > is used. > This is a violation of the specification and can cause serious unexpected issues at runtime for the application if the parameters or return values are mutable -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFLY-11369) violation of call-by-value if a outbound connection is configured

by Flavia Rainone (Jira)

[ https://issues.jboss.org/browse/WFLY-11369?page=com.atlassian.jira.plugin... ] Flavia Rainone deleted WFLY-11369: ---------------------------------- > violation of call-by-value if a outbound connection is configured > ----------------------------------------------------------------- > > Key: WFLY-11369 > URL: https://issues.jboss.org/browse/WFLY-11369 > Project: WildFly > Issue Type: Bug > Reporter: Flavia Rainone > Assignee: Flavia Rainone > Priority: Blocker > > If the server default configuration is used an EJB invocation via @Remote interface is, according to the specification, with call-by-value. > But if the application is configured with jboss-ejb-client.xml to have a remote-outbound-connection the EJB invocation via @Remote is done as call-by-reference no matter whether the configuration is default or > <in-vm-remote-interface-invocation pass-by-value="true"/> > is used when it invokes an inVM EJB. > This is a violation of the specification and can cause serious unexpected issues at runtime for the application if the parameters or return values are mutable -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFLY-11369) violation of call-by-value if a outbound connection is configured

by Flavia Rainone (Jira)

Flavia Rainone created WFLY-11369: ------------------------------------- Summary: violation of call-by-value if a outbound connection is configured Key: WFLY-11369 URL: https://issues.jboss.org/browse/WFLY-11369 Project: WildFly Issue Type: Bug Components: EJB Reporter: Flavia Rainone Assignee: Flavia Rainone Fix For: 15.0.0.CR1 If the server default configuration is used an EJB invocation via @Remote interface is, according to the specification, with call-by-value. But if the application is configured with jboss-ejb-client.xml to have a remote-outbound-connection the EJB invocation via @Remote is done as call-by-reference no matter whether the configuration is default or <in-vm-remote-interface-invocation pass-by-value="true"/> is used when it invokes an inVM EJB. This is a violation of the specification and can cause serious unexpected issues at runtime for the application if the parameters or return values are mutable -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 8 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-3287) [DMN Designer] Enable DMN editor by default in distributions

by Michael Anstis (Jira)

[ https://issues.jboss.org/browse/DROOLS-3287?page=com.atlassian.jira.plugi... ] Michael Anstis commented on DROOLS-3287: ---------------------------------------- [~dadossan] Yes please. > [DMN Designer] Enable DMN editor by default in distributions > ------------------------------------------------------------ > > Key: DROOLS-3287 > URL: https://issues.jboss.org/browse/DROOLS-3287 > Project: Drools > Issue Type: Feature Request > Components: DMN Editor > Affects Versions: 7.14.0.Final > Reporter: Michael Anstis > Assignee: Daniel José dos Santos > Priority: Critical > Labels: drools-tools > Attachments: screenshot-1.png > > > The DMN Editor needs to be _enabled_ by default in the workbench distributions. > This needs to be accomplished for _product_ 7.4. > Priority set to _critical_ so we don't loose sight of it! > See https://issues.jboss.org/browse/DROOLS-2748 (and reverse it!) -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 8 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 November 2018