August 2019 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFLY-2732) Injected EJB not available to MDB @PreDestroy methods

by RH Bugzilla Integration (Jira)

[ https://issues.jboss.org/browse/WFLY-2732?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on WFLY-2732: ----------------------------------------------- Jan Kurik <jkurik(a)redhat.com> changed the Status of [bug 1060722|https://bugzilla.redhat.com/show_bug.cgi?id=1060722] from VERIFIED to CLOSED > Injected EJB not available to MDB @PreDestroy methods > ----------------------------------------------------- > > Key: WFLY-2732 > URL: https://issues.jboss.org/browse/WFLY-2732 > Project: WildFly > Issue Type: Bug > Components: EJB > Affects Versions: 8.0.0.CR1 > Reporter: Mustafa Musaji > Assignee: Stuart Douglas > Priority: Major > Fix For: 8.0.0.Final > > Attachments: MDBLifeCycleJAR.zip > > > MDB with method annotated with @PreDestroy and injected EJB. In this method we are calling an EJB. When the application is undeployed the PreDestroy method is called but it fails on the call to the injected EJB as it's already been undeployed. > This was fixed in an RFE for Session Beans but does not seem to work for MDB. -- This message was sent by Atlassian Jira (v7.12.1#712002)

6 years, 9 months

1
0
0 / 0

[JBoss JIRA] (SWSQE-912) Improve clean evn job to always clean all controll planes

by Filip Brychta (Jira)

Filip Brychta created SWSQE-912: ----------------------------------- Summary: Improve clean evn job to always clean all controll planes Key: SWSQE-912 URL: https://issues.jboss.org/browse/SWSQE-912 Project: Kiali QE Issue Type: QE Task Reporter: Filip Brychta When we have cluster with more control planes and then we start upstream pipeline with just one control plane the clean env job is stuck on deleting operator. We need to clean everything before installing new control plane. -- This message was sent by Atlassian Jira (v7.12.1#712002)

6 years, 9 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-4384) Fix LeaderElection problems introduced with supported dependencies

by Massimiliano Dessi (Jira)

[ https://issues.jboss.org/browse/DROOLS-4384?page=com.atlassian.jira.plugi... ] Massimiliano Dessi edited comment on DROOLS-4384 at 8/2/19 2:39 AM: -------------------------------------------------------------------- Fabric8 k8s client in case of error fails silently, no exception, no log, simply stop the execution and the thread wait, the error could see with debug remote on openshift using the evaluate when the ConfigMaps are created with the builders or when k8s client try to replace the configmap. The error is the lack of the validation dependencies not required by the k8s client but used for the validation internally. !Istantanea_2019-08-01_18-42-24.png|thumbnail! https://github.com/kiegroup/openshift-drools-hacep/pull/17/commits/1b9065... was (Author: mdessi): Fabric8 k8s client in case of error fails silently, no exception, no log, simply stop the execution and the thread wait, the error could see with debug remote on openshift using the evaluate when the ConfigMaps are created with the builders or when k8s client try to replace the configmap. The error is the lack of the validation dependencies not required by the k8s client but used for the validation internally. !Istantanea_2019-08-01_18-42-24.png|thumbnail! > Fix LeaderElection problems introduced with supported dependencies > ------------------------------------------------------------------ > > Key: DROOLS-4384 > URL: https://issues.jboss.org/browse/DROOLS-4384 > Project: Drools > Issue Type: Task > Reporter: Massimiliano Dessi > Assignee: Massimiliano Dessi > Priority: Major > Attachments: Istantanea_2019-08-01_18-42-24.png > > -- This message was sent by Atlassian Jira (v7.12.1#712002)

6 years, 9 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-4384) Fix LeaderElection problems introduced with supported dependencies

by Massimiliano Dessi (Jira)

[ https://issues.jboss.org/browse/DROOLS-4384?page=com.atlassian.jira.plugi... ] Massimiliano Dessi commented on DROOLS-4384: -------------------------------------------- Fabric8 k8s client in case of error fails silently, no exception, no log, simply stop the execution and the thread wait, the error could see with debug remote on openshift using the evaluate when the ConfigMaps are created with the builders or when k8s client try to replace the configmap. The error is the lack of the validation dependencies not required by the k8s client but used for the validation internally. !Istantanea_2019-08-01_18-42-24.png|thumbnail! > Fix LeaderElection problems introduced with supported dependencies > ------------------------------------------------------------------ > > Key: DROOLS-4384 > URL: https://issues.jboss.org/browse/DROOLS-4384 > Project: Drools > Issue Type: Task > Reporter: Massimiliano Dessi > Assignee: Massimiliano Dessi > Priority: Major > Attachments: Istantanea_2019-08-01_18-42-24.png > > -- This message was sent by Atlassian Jira (v7.12.1#712002)

6 years, 9 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-4384) Fix LeaderElection problems introduced with supported dependencies

