October 2007 - jboss-jira - Jboss List Archives

[JBoss JIRA] Created: (JBAS-3986) OutOfMemory exception due to TimedCachePolicy in JAAS

by Ramil Israfilov (JIRA)

OutOfMemory exception due to TimedCachePolicy in JAAS ----------------------------------------------------- Key: JBAS-3986 URL: http://jira.jboss.com/jira/browse/JBAS-3986 Project: JBoss Application Server Issue Type: Bug Security Level: Public (Everyone can see) Components: Security Affects Versions: JBossAS-4.0.5.GA, JBossAS-4.0.4.GA Environment: JDK1.5, solarisx86, JBoss-4.0.4.GA Reporter: Ramil Israfilov Assigned To: Scott M Stark Priority: Critical We have a big amount of users who perform logon to jboss. After 15 000 user logins we have an OutOfMemory exception. During profiling we see that JAASSecurityManager$DomainInfo takes almost all memory. We are using <attribute name="DefaultCacheTimeout">120</attribute> and <attribute name="DefaultCacheResolution">60</attribute> But memory is only growing. So no objects are removed from authentication cache. We tried to disable caching but in that case we had from time to time Authentication failure exception then did logon from multiple clients. After digging into source code we saw that object never removed from cache ! Only then user do re-logon it is checked that principa is expired and removed. But it means that If user logged on once it will be always (!!) in cache. And it leads to OutOfMemory. We had to extend a run() method of TimedCachePolicy to do remove expired objects: public void run() { super.run(); synchronized (entryMap) { Iterator iter = entryMap.entrySet().iterator(); List<Object> removeentries = new ArrayList<Object>(); while (iter.hasNext()) { Map.Entry entry = (Map.Entry) iter.next(); TimedEntry value = (TimedEntry) entry.getValue(); if (value.isCurrent(now) == false) { if(log.isDebugEnabled()){ log.debug("destroying object:"+value); } value.destroy(); removeentries.add(entry.getKey()); } } for (Object object : removeentries) { if(log.isDebugEnabled()){ log.debug("removing object from Map:"+object); } entryMap.remove(object); } } } Is not it will be much better to do it on original TimedCachePolicy class ? -- 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

14 years, 11 months

6
10
0 / 0

[JBoss JIRA] Created: (EJBTHREE-835) revet to Hibernate's PersistenceXmlLoader

by Bill Burke (JIRA)

revet to Hibernate's PersistenceXmlLoader ----------------------------------------- Key: EJBTHREE-835 URL: http://jira.jboss.com/jira/browse/EJBTHREE-835 Project: EJB 3.0 Issue Type: Bug Reporter: Bill Burke Assigned To: Carlo de Wolf Fix For: EJB 3.0 RC10 - FD The default PersistenceUnitTransactionType is JTA in Java EE and RESOURCE_LOCAL in Java SE. Currently HEM returns RESOURCE_LOCAL no matter what. HEM is fixed but until it revs in JBoss head, I have copied the persistence.xml parsing to EJB3 project. Please remove org.jboss.ejb3.entity.PersistenceXmlLoader from SVN when HEM revs and revert to Hibernate version. -- 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

14 years, 11 months

6
12
0 / 0

[JBoss JIRA] Created: (EJBTHREE-760) @WebServiceRef not bound to java:comp/env

by Thomas Diesler (JIRA)

@WebServiceRef not bound to java:comp/env ----------------------------------------- Key: EJBTHREE-760 URL: http://jira.jboss.com/jira/browse/EJBTHREE-760 Project: EJB 3.0 Issue Type: Bug Reporter: Thomas Diesler Assigned To: Carlo de Wolf package org.jboss.test.ws.jaxws.webserviceref; @WebServiceRef(name = "service1", value = TestEndpointService.class, wsdlLocation = "META-INF/wsdl/TestEndpoint.wsdl") @WebServiceRefs( { @WebServiceRef(name = "service2", value = TestEndpointService.class, wsdlLocation = "META-INF/wsdl/TestEndpoint.wsdl"), @WebServiceRef(name = "port1", value = TestEndpointService.class, type = TestEndpoint.class, wsdlLocation = "META-INF/wsdl/TestEndpoint.wsdl") }) public class ApplicationClient When the client is deployed, I see the first reference beeing bound to jbossws-client/env/service1 However, ports.add(((TestEndpointService)encCtx.lookup("java:comp/env/service1")).getTestEndpointPort()); fails with javax.naming.NameNotFoundException: service1 not bound To reproduce run this against jbossas/branches/JEE5_TCK /home/tdiesler/svn/jbossws/trunk/src/test [tdiesler@tddell test]$ ant -Dtest=jaxws/webserviceref test -- 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

