June 2014 - jboss-jira - Jboss List Archives

[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: ------------------------------------------------ mark yarborough <myarboro(a)redhat.com> changed the Status of [bug 1088469|https://bugzilla.redhat.com/show_bug.cgi?id=1088469] from VERIFIED to CLOSED > ConnectionListener leaked if TSR throws IllegalStateException > ------------------------------------------------------------- > > Key: JBJCA-1159 > URL: https://issues.jboss.org/browse/JBJCA-1159 > Project: IronJacamar > Issue Type: Bug > 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.3#6260)

12 years, 1 month

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: ------------------------------------------------ mark yarborough <myarboro(a)redhat.com> changed the Status of [bug 1088469|https://bugzilla.redhat.com/show_bug.cgi?id=1088469] from VERIFIED to CLOSED > Pool statistics are not cleared > ------------------------------- > > Key: JBJCA-1110 > URL: https://issues.jboss.org/browse/JBJCA-1110 > Project: IronJacamar > Issue Type: Bug > 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.3#6260)

12 years, 1 month

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: ------------------------------------------------ mark yarborough <myarboro(a)redhat.com> changed the Status of [bug 1088469|https://bugzilla.redhat.com/show_bug.cgi?id=1088469] from VERIFIED to CLOSED > NPE in SemaphoreArrayListManagedConnectionPool > ---------------------------------------------- > > Key: JBJCA-1161 > URL: https://issues.jboss.org/browse/JBJCA-1161 > Project: IronJacamar > Issue Type: Bug > 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.3#6260)

12 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFLY-2920) StackOverflowError when org.jboss.as.jacorb.rmi.InterfaceAnalysis is analyzing javax.ejb.EJBObject

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFLY-2920?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on WFLY-2920: ----------------------------------------------- mark yarborough <myarboro(a)redhat.com> changed the Status of [bug 1072747|https://bugzilla.redhat.com/show_bug.cgi?id=1072747] from VERIFIED to CLOSED > StackOverflowError when org.jboss.as.jacorb.rmi.InterfaceAnalysis is analyzing javax.ejb.EJBObject > -------------------------------------------------------------------------------------------------- > > Key: WFLY-2920 > URL: https://issues.jboss.org/browse/WFLY-2920 > Project: WildFly > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: IIOP > Affects Versions: 8.0.0.Final > Reporter: Osamu Nagano > Assignee: Stuart Douglas > Fix For: 8.1.0.CR1, 8.1.0.Final > > Attachments: td.dump > > > Depending on when a thread context switch happens, an IIOP enabled EJB fails to be deployed by throwing {{java.lang.StackOverflowError}}. Here is the stack trace from the attached thread dump. > {code} > "MSC service thread 1-7" prio=10 tid=0x00007f52e8001800 nid=0x4d12 at breakpoint[0x00007f534093f000] > java.lang.Thread.State: RUNNABLE > at org.jboss.as.jacorb.rmi.WorkCacheManager.getAnalysis(WorkCacheManager.java:105) > at org.jboss.as.jacorb.rmi.InterfaceAnalysis.getInterfaceAnalysis(InterfaceAnalysis.java:53) > at org.jboss.as.jacorb.rmi.Util.getTypeIDLName(Util.java:104) > at org.jboss.as.jacorb.rmi.ParameterAnalysis.<init>(ParameterAnalysis.java:50) > at org.jboss.as.jacorb.rmi.OperationAnalysis.<init>(OperationAnalysis.java:91) > at org.jboss.as.jacorb.rmi.InterfaceAnalysis.analyzeOperations(InterfaceAnalysis.java:116) > at org.jboss.as.jacorb.rmi.ContainerAnalysis.doAnalyze(ContainerAnalysis.java:186) > at org.jboss.as.jacorb.rmi.InterfaceAnalysis.doAnalyze(InterfaceAnalysis.java:62) > at sun.reflect.GeneratedMethodAccessor3.invoke(Unknown Source) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:606) > at org.jboss.as.jacorb.rmi.WorkCacheManager.doTheWork(WorkCacheManager.java:177) > at org.jboss.as.jacorb.rmi.WorkCacheManager.getAnalysis(WorkCacheManager.java:105) > at org.jboss.as.jacorb.rmi.InterfaceAnalysis.getInterfaceAnalysis(InterfaceAnalysis.java:53) > at org.jboss.as.jacorb.rmi.Util.getTypeIDLName(Util.java:104) > at org.jboss.as.jacorb.rmi.ParameterAnalysis.<init>(ParameterAnalysis.java:50) > at org.jboss.as.jacorb.rmi.OperationAnalysis.<init>(OperationAnalysis.java:91) > at org.jboss.as.jacorb.rmi.InterfaceAnalysis.analyzeOperations(InterfaceAnalysis.java:116) > at org.jboss.as.jacorb.rmi.ContainerAnalysis.doAnalyze(ContainerAnalysis.java:186) > at org.jboss.as.jacorb.rmi.InterfaceAnalysis.doAnalyze(InterfaceAnalysis.java:62) > at sun.reflect.GeneratedMethodAccessor3.invoke(Unknown Source) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:606) > ... > at org.jboss.as.jacorb.rmi.WorkCacheManager.doTheWork(WorkCacheManager.java:177) > at org.jboss.as.jacorb.rmi.WorkCacheManager.getAnalysis(WorkCacheManager.java:105) > at org.jboss.as.jacorb.rmi.InterfaceAnalysis.getInterfaceAnalysis(InterfaceAnalysis.java:53) > at org.jboss.as.jacorb.rmi.Util.getTypeIDLName(Util.java:104) > at org.jboss.as.jacorb.rmi.ParameterAnalysis.<init>(ParameterAnalysis.java:50) > Locked ownable synchronizers: > - <0x00000000f9698790> (a java.util.concurrent.ThreadPoolExecutor$Worker) > {code} > The last part including {{Util.getTypeIDLName}} has been repeated as many as possible and the bottom of the stack has been lost. The same stack has been appeared in a different MSC service thread which is also executing an IIOP enabled EJB deployment. > The customer identified an improper synchronization in {{org.jboss.as.jacorb.rmi.WorkCacheManager#getAnalysis()}}. It is reproducible by manually controlling a thread context switch using a debugger. -- This message was sent by Atlassian JIRA (v6.2.3#6260)

12 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFLY-3161) Optimize org.jboss.as.jmx.model.RootResourceIterator

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFLY-3161?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on WFLY-3161: ----------------------------------------------- mark yarborough <myarboro(a)redhat.com> changed the Status of [bug 1089616|https://bugzilla.redhat.com/show_bug.cgi?id=1089616] from VERIFIED to CLOSED > Optimize org.jboss.as.jmx.model.RootResourceIterator > ---------------------------------------------------- > > Key: WFLY-3161 > URL: https://issues.jboss.org/browse/WFLY-3161 > Project: WildFly > Issue Type: Sub-task > Security Level: Public(Everyone can see) > Components: Domain Management, JMX > Affects Versions: 8.0.0.Final > Reporter: Brian Stansberry > Assignee: Brian Stansberry > Fix For: 8.1.0.CR1, 8.1.0.Final > > > RootResourceIterator is performing an access control check on a resource before confirming that the caller is in any way interested in that resource. This results in spurious access control checks. Fixing this can speed up queryMBeans and queryNames calls. -- This message was sent by Atlassian JIRA (v6.2.3#6260)

12 years, 1 month

1
0
0 / 0

[JBoss JIRA] (SECURITY-803) SecureIdentityLoginModule (and ConfiguredIdentityLoginModule) results are not cached by the JAAS cache

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/SECURITY-803?page=com.atlassian.jira.plug... ] RH Bugzilla Integration commented on SECURITY-803: -------------------------------------------------- mark yarborough <myarboro(a)redhat.com> changed the Status of [bug 1069886|https://bugzilla.redhat.com/show_bug.cgi?id=1069886] from VERIFIED to CLOSED > SecureIdentityLoginModule (and ConfiguredIdentityLoginModule) results are not cached by the JAAS cache > ------------------------------------------------------------------------------------------------------ > > Key: SECURITY-803 > URL: https://issues.jboss.org/browse/SECURITY-803 > Project: PicketBox > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: PicketBox > Affects Versions: PicketBox_4_0_19.Final > Reporter: Derek Horton > Assignee: Stefan Guilhen > Attachments: SECURITY-803.patch > > > In EAP 6, when using the SecureIdentityLoginModule to encrypt datasource passwords, the results are not cached by the JAAS cache. In EAP 5, the results are cached. This can lead to a performance issue. > The root cause appears to be that the EAP 6 JAAS cache does not allow for a JAAS cache key to be null. > The issue only occurs when the application that uses the datasource is not secured. In this situation, the principal is null when isValid() and updateCache() are called. When the application is secured, the results are cached. I think it is working because the result of the SecureIdentityLoginModule are cached using the authenticated user's principal as the cache key. > Workaround: > Use vault for encrypting the database password. This does not use a JAAS login module so the JAAS cache and login module are completely avoided. -- This message was sent by Atlassian JIRA (v6.2.3#6260)

12 years, 1 month

1
0
0 / 0

[JBoss JIRA] (SECURITY-815) NegotiationAuthenticator loses post data

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/SECURITY-815?page=com.atlassian.jira.plug... ] RH Bugzilla Integration commented on SECURITY-815: -------------------------------------------------- mark yarborough <myarboro(a)redhat.com> changed the Status of [bug 1085504|https://bugzilla.redhat.com/show_bug.cgi?id=1085504] from VERIFIED to CLOSED > NegotiationAuthenticator loses post data > ---------------------------------------- > > Key: SECURITY-815 > URL: https://issues.jboss.org/browse/SECURITY-815 > Project: PicketBox > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Negotiation > Affects Versions: Negotiation_2_2_5 > Reporter: Derek Horton > Assignee: Darran Lofthouse > Fix For: Negotiation_2_2_8, Negotiation_2_3_0_CR2 > > > The NegotiationAuthenticator loses post data. > A customer is attempting to use Negotiation along with PicketLink at the IDP. This works fine as long as the SP is using HTTP-Redirect SAML binding. > If the SP is using HTTP-Redirect, then this issue is avoided as the SAMLRequest is passed along through the redirects on the URL. > If the HTTP-POST binding is used, then the NegotiationAuthenticator will lose the SAMLRequest post parameter. This means that after a user is successfully authenticated, the IDP will not know where to redirect the user to. As a result, the user will be left at the IDP index.html page. -- This message was sent by Atlassian JIRA (v6.2.3#6260)

12 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFLY-2949) Cannot get exception as pass-by-reference

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFLY-2949?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on WFLY-2949: ----------------------------------------------- mark yarborough <myarboro(a)redhat.com> changed the Status of [bug 1082880|https://bugzilla.redhat.com/show_bug.cgi?id=1082880] from VERIFIED to CLOSED > Cannot get exception as pass-by-reference > ----------------------------------------- > > Key: WFLY-2949 > URL: https://issues.jboss.org/browse/WFLY-2949 > Project: WildFly > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: EJB > Affects Versions: 8.0.0.Final > Reporter: Osamu Nagano > Assignee: David Lloyd > Fix For: 8.1.0.CR1, 8.1.0.Final > > > Despite of {{<in-vm-remote-interface-invocation pass-by-value="false"/>}}, an exception is not thrown by reference, which results in {{java.io.NotSerializableException}} if the exception doesn't implement {{Serializable}}. This is a blocker of a large migration project from WebLogic because it throws by reference even if that doesn't implement {{Serializable}}. -- This message was sent by Atlassian JIRA (v6.2.3#6260)

12 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFLY-3099) management authorization throws an exception when an LDAP group contains a slash/backslash character

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFLY-3099?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on WFLY-3099: ----------------------------------------------- mark yarborough <myarboro(a)redhat.com> changed the Status of [bug 1075082|https://bugzilla.redhat.com/show_bug.cgi?id=1075082] from VERIFIED to CLOSED > management authorization throws an exception when an LDAP group contains a slash/backslash character > ---------------------------------------------------------------------------------------------------- > > Key: WFLY-3099 > URL: https://issues.jboss.org/browse/WFLY-3099 > Project: WildFly > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Domain Management > Affects Versions: 8.0.0.Final > Reporter: Tom Fonteyne > Assignee: Tom Fonteyne > Fix For: 8.1.0.CR1, 8.1.0.Final > > > management authorization throws an exception when an LDAP group contains a slash/backslash character -- This message was sent by Atlassian JIRA (v6.2.3#6260)

12 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFLY-3069) slaves cannot reconnect to a restarted master if RBAC is enabled

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFLY-3069?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on WFLY-3069: ----------------------------------------------- mark yarborough <myarboro(a)redhat.com> changed the Status of [bug 1072949|https://bugzilla.redhat.com/show_bug.cgi?id=1072949] from VERIFIED to CLOSED > slaves cannot reconnect to a restarted master if RBAC is enabled > ---------------------------------------------------------------- > > Key: WFLY-3069 > URL: https://issues.jboss.org/browse/WFLY-3069 > Project: WildFly > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Domain Management > Affects Versions: 8.0.0.Final > Reporter: Tom Fonteyne > Assignee: Emanuel Muckenhuber > Priority: Critical > Fix For: 8.1.0.CR1, 8.1.0.Final > > > Enable RBAC in an Wilfly domain setup. "reload --host=master" and the slaves will no longer be connected to the master -- This message was sent by Atlassian JIRA (v6.2.3#6260)

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