[JBoss JIRA] Created: (JGRP-556) Consolidate thread pools
by Vladimir Blagojevic (JIRA)
Consolidate thread pools
------------------------
Key: JGRP-556
URL: http://jira.jboss.com/jira/browse/JGRP-556
Project: JGroups
Issue Type: Task
Reporter: Vladimir Blagojevic
Assigned To: Bela Ban
Fix For: 2.6
For JGroups 2.5 we have used numerous instances of ThreadPoolExecutor(s) as we needed them. For instance, STREAMING_STATE_TRANSFER, Multiplexer, TP, and ProtocolStack. Undoubtedly this lead to increased overhead and performance impact that we have not measured. First of all we should stop indiscriminately introducing new thread pools as we go further. Second, we should Investigate possibility to consolidate thread pools so they can be reused by various protocols and components of a channel.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
17 years, 1 month
[JBoss JIRA] Created: (JBPORTAL-1782) CMS security checks using ldap causes "too many open files" error
by frontline frontline (JIRA)
CMS security checks using ldap causes "too many open files" error
-----------------------------------------------------------------
Key: JBPORTAL-1782
URL: http://jira.jboss.com/jira/browse/JBPORTAL-1782
Project: JBoss Portal
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: Portal CMS, Portal Identity
Affects Versions: 2.6.1 Final
Environment: Linux
Reporter: frontline frontline
Assigned To: Sohil Shah
I have configured the portal to use OpenDS as the "user store".
I noticed that if I log in as some other user than admin and then perform many CMS operations I eventually get an "java.net.SocketException: Too many open files" error.
Apparently the portal always opens a new connection when getting role info etc. for authorization? So there is no caching or even pooling of the ldap connections? Isn't this also potentially bad for performance (and for the poor ldap server)?
If I wait a while the connections become usable again so there is no connection leak (the sockets are in TIME_WAIT for a while).
Here is the error:
java.net.SocketException: Too many open files
java.net.Socket.createImpl(Socket.java:388)
java.net.Socket.<init>(Socket.java:361)
java.net.Socket.<init>(Socket.java:179)
com.sun.jndi.ldap.Connection.createSocket(Connection.java:346)
com.sun.jndi.ldap.Connection.<init>(Connection.java:181)
com.sun.jndi.ldap.LdapClient.<init>(LdapClient.java:118)
com.sun.jndi.ldap.LdapClient.getInstance(LdapClient.java:1578)
com.sun.jndi.ldap.LdapCtx.connect(LdapCtx.java:2596)
com.sun.jndi.ldap.LdapCtx.<init>(LdapCtx.java:283)
com.sun.jndi.ldap.LdapCtxFactory.getUsingURL(LdapCtxFactory.java:175)
com.sun.jndi.ldap.LdapCtxFactory.getUsingURLs(LdapCtxFactory.java:193)
com.sun.jndi.ldap.LdapCtxFactory.getLdapCtxInstance(LdapCtxFactory.java:136)
com.sun.jndi.ldap.LdapCtxFactory.getInitialContext(LdapCtxFactory.java:66)
javax.naming.spi.NamingManager.getInitialContext(NamingManager.java:667)
javax.naming.InitialContext.getDefaultInitCtx(InitialContext.java:247)
javax.naming.InitialContext.init(InitialContext.java:223)
javax.naming.ldap.InitialLdapContext.<init>(InitialLdapContext.java:134)
org.jboss.portal.identity.ldap.LDAPConnectionContext.createInitialContext(LDAPConnectionContext.java:99)
org.jboss.portal.identity.ldap.LDAPUserModuleImpl.searchUsers(LDAPUserModuleImpl.java:353)
org.jboss.portal.identity.ldap.LDAPUserModuleImpl.findUserByUserName(LDAPUserModuleImpl.java:81)
org.jboss.portal.cms.security.AuthorizationProviderImpl.findPermissionsByUser(AuthorizationProviderImpl.java:365)
org.jboss.portal.cms.security.AuthorizationProviderImpl.getSecurityBindings(AuthorizationProviderImpl.java:147)
org.jboss.portal.cms.impl.jcr.command.ACLEnforcer.getPermissions(ACLEnforcer.java:573)
org.jboss.portal.cms.impl.jcr.command.ACLEnforcer.computeAccess(ACLEnforcer.java:330)
org.jboss.portal.cms.impl.jcr.command.ACLEnforcer.hasReadAccess(ACLEnforcer.java:209)
org.jboss.portal.cms.impl.jcr.command.ACLEnforcer.hasAccess(ACLEnforcer.java:120)
org.jboss.portal.cms.security.AuthorizationManagerImpl.checkPermission(AuthorizationManagerImpl.java:127)
org.jboss.portal.cms.impl.interceptors.ACLInterceptor.invoke(ACLInterceptor.java:238)
org.jboss.portal.cms.CMSInterceptor.invoke(CMSInterceptor.java:36)
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
17 years, 1 month
[JBoss JIRA] Created: (JBAS-4152) Upgrade to hsql 1.8.0.7 causes org.jboss.test.cmp2.idxandusersql.test.IdxAndUsersqlUnitTestCase::testCMRmn2 to fail
by Vivek Lakshmanan (JIRA)
Upgrade to hsql 1.8.0.7 causes org.jboss.test.cmp2.idxandusersql.test.IdxAndUsersqlUnitTestCase::testCMRmn2 to fail
-------------------------------------------------------------------------------------------------------------------
Key: JBAS-4152
URL: http://jira.jboss.com/jira/browse/JBAS-4152
Project: JBoss Application Server
Issue Type: Sub-task
Security Level: Public (Everyone can see)
Components: EJB2
Affects Versions: JBossAS-4.0.5.CR1
Environment: BEA JRockit 1.5.0_08 on Red Hat Enterprise Linux AS release 4 (Nahant Update 4)
Reporter: Vivek Lakshmanan
Assigned To: Scott M Stark
On upgrade of HSQLDB from 1.8.0.2 to 1.8.0.7 the following testcase seems to consistently fail:
org.jboss.test.cmp2.idxandusersql.test.IdxAndUsersqlUnitTestCase::testCMRmn2
Error: FKey cmr2_id is indexed
The test reports say:
junit.framework.AssertionFailedError: Error: FKey cmr2_id is indexed
at org.jboss.test.cmp2.idxandusersql.test.IdxAndUsersqlUnitTestCase.testCMRmn2(IdxAndUsersqlUnitTestCase.java:190)
at net.sourceforge.junitejb.EJBTestCase.runBare(EJBTestCase.java:133)
at net.sourceforge.junitejb.EJBTestRunnerBean.runTestCase(EJBTestRunnerBean.java:102)
at net.sourceforge.junitejb.EJBTestRunnerBean.run(EJBTestRunnerBean.java:44)
at org.jboss.invocation.Invocation.performCall(Invocation.java:359)
at org.jboss.ejb.StatelessSessionContainer$ContainerInterceptor.invoke(StatelessSessionContainer.java:237)
at org.jboss.resource.connectionmanager.CachedConnectionInterceptor.invoke(CachedConnectionInterceptor.java:158)
at org.jboss.ejb.plugins.CallValidationInterceptor.invoke(CallValidationInterceptor.java:63)
at org.jboss.ejb.plugins.AbstractTxInterceptor.invokeNext(AbstractTxInterceptor.java:121)
at org.jboss.ejb.plugins.AbstractTxInterceptorBMT.invokeNext(AbstractTxInterceptorBMT.java:173)
at org.jboss.ejb.plugins.TxInterceptorBMT.invoke(TxInterceptorBMT.java:77)
at org.jboss.ejb.plugins.StatelessSessionInstanceInterceptor.invoke(StatelessSessionInstanceInterceptor.java:169)
at org.jboss.ejb.plugins.SecurityInterceptor.invoke(SecurityInterceptor.java:168)
at org.jboss.ejb.plugins.LogInterceptor.invoke(LogInterceptor.java:205)
at org.jboss.ejb.plugins.ProxyFactoryFinderInterceptor.invoke(ProxyFactoryFinderInterceptor.java:136)
at org.jboss.ejb.SessionContainer.internalInvoke(SessionContainer.java:648)
The sourcefile for the test says:
/*
* Look for indices on the m:n mapping table
* This is for hsql a strange case, at indices are put there
* anyway, but it has been told that other databases don't do
* it by themselves, so we check if the creation succeeds.
*/
Would like to get an experts opinion on it
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
17 years, 1 month