by Massimiliano Dessi (Jira)

[ https://issues.jboss.org/browse/DROOLS-4384?page=com.atlassian.jira.plugi... ] Massimiliano Dessi updated DROOLS-4384: --------------------------------------- Attachment: Istantanea_2019-08-01_18-42-24.png > Fix LeaderElection problems introduced with supported dependencies > ------------------------------------------------------------------ > > Key: DROOLS-4384 > URL: https://issues.jboss.org/browse/DROOLS-4384 > Project: Drools > Issue Type: Task > Reporter: Massimiliano Dessi > Assignee: Massimiliano Dessi > Priority: Major > Attachments: Istantanea_2019-08-01_18-42-24.png > > -- This message was sent by Atlassian Jira (v7.12.1#712002)

6 years, 9 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-4384) Fix LeaderElection problems introduced with supported dependencies

by Massimiliano Dessi (Jira)

[ https://issues.jboss.org/browse/DROOLS-4384?page=com.atlassian.jira.plugi... ] Massimiliano Dessi updated DROOLS-4384: --------------------------------------- Sprint: 2019 Week 29-31 > Fix LeaderElection problems introduced with supported dependencies > ------------------------------------------------------------------ > > Key: DROOLS-4384 > URL: https://issues.jboss.org/browse/DROOLS-4384 > Project: Drools > Issue Type: Task > Reporter: Massimiliano Dessi > Assignee: Massimiliano Dessi > Priority: Major > -- This message was sent by Atlassian Jira (v7.12.1#712002)

6 years, 9 months

1
0
0 / 0

[JBoss JIRA] (JGRP-2350) TCP: connection close can block when send() block on full TCP send-window

by Martin Stefanko (Jira)

[ https://issues.jboss.org/browse/JGRP-2350?page=com.atlassian.jira.plugin.... ] Martin Stefanko updated JGRP-2350: ---------------------------------- Labels: downstream_dependency (was: ) > TCP: connection close can block when send() block on full TCP send-window > ------------------------------------------------------------------------- > > Key: JGRP-2350 > URL: https://issues.jboss.org/browse/JGRP-2350 > Project: JGroups > Issue Type: Bug > Reporter: Bela Ban > Assignee: Bela Ban > Priority: Major > Labels: downstream_dependency > Fix For: 4.1.1, 4.0.20 > > > When a peer is non-responsive (without closing its socket), a TcpConnection.send() can block on a write (state is RUNNABLE!). > The problem is that the TcpConnection cannout be closed either, as TcpConnection.close() tries to acquire the same lock already held by TcpConnection.send(). > See the stack trace below for a sample scenario. > The use case is this one: > * Say we have nodes A (coord), B and C > * There's heavy (clustering) traffic to all 3 nodes, from the 2 clients > * B is isolated by executing 'ifdown bond0' > * At this point, the messages going to B will back up at (say) A because A doesn't get any TCP acks from B > * At some point, depending on the traffic and the size of the sent messages, A will acquire a lock on the send connection to B, to write data, but the write will block as the TCP send-window to B is full (note that the sender thread will still be in state RUNNABLE!) > * After 40s, A suspects B and emits a new view {A,C} > * This causes A's connection to B to be closed and subsequently removed. However, this _won't_ happen, as the connection close will need to acquire the connection lock, which is held by the TCP write > {noformat} > "main" #1 prio=5 os_prio=31 tid=0x00007fbbd3802000 nid=0x2303 runnable [0x0000700009793000] > java.lang.Thread.State: RUNNABLE > at java.net.SocketOutputStream.socketWrite0(Native Method) > at java.net.SocketOutputStream.socketWrite(SocketOutputStream.java:111) > at java.net.SocketOutputStream.write(SocketOutputStream.java:155) > at java.io.BufferedOutputStream.write(BufferedOutputStream.java:122) > - locked <0x000000079e790a50> (a java.io.BufferedOutputStream) > at java.io.DataOutputStream.write(DataOutputStream.java:107) > - locked <0x000000079e790838> (a java.io.DataOutputStream) > at org.jgroups.blocks.cs.TcpConnection.doSend(TcpConnection.java:161) > at org.jgroups.blocks.cs.TcpConnection.send(TcpConnection.java:131) > at org.jgroups.blocks.cs.TcpClient.send(TcpClient.java:103) > at org.jgroups.tests.bla6.main(bla6.java:35) > "Thread-2" #15 prio=5 os_prio=31 tid=0x00007fbbd2150800 nid=0x6503 waiting on condition [0x000070000bcf6000] > java.lang.Thread.State: WAITING (parking) > at sun.misc.Unsafe.park(Native Method) > - parking to wait for <0x000000079e7871a8> (a java.util.concurrent.locks.ReentrantLock$NonfairSync) > at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175) > at java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:836) > at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireQueued(AbstractQueuedSynchronizer.java:870) > at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquire(AbstractQueuedSynchronizer.java:1199) > at java.util.concurrent.locks.ReentrantLock$NonfairSync.lock(ReentrantLock.java:209) > at java.util.concurrent.locks.ReentrantLock.lock(ReentrantLock.java:285) > at org.jgroups.blocks.cs.TcpConnection.close(TcpConnection.java:358) > at org.jgroups.util.Util.close(Util.java:422) > at org.jgroups.blocks.cs.TcpClient.stop(TcpClient.java:85) > at org.jgroups.blocks.cs.BaseServer.close(BaseServer.java:147) > at org.jgroups.util.Util.close(Util.java:422) > at org.jgroups.tests.bla6.lambda$main$0(bla6.java:27) > at org.jgroups.tests.bla6$$Lambda$1/1384010761.run(Unknown Source) > at java.lang.Thread.run(Thread.java:748) > {noformat} -- This message was sent by Atlassian Jira (v7.12.1#712002)

6 years, 9 months

1
0
0 / 0

[JBoss JIRA] (WFLY-11864) Only one JSF Validator is invoked when defined via annotation @FacesValidator

by Chao Wang (Jira)

[ https://issues.jboss.org/browse/WFLY-11864?page=com.atlassian.jira.plugin... ] Chao Wang resolved WFLY-11864. ------------------------------ Resolution: Done > Only one JSF Validator is invoked when defined via annotation @FacesValidator > ----------------------------------------------------------------------------- > > Key: WFLY-11864 > URL: https://issues.jboss.org/browse/WFLY-11864 > Project: WildFly > Issue Type: Bug > Components: JSF > Affects Versions: 16.0.0.Final > Reporter: Chao Wang > Assignee: Chao Wang > Priority: Major > Labels: downstream_dependency > > Only one JSF Validator is invoked when defined via annotation @FacesValidator > {code} > @FacesValidator(value = "validator.CustomValidator1", managed = true) > public class CustomValidator1 implements Validator<String> { > ... > } > @FacesValidator(value = "validator.CustomValidator2", managed = true) > public class CustomValidator2 implements Validator<String> { > ... > } > {code} > {code} > <h:inputText id="input-value" value="#{customBean.inputValue}"> > <f:validator validatorId="validator.CustomValidator2" /> > <f:validator validatorId="validator.CustomValidator1" /> > </h:inputText> > {code} -- This message was sent by Atlassian Jira (v7.12.1#712002)

6 years, 9 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-4578) Upgrade jboss-logmanager from 2.1.13 to 2.1.14.Final

by Chao Wang (Jira)

[ https://issues.jboss.org/browse/WFCORE-4578?page=com.atlassian.jira.plugi... ] Chao Wang resolved WFCORE-4578. ------------------------------- Resolution: Duplicate Issue > Upgrade jboss-logmanager from 2.1.13 to 2.1.14.Final > ---------------------------------------------------- > > Key: WFCORE-4578 > URL: https://issues.jboss.org/browse/WFCORE-4578 > Project: WildFly Core > Issue Type: Component Upgrade > Components: Logging > Affects Versions: 10.0.0.Beta2 > Reporter: Chao Wang > Assignee: Chao Wang > Priority: Major > -- This message was sent by Atlassian Jira (v7.12.1#712002)

6 years, 9 months

1
0
0 / 0

[JBoss JIRA] (SWSQE-911) Maistra - Create RC1 Polarion PQI reports

by Sunil Kondkar (Jira)

Sunil Kondkar created SWSQE-911: ----------------------------------- Summary: Maistra - Create RC1 Polarion PQI reports Key: SWSQE-911 URL: https://issues.jboss.org/browse/SWSQE-911 Project: Kiali QE Issue Type: QE Task Reporter: Sunil Kondkar Get PQI reports for Maistra: 1) Check Test case Quality Audit report(No missing data) 2) PQI reports - Create RC1 test iteration, link this iteration to Maistra RC1 test runs -- This message was sent by Atlassian Jira (v7.12.1#712002)

6 years, 9 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 August 2019