July 2014 - jboss-jira - Jboss List Archives

[JBoss JIRA] (JBJCA-1110) Pool statistics are not cleared

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/JBJCA-1110?page=com.atlassian.jira.plugin... ] RH Bugzilla Integration commented on JBJCA-1110: ------------------------------------------------ Martin Simka <msimka(a)redhat.com> changed the Status of [bug 1081058|https://bugzilla.redhat.com/show_bug.cgi?id=1081058] from ON_QA to VERIFIED > Pool statistics are not cleared > ------------------------------- > > Key: JBJCA-1110 > URL: https://issues.jboss.org/browse/JBJCA-1110 > Project: IronJacamar > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Core > Affects Versions: 1.0.19.Final > Reporter: Koen Janssens > Assignee: Jesper Pedersen > Fix For: 1.1.2.Final > > > Invoking the 'clear statistics' JMX method on a connection pool has no effect. > Quite annoying since it forces me to restart to get a useful value for the 'average' values such as 'averageblockingtime' > Better implement the method or don't provide a clear method at all. > Today, org.jboss.jca.core.connectionmanager.pool.mcp.ManagedConnectionPoolStatisticsImpl#clear is a no-op... -- This message was sent by Atlassian JIRA (v6.2.6#6264)

11 years, 9 months

1
0
0 / 0

[JBoss JIRA] (JBJCA-1159) ConnectionListener leaked if TSR throws IllegalStateException

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/JBJCA-1159?page=com.atlassian.jira.plugin... ] RH Bugzilla Integration commented on JBJCA-1159: ------------------------------------------------ Vaclav Tunka <vtunka(a)redhat.com> changed the Status of [bug 1081058|https://bugzilla.redhat.com/show_bug.cgi?id=1081058] from ASSIGNED to ON_QA > ConnectionListener leaked if TSR throws IllegalStateException > ------------------------------------------------------------- > > Key: JBJCA-1159 > URL: https://issues.jboss.org/browse/JBJCA-1159 > Project: IronJacamar > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Core > Affects Versions: 1.0.24.Final, 1.1.4.Final > Environment: AS7 EAP6.1 > Reporter: Koen Janssens > Assignee: Jesper Pedersen > Priority: Blocker > Fix For: 1.0.25.Final, 1.1.5.Final, 1.2.0.Beta1 > > > When a connection is retrieved from the MCP, ironjacamar will register it to ongoing JTA transaction. However, if the ongoing TX is not 'active' anymore the connection is lost. > The code of AbstractPool demonstrates the problem. The call to getLock will throw an exception if the current TX is not active anymore and the cl is not returned to the pool. > This issue can be reproduced on AS7 by using any EJB that requires a tx and does something with a DB connection. Put a breakpoint in the code below after retrieving the connectionlistener, and then wait for the transaction to timeout. Once that's done, continue the thread. The connection is not release (can be seen in JMX) > We have noticed this problem regularly during our performance tests. > {code} > ConnectionListener cl = mcp.getConnection(subject, cri); > if (trace) > log.tracef("Got connection from pool tracked by transaction=%s tx=%s", cl, trackByTransaction); > TransactionSynchronizationRegistry tsr = getTransactionSynchronizationRegistry(); > Lock lock = getLock(); > try > { > lock.lockInterruptibly(); > } > catch (InterruptedException ie) > { > Thread.interrupted(); > throw new ResourceException(bundle.unableObtainLock(), ie); > } > {code} > It seems this issue was introduced by changes done for https://issues.jboss.org/browse/JBJCA-572 -- This message was sent by Atlassian JIRA (v6.2.6#6264)

11 years, 9 months

1
0
0 / 0

[JBoss JIRA] (JBJCA-1161) NPE in SemaphoreArrayListManagedConnectionPool

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/JBJCA-1161?page=com.atlassian.jira.plugin... ] RH Bugzilla Integration commented on JBJCA-1161: ------------------------------------------------ Vaclav Tunka <vtunka(a)redhat.com> changed the Status of [bug 1081058|https://bugzilla.redhat.com/show_bug.cgi?id=1081058] from ASSIGNED to ON_QA > NPE in SemaphoreArrayListManagedConnectionPool > ---------------------------------------------- > > Key: JBJCA-1161 > URL: https://issues.jboss.org/browse/JBJCA-1161 > Project: IronJacamar > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Core > Affects Versions: 1.0.25.Final > Reporter: Jesper Pedersen > Assignee: Jesper Pedersen > Priority: Blocker > Fix For: 1.0.26.Final > > > {noformat} > at org.jboss.jca.core.connectionmanager.pool.mcp.SemaphoreArrayListManagedConnectionPool.doDestroy(SemaphoreArrayListManagedConnectionPool.java:866) > at org.jboss.jca.core.connectionmanager.pool.mcp.SemaphoreArrayListManagedConnectionPool.getConnection(SemaphoreArrayListManagedConnectionPool.java:312) > at org.jboss.jca.core.connectionmanager.pool.AbstractPool.getSimpleConnection(AbstractPool.java:404) > {noformat} -- This message was sent by Atlassian JIRA (v6.2.6#6264)

11 years, 9 months

1
0
0 / 0

[JBoss JIRA] (JBJCA-1110) Pool statistics are not cleared

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/JBJCA-1110?page=com.atlassian.jira.plugin... ] RH Bugzilla Integration commented on JBJCA-1110: ------------------------------------------------ Vaclav Tunka <vtunka(a)redhat.com> changed the Status of [bug 1081058|https://bugzilla.redhat.com/show_bug.cgi?id=1081058] from ASSIGNED to ON_QA > Pool statistics are not cleared > ------------------------------- > > Key: JBJCA-1110 > URL: https://issues.jboss.org/browse/JBJCA-1110 > Project: IronJacamar > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Core > Affects Versions: 1.0.19.Final > Reporter: Koen Janssens > Assignee: Jesper Pedersen > Fix For: 1.1.2.Final > > > Invoking the 'clear statistics' JMX method on a connection pool has no effect. > Quite annoying since it forces me to restart to get a useful value for the 'average' values such as 'averageblockingtime' > Better implement the method or don't provide a clear method at all. > Today, org.jboss.jca.core.connectionmanager.pool.mcp.ManagedConnectionPoolStatisticsImpl#clear is a no-op... -- This message was sent by Atlassian JIRA (v6.2.6#6264)

11 years, 9 months

1
0
0 / 0

[JBoss JIRA] (JGRP-1864) UDP unable to bind to ephemeral port: port out of range:65536

by Bela Ban (JIRA)

[ https://issues.jboss.org/browse/JGRP-1864?page=com.atlassian.jira.plugin.... ] Bela Ban updated JGRP-1864: --------------------------- Fix Version/s: 3.4.5 > UDP unable to bind to ephemeral port: port out of range:65536 > ------------------------------------------------------------- > > Key: JGRP-1864 > URL: https://issues.jboss.org/browse/JGRP-1864 > Project: JGroups > Issue Type: Bug > Security Level: Public(Everyone can see) > Affects Versions: 3.4.4 > Reporter: Dan Berindei > Assignee: Bela Ban > Priority: Minor > Fix For: 3.4.5, 3.5 > > > It looks like {{UDP.createEphemeralDatagramSocket()}} swallows any errors it gets while creating the socket, and throws this exception after trying to bind to all ports in the 0 - 65535 range: > {noformat} > java.lang.IllegalArgumentException: port out of range:65536 > at java.net.InetSocketAddress.checkPort(InetSocketAddress.java:143) > at java.net.InetSocketAddress.<init>(InetSocketAddress.java:185) > at java.net.DatagramSocket.<init>(DatagramSocket.java:284) > at org.jgroups.util.DefaultSocketFactory.createDatagramSocket(DefaultSocketFactory.java:62) > at org.jgroups.protocols.UDP.createEphemeralDatagramSocket(UDP.java:429) > at org.jgroups.protocols.UDP.createSockets(UDP.java:311) > at org.jgroups.protocols.UDP.start(UDP.java:216) > at org.jgroups.stack.ProtocolStack.startStack(ProtocolStack.java:966) > at org.jgroups.JChannel.startStack(JChannel.java:889) > at org.jgroups.JChannel._preConnect(JChannel.java:547) > at org.jgroups.JChannel.connect(JChannel.java:282) > at org.jgroups.JChannel.connect(JChannel.java:273) > at org.infinispan.remoting.transport.jgroups.JGroupsTransport.startJGroupsChannelIfNeeded(JGroupsTransport.java:200) > {noformat} -- This message was sent by Atlassian JIRA (v6.2.6#6264)

11 years, 9 months

1
0
0 / 0

[JBoss JIRA] (WFLY-3621) Invalid behavior of FormAuthUnitTestCase testPostDataFormAuth causing it to pass even when it should fail

by Radim Hatlapatka (JIRA)

[ https://issues.jboss.org/browse/WFLY-3621?page=com.atlassian.jira.plugin.... ] Radim Hatlapatka updated WFLY-3621: ----------------------------------- Fix Version/s: 9.0.0.Beta1 > Invalid behavior of FormAuthUnitTestCase testPostDataFormAuth causing it to pass even when it should fail > --------------------------------------------------------------------------------------------------------- > > Key: WFLY-3621 > URL: https://issues.jboss.org/browse/WFLY-3621 > Project: WildFly > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Test Suite > Reporter: Radim Hatlapatka > Assignee: Radim Hatlapatka > Fix For: 9.0.0.Beta1 > > > FormAuthUnitTestCase testPostDataFormAuth passes even though it should fail. Due typo it redirects to original URL instead of the one retrieved from header resulting in invalid behaviour. -- This message was sent by Atlassian JIRA (v6.2.6#6264)

11 years, 9 months

1
0
0 / 0

[JBoss JIRA] (JBJCA-1159) ConnectionListener leaked if TSR throws IllegalStateException

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/JBJCA-1159?page=com.atlassian.jira.plugin... ] RH Bugzilla Integration commented on JBJCA-1159: ------------------------------------------------ Vaclav Tunka <vtunka(a)redhat.com> changed the Status of [bug 1088470|https://bugzilla.redhat.com/show_bug.cgi?id=1088470] from NEW to ON_QA > ConnectionListener leaked if TSR throws IllegalStateException > ------------------------------------------------------------- > > Key: JBJCA-1159 > URL: https://issues.jboss.org/browse/JBJCA-1159 > Project: IronJacamar > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Core > Affects Versions: 1.0.24.Final, 1.1.4.Final > Environment: AS7 EAP6.1 > Reporter: Koen Janssens > Assignee: Jesper Pedersen > Priority: Blocker > Fix For: 1.0.25.Final, 1.1.5.Final, 1.2.0.Beta1 > > > When a connection is retrieved from the MCP, ironjacamar will register it to ongoing JTA transaction. However, if the ongoing TX is not 'active' anymore the connection is lost. > The code of AbstractPool demonstrates the problem. The call to getLock will throw an exception if the current TX is not active anymore and the cl is not returned to the pool. > This issue can be reproduced on AS7 by using any EJB that requires a tx and does something with a DB connection. Put a breakpoint in the code below after retrieving the connectionlistener, and then wait for the transaction to timeout. Once that's done, continue the thread. The connection is not release (can be seen in JMX) > We have noticed this problem regularly during our performance tests. > {code} > ConnectionListener cl = mcp.getConnection(subject, cri); > if (trace) > log.tracef("Got connection from pool tracked by transaction=%s tx=%s", cl, trackByTransaction); > TransactionSynchronizationRegistry tsr = getTransactionSynchronizationRegistry(); > Lock lock = getLock(); > try > { > lock.lockInterruptibly(); > } > catch (InterruptedException ie) > { > Thread.interrupted(); > throw new ResourceException(bundle.unableObtainLock(), ie); > } > {code} > It seems this issue was introduced by changes done for https://issues.jboss.org/browse/JBJCA-572 -- This message was sent by Atlassian JIRA (v6.2.6#6264)

11 years, 9 months

1
0
0 / 0

[JBoss JIRA] (JBJCA-1161) NPE in SemaphoreArrayListManagedConnectionPool

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/JBJCA-1161?page=com.atlassian.jira.plugin... ] RH Bugzilla Integration commented on JBJCA-1161: ------------------------------------------------ Vaclav Tunka <vtunka(a)redhat.com> changed the Status of [bug 1088470|https://bugzilla.redhat.com/show_bug.cgi?id=1088470] from NEW to ON_QA > NPE in SemaphoreArrayListManagedConnectionPool > ---------------------------------------------- > > Key: JBJCA-1161 > URL: https://issues.jboss.org/browse/JBJCA-1161 > Project: IronJacamar > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Core > Affects Versions: 1.0.25.Final > Reporter: Jesper Pedersen > Assignee: Jesper Pedersen > Priority: Blocker > Fix For: 1.0.26.Final > > > {noformat} > at org.jboss.jca.core.connectionmanager.pool.mcp.SemaphoreArrayListManagedConnectionPool.doDestroy(SemaphoreArrayListManagedConnectionPool.java:866) > at org.jboss.jca.core.connectionmanager.pool.mcp.SemaphoreArrayListManagedConnectionPool.getConnection(SemaphoreArrayListManagedConnectionPool.java:312) > at org.jboss.jca.core.connectionmanager.pool.AbstractPool.getSimpleConnection(AbstractPool.java:404) > {noformat} -- This message was sent by Atlassian JIRA (v6.2.6#6264)

11 years, 9 months

1
0
0 / 0

[JBoss JIRA] (WFLY-3621) Invalid behavior of FormAuthUnitTestCase testPostDataFormAuth causing it to pass even when it should fail

by Radim Hatlapatka (JIRA)

[ https://issues.jboss.org/browse/WFLY-3621?page=com.atlassian.jira.plugin.... ] Radim Hatlapatka resolved WFLY-3621. ------------------------------------ Resolution: Done Pull request merged > Invalid behavior of FormAuthUnitTestCase testPostDataFormAuth causing it to pass even when it should fail > --------------------------------------------------------------------------------------------------------- > > Key: WFLY-3621 > URL: https://issues.jboss.org/browse/WFLY-3621 > Project: WildFly > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Test Suite > Reporter: Radim Hatlapatka > Assignee: Radim Hatlapatka > > FormAuthUnitTestCase testPostDataFormAuth passes even though it should fail. Due typo it redirects to original URL instead of the one retrieved from header resulting in invalid behaviour. -- This message was sent by Atlassian JIRA (v6.2.6#6264)

11 years, 9 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-35) launch-command was only added in version 3.0 of schema, however being parsed in all prior versions.

by Darran Lofthouse (JIRA)

Darran Lofthouse created WFCORE-35: -------------------------------------- Summary: launch-command was only added in version 3.0 of schema, however being parsed in all prior versions. Key: WFCORE-35 URL: https://issues.jboss.org/browse/WFCORE-35 Project: WildFly Core Issue Type: Bug Security Level: Public (Everyone can see) Components: Domain Management Reporter: Darran Lofthouse Assignee: Darran Lofthouse Fix For: 1.0.0.Alpha4 -- This message was sent by Atlassian JIRA (v6.2.6#6264)

11 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 July 2014