April 2020 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFLY-13340) Exception in thread "ConnectionValidator" java.lang.IllegalMonitorStateException in server shutdown

by Brian Stansberry (Jira)

[ https://issues.redhat.com/browse/WFLY-13340?page=com.atlassian.jira.plugi... ] Brian Stansberry updated WFLY-13340: ------------------------------------ Fix Version/s: 20.0.0.Beta1 > Exception in thread "ConnectionValidator" java.lang.IllegalMonitorStateException in server shutdown > --------------------------------------------------------------------------------------------------- > > Key: WFLY-13340 > URL: https://issues.redhat.com/browse/WFLY-13340 > Project: WildFly > Issue Type: Bug > Components: JCA > Reporter: Chao Wang > Assignee: Flavia Rainone > Priority: Critical > Fix For: 20.0.0.Beta1 > > > By upgrading IJ to 1.4.21. Final https://issues.redhat.com/browse/WFLY-1324 > There is a constant error in server shutdown > {code:xml} > 12:12:44,713 ERROR [stderr] (ConnectionValidator) Exception in thread "ConnectionValidator" java.lang.IllegalMonitorStateException > 12:12:44,714 ERROR [stderr] (ConnectionValidator) at java.util.concurrent.locks.ReentrantLock$Sync.tryRelease(ReentrantLock.java:151) > 12:12:44,714 ERROR [stderr] (ConnectionValidator) at java.util.concurrent.locks.AbstractQueuedSynchronizer.release(AbstractQueuedSynchronizer.java:1261) > 12:12:44,715 ERROR [stderr] (ConnectionValidator) at java.util.concurrent.locks.ReentrantLock.unlock(ReentrantLock.java:457) > 12:12:44,715 ERROR [stderr] (ConnectionValidator) at org.jboss.jca.core.connectionmanager.pool.validator.ConnectionValidator$ConnectionValidatorRunner.run(ConnectionValidator.java:317) > 12:12:44,715 ERROR [stderr] (ConnectionValidator) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) > 12:12:44,715 ERROR [stderr] (ConnectionValidator) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) > 12:12:44,715 ERROR [stderr] (ConnectionValidator) at java.lang.Thread.run(Thread.java:748) > {code} -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-4907) Expose the ability to add jboss-modules specific arguments

by James Perkins (Jira)

James Perkins created WFCORE-4907: ------------------------------------- Summary: Expose the ability to add jboss-modules specific arguments Key: WFCORE-4907 URL: https://issues.redhat.com/browse/WFCORE-4907 Project: WildFly Core Issue Type: Enhancement Components: Launcher, Scripts Reporter: James Perkins Assignee: James Perkins Currently the scripts have an environment variable {{MODULE_OPTS}} which is used to enable the security manager for JBoss Modules. This variable is not currently allowed to be set yet in the {{*.conf}} files however we could expose it. The need for this comes from WFCORE-4674 where the fix will be to add JBoss Modules as an agent, then add {{-javaagent:some-agent.jar}} to the arguments for JBoss Modules. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-4748) Expose the ability to add jboss-modules specific arguments

by James Perkins (Jira)

[ https://issues.redhat.com/browse/WFCORE-4748?page=com.atlassian.jira.plug... ] James Perkins updated WFCORE-4748: ---------------------------------- Issue Type: Feature Request (was: Enhancement) > Expose the ability to add jboss-modules specific arguments > ---------------------------------------------------------- > > Key: WFCORE-4748 > URL: https://issues.redhat.com/browse/WFCORE-4748 > Project: WildFly Core > Issue Type: Feature Request > Components: Launcher, Scripts > Reporter: James Perkins > Assignee: James Perkins > Priority: Major > > Currently the scripts have an environment variable {{MODULE_OPTS}} which is used to enable the security manager for JBoss Modules. This variable is not currently allowed to be set yet in the {{*.conf}} files however we could expose it. The need for this comes from WFCORE-4674 where the fix will be to add JBoss Modules as an agent, then add {{-javaagent:some-agent.jar}} to the arguments for JBoss Modules. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFLY-13343) Guard against lookup of local user transaction using EJBClient

by Stephen Fikes (Jira)

Stephen Fikes created WFLY-13343: ------------------------------------ Summary: Guard against lookup of local user transaction using EJBClient Key: WFLY-13343 URL: https://issues.redhat.com/browse/WFLY-13343 Project: WildFly Issue Type: Feature Request Components: EJB, Transactions Affects Versions: 19.0.0.Final, 18.0.1.Final Reporter: Stephen Fikes Assignee: Cheng Fang A local UserTransaction instance obtained via EJBClient (which is meant solely for remote access) is non-functional and any use of it will fail subsequently. The lookup attempt should fail immediately with an unambiguous exception to make it clear this is a usage error as the subsequent behavior may be much more difficult to diagnose. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 3 months

1
0
0 / 0

[JBoss JIRA] (JGRP-2461) Clustering can fail when re-adding an existing node using TCP_NIO2

by Bela Ban (Jira)

[ https://issues.redhat.com/browse/JGRP-2461?page=com.atlassian.jira.plugin... ] Bela Ban commented on JGRP-2461: -------------------------------- I thought {{use_ip_addrs}} was a good idea at the time, bit I don't anymore: [1]. If you want to look into this, be my guest but I won't fix it, and this will be removed in 5.0. Sorry, > Clustering can fail when re-adding an existing node using TCP_NIO2 > ------------------------------------------------------------------ > > Key: JGRP-2461 > URL: https://issues.redhat.com/browse/JGRP-2461 > Project: JGroups > Issue Type: Bug > Affects Versions: 4.1.8 > Reporter: Robert Mitchell > Assignee: Bela Ban > Priority: Major > > When a node leaves a cluster and then later attempts to re-enter, a race condition can occur where the clustering fails to occur. Here is the sequence of events that seems to allow this to occur: > # The rejoining node must have a "higher" IP address than the current cluster coordinator. > # On the rejoin attempt, the coordinator sends a message to the rejoining node before the rejoining node sends to the coordinator using its prior address. I have seen this happen for two reasons: > ## UNICAST3 is resending messages (which often happens with the final LEAVE_RSP from the prior cluster membership because it apparently does not get acked before the connection closes) > ## TCPPING is sending a ping request to the cached prior address. > # The connection gets established. It will then be used by the rejoining node whenever communicating with the cluster coordinator. > # However, the cluster coordinator has this as the connection for the prior address. So the following happens whenever it wants to send a message to the rejoining node: > ## It will attempt to create a new connection. > ## The rejoining node will reject the connection as a redundant connection with its current connection taking precedence since it is coming from the same logical address as the "bad" connection. > Since the messages needed to find and join the cluster or merge the two clusters are all unicast messages, the rejoining node will never get them and not be able to join until something happens that causes the initial connection to get closed. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 3 months

1
0
0 / 0

[JBoss JIRA] (JGRP-2465) Remove use_ip_addrs

by Bela Ban (Jira)

Bela Ban created JGRP-2465: ------------------------------ Summary: Remove use_ip_addrs Key: JGRP-2465 URL: https://issues.redhat.com/browse/JGRP-2465 Project: JGroups Issue Type: Task Reporter: Bela Ban Assignee: Bela Ban Fix For: 5.0.0.Alpha4 Remove {{use_ip_addrs}}; nobody uses this and it complicates the code -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 3 months

1
0
0 / 0

[JBoss JIRA] (HIBERNATE-173) Hibernate 6.0.0.Alpha4 has JUnit 5 as compile-time dependency

by Victor Williams Stafusa da Silva (Jira)

[ https://issues.redhat.com/browse/HIBERNATE-173?page=com.atlassian.jira.pl... ] Victor Williams Stafusa da Silva commented on HIBERNATE-173: ------------------------------------------------------------ Sorry for opening up it in the wrong place. Google sent me here. > Hibernate 6.0.0.Alpha4 has JUnit 5 as compile-time dependency > ------------------------------------------------------------- > > Key: HIBERNATE-173 > URL: https://issues.redhat.com/browse/HIBERNATE-173 > Project: Hibernate Integration > Issue Type: Bug > Reporter: Victor Williams Stafusa da Silva > Assignee: Steve Ebersole > Priority: Trivial > > As can evidenced in [mvnrepository|https://mvnrepository.com/artifact/org.hibernate.orm/hibern...], JUnit 5 (org.junit.jupiter:junit-jupiter-engine:5.3.1 and org.junit.vintage:junit-vintage-engine:5.3.1 to be precise) ended up being compile dependencies in Hibernate 6.0.0.Alpha4. They should have a testCompile scope instead. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 3 months

1
0
0 / 0

[JBoss JIRA] (SWSQE-1099) Automate labels https://github.com/kiali/kiali-ui/pull/1686

by Hayk Hovsepyan (Jira)

[ https://issues.redhat.com/browse/SWSQE-1099?page=com.atlassian.jira.plugi... ] Hayk Hovsepyan resolved SWSQE-1099. ----------------------------------- Resolution: Done > Automate labels https://github.com/kiali/kiali-ui/pull/1686 > ----------------------------------------------------------- > > Key: SWSQE-1099 > URL: https://issues.redhat.com/browse/SWSQE-1099 > Project: Kiali QE > Issue Type: QE Task > Reporter: Hayk Hovsepyan > Assignee: Hayk Hovsepyan > Priority: Major > Labels: automation > -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 3 months

1
0
0 / 0

[JBoss JIRA] (SWSQE-1099) Automate labels https://github.com/kiali/kiali-ui/pull/1686

by Hayk Hovsepyan (Jira)

[ https://issues.redhat.com/browse/SWSQE-1099?page=com.atlassian.jira.plugi... ] Hayk Hovsepyan reassigned SWSQE-1099: ------------------------------------- Assignee: Hayk Hovsepyan > Automate labels https://github.com/kiali/kiali-ui/pull/1686 > ----------------------------------------------------------- > > Key: SWSQE-1099 > URL: https://issues.redhat.com/browse/SWSQE-1099 > Project: Kiali QE > Issue Type: QE Task > Reporter: Hayk Hovsepyan > Assignee: Hayk Hovsepyan > Priority: Major > Labels: automation > -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 3 months

1
0
0 / 0

[JBoss JIRA] (SWSQE-1099) Automate labels https://github.com/kiali/kiali-ui/pull/1686

by Hayk Hovsepyan (Jira)

[ https://issues.redhat.com/browse/SWSQE-1099?page=com.atlassian.jira.plugi... ] Hayk Hovsepyan commented on SWSQE-1099: --------------------------------------- https://github.com/Kiali-QE/kiali-qe-python/pull/275 > Automate labels https://github.com/kiali/kiali-ui/pull/1686 > ----------------------------------------------------------- > > Key: SWSQE-1099 > URL: https://issues.redhat.com/browse/SWSQE-1099 > Project: Kiali QE > Issue Type: QE Task > Reporter: Hayk Hovsepyan > Priority: Major > Labels: automation > -- 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