March 2014 - jboss-jira - Jboss List Archives

[JBoss JIRA] (JBJCA-1159) DB Connections leaked if TX is not active after retrieving a connection

by Shrihari Chakrapani (JIRA)

[ https://issues.jboss.org/browse/JBJCA-1159?page=com.atlassian.jira.plugin... ] Shrihari Chakrapani commented on JBJCA-1159: -------------------------------------------- An example of how acquiring a lock can fail, if a TX timesout {noformat} Caused by: java.lang.IllegalStateException: No transaction is running at com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionSynchronizationRegistryImple.getTransactionImple(TransactionSynchronizationRegistryImple.java:232) at com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionSynchronizationRegistryImple.getResource(TransactionSynchronizationRegistryImple.java:125) at org.jboss.jca.core.connectionmanager.pool.AbstractPool.getLock(AbstractPool.java:264) at org.jboss.jca.core.connectionmanager.pool.AbstractPool.getTransactionNewConnection(AbstractPool.java:500) at org.jboss.jca.core.connectionmanager.pool.AbstractPool.getConnection(AbstractPool.java:374) at org.jboss.jca.core.connectionmanager.AbstractConnectionManager.getManagedConnection(AbstractConnectionManager.java:329) at org.jboss.jca.core.connectionmanager.tx.TxConnectionManagerImpl.getManagedConnection(TxConnectionManagerImpl.java:368) at org.jboss.jca.core.connectionmanager.AbstractConnectionManager.allocateConnection(AbstractConnectionManager.java:464) at org.jboss.jca.adapters.jdbc.WrapperDataSource.getConnection(WrapperDataSource.java:139) at org.hibernate.ejb.connection.InjectedDataSourceConnectionProvider.getConnection(InjectedDataSourceConnectionProvider.java:70) at org.hibernate.internal.AbstractSessionImpl$NonContextualJdbcConnectionAccess.obtainConnection(AbstractSessionImpl.java:292) at org.hibernate.engine.jdbc.internal.LogicalConnectionImpl.obtainConnection(LogicalConnectionImpl.java:214) at org.hibernate.engine.jdbc.internal.LogicalConnectionImpl.getConnection(LogicalConnectionImpl.java:157) at org.hibernate.engine.jdbc.internal.StatementPreparerImpl.connection(StatementPreparerImpl.java:56) at org.hibernate.engine.jdbc.internal.StatementPreparerImpl$5.doPrepare(StatementPreparerImpl.java:161) at org.hibernate.engine.jdbc.internal.StatementPreparerImpl$StatementPreparationTemplate.prepareStatement(StatementPreparerImpl.java:182) at org.hibernate.engine.jdbc.internal.StatementPreparerImpl.prepareQueryStatement(StatementPreparerImpl.java:159) at org.hibernate.loader.Loader.prepareQueryStatement(Loader.java:1854) at org.hibernate.loader.Loader.executeQueryStatement(Loader.java:1831) at org.hibernate.loader.Loader.executeQueryStatement(Loader.java:1811) at org.hibernate.loader.Loader.doQuery(Loader.java:899) at org.hibernate.loader.Loader.doQueryAndInitializeNonLazyCollections(Loader.java:341) at org.hibernate.loader.Loader.doList(Loader.java:2516) at org.hibernate.loader.Loader.doList(Loader.java:2502) at org.hibernate.loader.Loader.listIgnoreQueryCache(Loader.java:2332) at org.hibernate.loader.Loader.list(Loader.java:2327) at org.hibernate.loader.hql.QueryLoader.list(QueryLoader.java:490) at org.hibernate.hql.internal.ast.QueryTranslatorImpl.list(QueryTranslatorImpl.java:355) at org.hibernate.engine.query.spi.HQLQueryPlan.performList(HQLQueryPlan.java:195) at org.hibernate.internal.SessionImpl.list(SessionImpl.java:1269) at org.hibernate.internal.QueryImpl.list(QueryImpl.java:101) at org.hibernate.ejb.QueryImpl.getResultList(QueryImpl.java:264) {noformat} > DB Connections leaked if TX is not active after retrieving a connection > ----------------------------------------------------------------------- > > Key: JBJCA-1159 > URL: https://issues.jboss.org/browse/JBJCA-1159 > Project: IronJacamar > Issue Type: Bug > Components: Core > Affects Versions: 1.0.19.Final > Environment: AS7 EAP6.1 > Reporter: gui borland > Assignee: Jesper Pedersen > Priority: Critical > > 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 is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFLY-3177) wrong placement of jipijapa-eclipselink-1.0.1.Final.jar file inside bundle. Eclipselink logger to work properly it should be moved from org/eclipse/persistence/main to org/jipijapa/eclipselink/main and configured in xml file accordingly.

by Scott Marlow (JIRA)

[ https://issues.jboss.org/browse/WFLY-3177?page=com.atlassian.jira.plugin.... ] Scott Marlow commented on WFLY-3177: ------------------------------------ Why do you have a org/jipijapa/eclipselink/main folder? Did you follow the steps listed on [https://docs.jboss.org/author/display/WFLY8/JPA+Reference+Guide#JPARefere... I'm trying to understand if we have a software bug somewhere or if this is just configuration. I suspect that your persistence.xml is specifying the "org.jipijapa.eclipselink" module instead of the default "org.eclipse.persistence". But, I need to see your persistence.xml to tell for sure. > wrong placement of jipijapa-eclipselink-1.0.1.Final.jar file inside bundle. Eclipselink logger to work properly it should be moved from org/eclipse/persistence/main to org/jipijapa/eclipselink/main and configured in xml file accordingly. > --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- > > Key: WFLY-3177 > URL: https://issues.jboss.org/browse/WFLY-3177 > Project: WildFly > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: JPA / Hibernate > Reporter: Ravshan Samandarov > -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 1 month

1
0
0 / 0

[JBoss JIRA] (SECURITY-795) AdvancedLdap login module does not handle a user that has a slash character in the uid

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/SECURITY-795?page=com.atlassian.jira.plug... ] RH Bugzilla Integration commented on SECURITY-795: -------------------------------------------------- Ondrej Lukas <olukas(a)redhat.com> changed the Status of [bug 1065476|https://bugzilla.redhat.com/show_bug.cgi?id=1065476] from ON_QA to VERIFIED > AdvancedLdap login module does not handle a user that has a slash character in the uid > -------------------------------------------------------------------------------------- > > Key: SECURITY-795 > URL: https://issues.jboss.org/browse/SECURITY-795 > Project: PicketBox > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Negotiation > Affects Versions: Negotiation_2_2_5 > Reporter: Derek Horton > Assignee: Derek Horton > Fix For: Negotiation_2_2_7 > > Attachments: SECURITY-795.patch > > > AdvancedLdap login module does not handle a user that has a slash character in the uid. > For example, JBoss will fail to authenticate the following user correctly: > dn: uid=weird/user,ou=Users,dc=my-domain,dc=com > uid: weird/user > cn: Weird User -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 1 month

1
0
0 / 0

[JBoss JIRA] (JBJCA-1159) DB Connections leaked if TX is not active after retrieving a connection

by gui borland (JIRA)

[ https://issues.jboss.org/browse/JBJCA-1159?page=com.atlassian.jira.plugin... ] gui borland updated JBJCA-1159: ------------------------------- Description: 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 was: 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. > DB Connections leaked if TX is not active after retrieving a connection > ----------------------------------------------------------------------- > > Key: JBJCA-1159 > URL: https://issues.jboss.org/browse/JBJCA-1159 > Project: IronJacamar > Issue Type: Bug > Components: Core > Affects Versions: 1.0.19.Final > Environment: AS7 EAP6.1 > Reporter: gui borland > Assignee: Jesper Pedersen > Priority: Critical > > 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 is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 1 month

1
0
0 / 0

[JBoss JIRA] (JBJCA-1159) DB Connections leaked if TX is not active after retrieving a connection

by gui borland (JIRA)

gui borland created JBJCA-1159: ---------------------------------- Summary: DB Connections leaked if TX is not active after retrieving a connection Key: JBJCA-1159 URL: https://issues.jboss.org/browse/JBJCA-1159 Project: IronJacamar Issue Type: Bug Components: Core Affects Versions: 1.0.19.Final Environment: AS7 EAP6.1 Reporter: gui borland Assignee: Jesper Pedersen Priority: Critical 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. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFLY-3187) Can't deploy same webservice endpoint impl with different url patterns

by Jim Ma (JIRA)

[ https://issues.jboss.org/browse/WFLY-3187?page=com.atlassian.jira.plugin.... ] Jim Ma updated WFLY-3187: ------------------------- Summary: Can't deploy same webservice endpoint impl with different url patterns (was: Can't deploy same webservice endpoint impl with different url pattern) > Can't deploy same webservice endpoint impl with different url patterns > ---------------------------------------------------------------------- > > Key: WFLY-3187 > URL: https://issues.jboss.org/browse/WFLY-3187 > Project: WildFly > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Web Services > Reporter: Jim Ma > Assignee: Jim Ma > Fix For: 8.0.1.Final > > > After WFLY-3067 change, CustomerServiceImpl can only be deployed with address http://localhost:8080/webcontext/test1. It should be started with /test2 urlPattern too. > {code:xml} > <?xml version="1.0" encoding="UTF-8"?> > <web-app xmlns="http://java.sun.com/xml/ns/j2ee" > xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" > xsi:schemaLocation="http://java.sun.com/xml/ns/j2ee http://java.sun.com/xml/ns/j2ee/web-app_2_4.xsd" > version="2.4"> > <servlet> > <servlet-name>TestService</servlet-name> > <servlet-class>org.jboss.test.ws.jaxws.samples.webresult.CustomerServiceImpl</servlet-class> > </servlet> > <servlet-mapping> > <servlet-name>TestService</servlet-name> > <url-pattern>/test1/*</url-pattern> > </servlet-mapping> > <servlet> > <servlet-name>TestService2</servlet-name> > <servlet-class>org.jboss.test.ws.jaxws.samples.webresult.CustomerServiceImpl</servlet-class> > </servlet> > <servlet-mapping> > <servlet-name>TestService2</servlet-name> > <url-pattern>/test2/*</url-pattern> > </servlet-mapping> > </web-app> > {code} -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFLY-3187) Can't deploy same webservice endpoint impl with different url pattern

by Jim Ma (JIRA)

Jim Ma created WFLY-3187: ---------------------------- Summary: Can't deploy same webservice endpoint impl with different url pattern Key: WFLY-3187 URL: https://issues.jboss.org/browse/WFLY-3187 Project: WildFly Issue Type: Bug Security Level: Public (Everyone can see) Components: Web Services Reporter: Jim Ma Assignee: Jim Ma Fix For: 8.0.1.Final After WFLY-3067 change, CustomerServiceImpl can only be deployed with address http://localhost:8080/webcontext/test1. It should be started with /test2 urlPattern too. {code:xml} <?xml version="1.0" encoding="UTF-8"?> <web-app xmlns="http://java.sun.com/xml/ns/j2ee" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://java.sun.com/xml/ns/j2ee http://java.sun.com/xml/ns/j2ee/web-app_2_4.xsd" version="2.4"> <servlet> <servlet-name>TestService</servlet-name> <servlet-class>org.jboss.test.ws.jaxws.samples.webresult.CustomerServiceImpl</servlet-class> </servlet> <servlet-mapping> <servlet-name>TestService</servlet-name> <url-pattern>/test1/*</url-pattern> </servlet-mapping> <servlet> <servlet-name>TestService2</servlet-name> <servlet-class>org.jboss.test.ws.jaxws.samples.webresult.CustomerServiceImpl</servlet-class> </servlet> <servlet-mapping> <servlet-name>TestService2</servlet-name> <url-pattern>/test2/*</url-pattern> </servlet-mapping> </web-app> {code} -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 1 month

1
0
0 / 0

[JBoss JIRA] (SECURITY-812) Release JBoss Negotiation 2.3.0.CR1

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/SECURITY-812?page=com.atlassian.jira.plug... ] RH Bugzilla Integration commented on SECURITY-812: -------------------------------------------------- Kabir Khan <kkhan(a)redhat.com> changed the Status of [bug 1081607|https://bugzilla.redhat.com/show_bug.cgi?id=1081607] from POST to MODIFIED > Release JBoss Negotiation 2.3.0.CR1 > ----------------------------------- > > Key: SECURITY-812 > URL: https://issues.jboss.org/browse/SECURITY-812 > Project: PicketBox > Issue Type: Release > Security Level: Public(Everyone can see) > Components: Negotiation > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Fix For: Negotiation_2_3_0_CR1 > > -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFLY-3182) Upgrade to JBoss Negotiation 2.3.0.CR1

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFLY-3182?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on WFLY-3182: ----------------------------------------------- Kabir Khan <kkhan(a)redhat.com> changed the Status of [bug 1081607|https://bugzilla.redhat.com/show_bug.cgi?id=1081607] from POST to MODIFIED > Upgrade to JBoss Negotiation 2.3.0.CR1 > -------------------------------------- > > Key: WFLY-3182 > URL: https://issues.jboss.org/browse/WFLY-3182 > Project: WildFly > Issue Type: Component Upgrade > Security Level: Public(Everyone can see) > Components: Security > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Fix For: 9.0.0.CR1 > > -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFLY-3186) Upgrade to Weld 2.2

by Jozef Hartinger (JIRA)

Jozef Hartinger created WFLY-3186: ------------------------------------- Summary: Upgrade to Weld 2.2 Key: WFLY-3186 URL: https://issues.jboss.org/browse/WFLY-3186 Project: WildFly Issue Type: Task Security Level: Public (Everyone can see) Reporter: Jozef Hartinger Assignee: Jozef Hartinger Fix For: 8.0.1.Final -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 1 month

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 March 2014