14 years, 11 months

2
2
0 / 0

[JBoss JIRA] Created: (JBAS-4813) EAR with WAR classloading isolation & commons-httpclient

by C￩dric Chantepie (JIRA)

EAR with WAR classloading isolation & commons-httpclient -------------------------------------------------------- Key: JBAS-4813 URL: http://jira.jboss.com/jira/browse/JBAS-4813 Project: JBoss Application Server Issue Type: Bug Security Level: Public (Everyone can see) Components: ClassLoading, Web (Tomcat) service Affects Versions: JBossAS-4.0.5.GA, JBossAS-4.0.3 SP1 Environment: Linux 2.6.11-1.1369_FC4smp (Fedora Core 4) 2005 i686 i686 i386 GNU/Linux jrockit-R26.4.0-jdk1.5.0_06 Reporter: C￩dric Chantepie Assigned To: Scott M Stark Priority: Blocker We have an EAR including 4 modules : - an ejb .jar, - persistence .har - 2 webapps. 3 modules -- the ejb .jar and the 2 webapps, depends on commons-httpclient 3.1, different from jboss version which 2.x, so I've first maid the EAR isolated by adding the jboss-app.xml with instruction given in JBoss wiki about EAR classloading. == META-INF/jboss-app.xml == <!DOCTYPE jboss-app PUBLIC "-//JBoss//DTD J2EE Application 1.4//EN" "http://www.jboss.org/j2ee/dtd/jboss-app_4_0.dtd"> <jboss-app> <loader-repository>my.package:loader=My.ear <loader-repository-config>java2ParentDelegation=false</loader-repository-config> </loader-repository> <jmx-name>my.package:module=My.ear</jmx-name> <module> <har>MyPersistence.har</har> </module> </jboss-app> Then I've added Class-Path attribute in ejb .jar manifest. == ejb.jar | META-INF/MANIFEST.MF == Manifest-Version: 1.0 Class-Path: lib/commons-httpclient-3.1.jar lib/commons-codec-1.2.jar l ib/lucene-core-2.0.0.jar lib/commons-lang-2.3.jar lib/j2cdk.jar lib/l ucene-analyzers-2.0.0.jar (Line breaks there are as in MANIFEST.MF when I extract it from the jar.) I've also manifest files in WAR for the 2 webapps, but I'm not sure jboss/jbossweb(tomcat) take care of it. == webapp1.war | META-INF/MANIFEST.MF == Manifest-Version: 1.0 Class-Path: lib/a-web-lib.jar lib/commons-beanutils-1.7.0.jar li b/commons-beanutils-core-1.7.0.jar lib/commons-digester-1.6.jar lib/c ommons-fileupload-1.0.jar lib/j2cdk-taglib.jar lib/j2cdk.jar lib/jgen .jar lib/jstl.jar lib/standard.jar lib/struts-1.2.9.jar lib/taglibs-m ailer.jar lib/commons-httpclient-3.1.jar == webapp2.war | META-INF/MANIFEST.MF == Manifest-Version: 1.0 Class-Path: lib/a-web-lib.jar lib/commons-beanutils-1.7.0.jar li b/commons-beanutils-core-1.7.0.jar lib/commons-digester-1.6.jar lib/j 2cdk-taglib.jar lib/j2cdk.jar lib/jgen.jar lib/jstl.jar lib/standard. jar lib/struts-1.2.9.jar lib/taglibs-mailer.jar lib/htmlparser-1.0-SN APSHOT.jar lib/commons-httpclient-3.1.jar And I've also jboss-web.xml files in these two WAR, even if there are included when deployed inside EAR (which is the top deployment in this case), with the same load repository specified "my.package:loader=My.ear". == webapp1.war | WEB-INF/MANIFEST.MF == <?xml version='1.0' encoding='UTF-8'?> <!DOCTYPE jboss-web PUBLIC "-//JBoss//DTD Web Application 2.3V2//EN" "http://www.jboss.org/j2ee/dtd/jboss-web_3_2.dtd"> <jboss-web> <context-root>/BO</context-root> <virtual-host>www.my-vhost.com</virtual-host> <class-loading java2ClassLoadingCompliance="false"> <loader-repository>my.package:loader=My.ear <loader-repository-config>java2ParentDelegation=false</loader-repository-config> </loader-repository> </class-loading> </jboss-web> == webapp2.war | WEB-INF/MANIFEST.MF == <?xml version='1.0' encoding='UTF-8'?> <!DOCTYPE jboss-web PUBLIC "-//JBoss//DTD Web Application 2.3V2//EN" "http://www.jboss.org/j2ee/dtd/jboss-web_3_2.dtd"> <jboss-web> <context-root>/</context-root> <virtual-host>www.my-vhost.com</virtual-host> <class-loading java2ClassLoadingCompliance="false"> <loader-repository>my.package:loader=My.ear <loader-repository-config>java2ParentDelegation=false</loader-repository-config> </loader-repository> </class-loading> </jboss-web> Ok, that the situation. All work well on several developpement servers (tested on 3 linux hosts and 1 os x), it can be deployed without any error on prodution server (which environement is indicated in this issue), but I get an exception when I test it. The exceptions occurs when I call a JSP, not precompiled and so compiled on-the-fly by jbossweb (as on developpement servers where it works fine). Then I get a NoSuchMethodException about getParams() on org.apache.commons.httpclient.HttpConnectionManager. In fact this method doesn't exist in commons-httpclient 2.x included in JBoss, that why I include it as lib in EAR, and isolate this one. If I replace the commons-httpclient in jboss/server/default/lib by mine it works fine. I've tested on 3 other server with the same JBoss, same JVM and same EAR, it works on the others. I'm sure JBoss/JVM/EAR are absolutely the same as on the production server because in fact I've make a tar file of all this on the server before transfering it on the 3 others. 2 of these test server have the same linux version (kernel), excepted SMP support. Here is where I'm. In fact now I really don't know what could cause this difference, and prevent EAR from working on production jboss server. Could it be related to the SMP (2 cpu) ? Does in this case jbossweb compile with a different classloader for the second cpu ? Maybe silly but I haven't real idea. So please if you can give some useful information. -- 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

14 years, 11 months

3
3
0 / 0

[JBoss JIRA] Created: (JBAS-4249) isUserInRole returns always false when jacc is enabled and the principal roles are empty

by Roland Räz (JIRA)

isUserInRole returns always false when jacc is enabled and the principal roles are empty ---------------------------------------------------------------------------------------- Key: JBAS-4249 URL: http://jira.jboss.com/jira/browse/JBAS-4249 Project: JBoss Application Server Issue Type: Bug Security Level: Public (Everyone can see) Components: Web (Tomcat) service Affects Versions: JBossAS-4.0.5.GA Reporter: Roland Räz Assigned To: Remy Maucherat We are using our won jacc policy and login modules that don't add (cache) the roles in the principal. In this situation, the org.jboss.web.tomcat.security.JaccAuthorizationRealm hasRole method always returns false. The reason behind that is that the method hasRole setups a Principal array that does not contain the principal itself (only the roles are contained) when getPrincipalRoles return a not null Set. The getPrincipalRoles retuns for the above described setup not null. The following code fixes the issue: public boolean hasRole(Principal principal, String name) { ... Principal[] principals = {principal}; Set roles = getPrincipalRoles(principal); if( roles != null ) { principals = new Principal[roles.size() + 1]; principals[0]= principal; Iterator it = roles.iterator(); for (int i=1;it.hasNext();i++) { principals[i] =(Principal) it.next(); } } ... In my opinion it would be even cleaner to use only the Principal and do not using the principal roles as own identity when querying a jacc provider. JBoss could then still extract in it's own jacc provider the principal roles from the principal. In the current design there is a clash between the role and principal names. The better solution is used in the EJB 2.x code (org.jboss.ejb.enterpriseContext.isCallerInRoleCheckForJacc(); It looks like this for servlets: ... Principal[] principals = {principal}; ... -- 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

14 years, 11 months

2
1
0 / 0

[JBoss JIRA] Created: (JBRULES-1168) jsr94, create stateful rule session, allow to set keepReference

by Juergen none (JIRA)

jsr94, create stateful rule session, allow to set keepReference --------------------------------------------------------------- Key: JBRULES-1168 URL: http://jira.jboss.com/jira/browse/JBRULES-1168 Project: JBoss Rules Issue Type: Feature Request Security Level: Public (Everyone can see) Components: JSR94 Affects Versions: 4.0.1 Reporter: Juergen none Assigned To: Mark Proctor Priority: Minor org.drools.jsr94.rules.StatefulRuleSessionImpl currently calls initSession() with constant value true for keepReference. Would be nice if this could be configurable via properties map. -- 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

14 years, 11 months

3
5
0 / 0

[JBoss JIRA] Created: (JBAS-3768) Define initial persistent format of the profile repository

by Scott M Stark (JIRA)

Define initial persistent format of the profile repository ---------------------------------------------------------- Key: JBAS-3768 URL: http://jira.jboss.com/jira/browse/JBAS-3768 Project: JBoss Application Server Issue Type: Sub-task Security Level: Public (Everyone can see) Components: Deployment services Reporter: Scott M Stark Assigned To: Scott M Stark Fix For: JBossAS-5.0.0.Beta We need to define the initial profile repository format with consideration of future migrations, jsr88, admin tools. -- 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

14 years, 11 months

6
11
0 / 0

[JBoss JIRA] Created: (JBAS-4585) Properties not being correctly parsed on JCA

by Clebert Suconic (JIRA)

Properties not being correctly parsed on JCA -------------------------------------------- Key: JBAS-4585 URL: http://jira.jboss.com/jira/browse/JBAS-4585 Project: JBoss Application Server Issue Type: Bug Security Level: Public (Everyone can see) Affects Versions: JBossAS-5.0.0.Beta3 Reporter: Clebert Suconic Fix For: JBossAS-5.0.0.Beta3 -- 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

14 years, 11 months

9
18
0 / 0

[JBoss JIRA] Created: (JBAS-3417) SocketException during minimal tests

by Jaroslaw Kijanowski (JIRA)

SocketException during minimal tests ------------------------------------ Key: JBAS-3417 URL: http://jira.jboss.com/jira/browse/JBAS-3417 Project: JBoss Application Server Issue Type: Bug Security Level: Public (Everyone can see) Affects Versions: JBossAS-5.0.0.Beta Environment: win xp, fedora core 5 Reporter: Jaroslaw Kijanowski while running the first test of the testsuite (jboss-minimal-tests), get a java.net.SocketException. server.log: 2006-07-22 17:05:55,046 DEBUG [org.jboss.deployment.MainDeployer] End deployment start on package: jboss-service.xml 2006-07-22 17:05:55,046 DEBUG [org.jboss.deployment.MainDeployer] Deployed package: file:/D:/jboss3/jboss-head/build/output/jboss-5.0.0.Beta/server/minimal/conf/jboss-service.xml 2006-07-22 17:05:55,046 INFO [org.jboss.system.server.Server] JBoss (MX MicroKernel) [5.0.0.Beta (build: CVSTag=HEAD date=200607220701)] Started in 3s:359ms 2006-07-22 17:05:55,281 DEBUG [org.jboss.naming.NamingService] Error writing response to /127.0.0.1 java.net.SocketException: Software caused connection abort: socket write error at java.net.SocketOutputStream.socketWrite0(Native Method) at java.net.SocketOutputStream.socketWrite(SocketOutputStream.java:92) at java.net.SocketOutputStream.write(SocketOutputStream.java:136) at java.io.ObjectOutputStream$BlockDataOutputStream.drain(ObjectOutputStream.java:1676) at java.io.ObjectOutputStream$BlockDataOutputStream.setBlockDataMode(ObjectOutputStream.java:1585) at java.io.ObjectOutputStream.writeNonProxyDesc(ObjectOutputStream.java:1167) at java.io.ObjectOutputStream.writeClassDesc(ObjectOutputStream.java:1121) at java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java:1278) at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1073) at java.io.ObjectOutputStream.writeFatalException(ObjectOutputStream.java:1392) at java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java:294) at org.jnp.server.Main$BootstrapRequestHandler.run(Main.java:476) at org.jboss.util.threadpool.RunnableTaskWrapper.run(Unknown Source) at EDU.oswego.cs.dl.util.concurrent.PooledExecutor$Worker.run(PooledExecutor.java:743) at java.lang.Thread.run(Thread.java:595) -- 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

14 years, 11 months

3
2
0 / 0

[JBoss JIRA] Created: (JBPORTAL-1287) enabling prepare-statement-cache throws error during startup

by Prabhat Jha (JIRA)

enabling prepare-statement-cache throws error during startup ------------------------------------------------------------ Key: JBPORTAL-1287 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1287 Project: JBoss Portal Issue Type: Bug Security Level: Public (Everyone can see) Affects Versions: 2.6.Alpha2 Environment: QA: jboss running on cluster01, mysql5 running on cluster08, jdk1.4, jboss-portal.sar as of 2007 Feb, 21. Reporter: Prabhat Jha This happens on my end when prepared-statement-cache is on. Here is my portal-mysql5-ds.xml: <datasources> <local-tx-datasource> <jndi-name>PortalDS</jndi-name> <connection-url>jdbc:mysql://10.16.0.103:3306/portal?jdbcCompliantTruncation=false</connection-url> <driver-class>com.mysql.jdbc.Driver</driver-class> <user-name>portal</user-name> <password></password> <min-pool-size>20</min-pool-size> <max-pool-size>40</max-pool-size> <prepared-statement-cache-size>100</prepared-statement-cache-size> </local-tx-datasource> </datasources> Once I comment out the prepared-statement-cache-size, then it starts fine. Given that Julien has not been able to reproduced on his end, he probably needs to have access to this environment or I have to see if I can reproduce in his environment. -- 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

14 years, 11 months

2
4
0 / 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira October 2007