November 2008 - jboss-jira - Jboss List Archives

[JBoss JIRA] Created: (JBAS-6257) Typo in firebird-ds.xml

by Otsuji Nobutaka (JIRA)

Typo in firebird-ds.xml ----------------------- Key: JBAS-6257 URL: https://jira.jboss.org/jira/browse/JBAS-6257 Project: JBoss Application Server Issue Type: Quality Risk Affects Versions: JBossAS-4.2.3.GA Reporter: Otsuji Nobutaka There is a typo in docs/examples/jca/firebird-ds.xml: <tx-connection-factory> <jndi-name>FIrebirdDS</jndi-name> <xa-transaction/> should be <tx-connection-factory> <jndi-name>FirebirdDS</jndi-name> <xa-transaction/> -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/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-5929) Sub Pooling in JBossManagedConnectionPool MemoryLeak for sparse CRI coverage

by Adrian Brock (JIRA)

Sub Pooling in JBossManagedConnectionPool MemoryLeak for sparse CRI coverage ---------------------------------------------------------------------------- Key: JBAS-5929 URL: https://jira.jboss.org/jira/browse/JBAS-5929 Project: JBoss Application Server Issue Type: Bug Security Level: Public (Everyone can see) Components: JCA service Affects Versions: JBossAS-4.2.3.GA, JBossAS-5.0.0.CR1 Reporter: Adrian Brock Assignee: Jesper Pedersen Fix For: JBossAS-5.0.0.GA, JBossAS-4.2.4.GA If you look at this WIKI page, there is a caveat about "sub-pooling" within the JBossManagedConnectionPool http://wiki.jboss.org/wiki/ConfigJCACommon "Unless the ResourceAdapter has <reauthentication-support> using multiple security identities will create subpools for each identity." The way this works is that we hold a map of CRI->SubPool (CRI == ConnectionRequestInfo). If there is sparse coverage of the CRI parameter space, you can end up with lots of subpools which holds references to each CRI (the same issue also applies to pooling by Subject). The sub-pools will be empted by the IdleRemover, but the sub-pools themselves will be retained which could consume a lot a memory or even cause an OutOfMemoryError depending on the use case. Currently the only way to clear these subpools is manually flush() the pool which will remove all the sub-pools and allow them to be re-created as required. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 11 months

3
6
0 / 0

[JBoss JIRA] Created: (JBAS-5302) StatefulHandleImpl is not portable from client A to client B

by Bernd Zeitler (JIRA)

StatefulHandleImpl is not portable from client A to client B ------------------------------------------------------------ Key: JBAS-5302 URL: http://jira.jboss.com/jira/browse/JBAS-5302 Project: JBoss Application Server Issue Type: Bug Security Level: Public (Everyone can see) Components: EJB2 Affects Versions: JBossAS-4.2.3.GA Reporter: Bernd Zeitler Assigned To: Alexey Loubyansky The StatefulHandleImpl holds the jndiEnv after creation and uses these properties in getEJBObject. Since jndiEnv is not transient, the properties used on client A are passed within the handle to Client B. This can lead to problems when these two clients use different properties (e.g. different host names for the same physical machine or a different implementation of the NamingContextFactory). Example: client A resides on the JBoss server and realizes remote access to the server using localhost within his URL. A handle, created on this client and passed to client B, which resides on another machine, can not be used to get the EBJ object, since even this clients tries to connect to the server using a lookup on localhost. -- 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
8
0 / 0

[JBoss JIRA] Created: (JBAS-5703) Make HA-JNDI use wait for first positive response

by Galder Zamarreno (JIRA)

Make HA-JNDI use wait for first positive response ------------------------------------------------- Key: JBAS-5703 URL: http://jira.jboss.com/jira/browse/JBAS-5703 Project: JBoss Application Server Issue Type: Sub-task Security Level: Public (Everyone can see) Components: Clustering, Naming Reporter: Galder Zamarreno Assigned To: Galder Zamarreno Fix For: JBossAS-5.0.0.CR2 -- 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

4
14
0 / 0

[JBoss JIRA] Created: (JBAS-4666) MBean for new EjbDeployer

by Adrian Brock (JIRA)

MBean for new EjbDeployer ------------------------- Key: JBAS-4666 URL: http://jira.jboss.com/jira/browse/JBAS-4666 Project: JBoss Application Server Issue Type: Task Security Level: Public (Everyone can see) Components: EJB2 Reporter: Adrian Brock Fix For: JBossAS-5.0.0.GA I've reinstated the MBean for the EJBDeployer since some tests were using it. This uses the @JMX annotation on the POJO. The new deployer looks to have some bits missing related to verification which it what this task is about resolving. -- 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

7
10
0 / 0

[JBoss JIRA] Created: (JBAS-6066) JSR-196 integration for web layer (Client-CERT)

by Anil Saldhana (JIRA)

JSR-196 integration for web layer (Client-CERT) ----------------------------------------------- Key: JBAS-6066 URL: https://jira.jboss.org/jira/browse/JBAS-6066 Project: JBoss Application Server Issue Type: Sub-task Security Level: Public (Everyone can see) Components: Security, Web (Tomcat) service Reporter: Anil Saldhana Assignee: Anil Saldhana Fix For: JBossAS-5.0.1.CR1 Server auth module to ape SSLAuthenticator. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 11 months

3
6
0 / 0

[JBoss JIRA] Created: (JBAS-4227) [SnmpAgentService] MIB2SystemGroup violates RFC-1213

by Kenny MacLeod (JIRA)

[SnmpAgentService] MIB2SystemGroup violates RFC-1213 ---------------------------------------------------- Key: JBAS-4227 URL: http://jira.jboss.com/jira/browse/JBAS-4227 Project: JBoss Application Server Issue Type: Bug Security Level: Public (Everyone can see) Components: JMX Affects Versions: JBossAS-4.0.4.GA Reporter: Kenny MacLeod Assigned To: Dimitris Andreadis The SnmpAgentService exposes a standard MIB2 System Group. However, the OIDs that are produced violate RFC-1213, which dictates that the sysUpTime value should have a type of TimeTicks. Instead, SnmpAgentService generates a type of int32. Take the following output from snmpwalk: SNMPv2-MIB::sysDescr = STRING: Central Computer SNMPv2-MIB::sysObjectID = OID: SNMPv2-SMI::enterprises.18016.1.1.2 SNMPv2-MIB::sysUpTime = Wrong Type (should be Timeticks): Gauge32: 769331 SNMPv2-MIB::sysContact = STRING: Agent Smith SNMPv2-MIB::sysName = STRING: kizoom(a)10.10.0.208 SNMPv2-MIB::sysLocation = STRING: In The Matrix SNMPv2-MIB::sysServices = INTEGER: 64 End of MIB For systems which monitor SNMP agents (e.g. OpenNMS), this causes them to reject the agent because of the bad type. The bug lies in org.jboss.jmx.adaptor.snmp.agent.RequestHandlerImpl, which determines the type of the OID value by examining the type of the JMX attribute being monitored. It has no way to generate a TimeTicks value, it can only handle Long, String, Integer and SnmpOID types. The JBoss wiki states that RFC-1213 is supported, but this is incorrect when the type for sysUpTime is wrong (http://wiki.jboss.org/wiki/Wiki.jsp?page=JBossSNMPAdapterGetValues). Also the attributes.xml file in xnmp-adaptor.sar quotes RFC-1213. -- 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

4
8
0 / 0

[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: (JBAS-4974) Upgrade to log4j 1.2.15 in JBoss5.0

by cheng dan (JIRA)

Upgrade to log4j 1.2.15 in JBoss5.0 ----------------------------------- Key: JBAS-4974 URL: http://jira.jboss.com/jira/browse/JBAS-4974 Project: JBoss Application Server Issue Type: Feature Request Security Level: Public (Everyone can see) Components: Logging Affects Versions: JBossAS-5.0.0.Beta2 Reporter: cheng dan Assigned To: Scott M Stark Priority: Minor Please upgrade to the latest stable log4j release 1.2.15 in JBoss5.0 http://logging.apache.org/log4j/1.2/download.html -- 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
7
0 / 0

[JBoss JIRA] Created: (JBAS-6097) Move Log4jService into separate project

by Scott M Stark (JIRA)

Move Log4jService into separate project --------------------------------------- Key: JBAS-6097 URL: https://jira.jboss.org/jira/browse/JBAS-6097 Project: JBoss Application Server Issue Type: Sub-task Security Level: Public (Everyone can see) Components: Logging Affects Versions: JBossAS-5.0.0.CR2 Reporter: Scott M Stark Assignee: Scott M Stark Fix For: JBossAS-5.0.0.GA To pull the Log4jService into a bootstrap beans file it needs to be moved out of the jboss.jar and properly pojoized. The org.jboss.logging package from the server module is being moved to: https://svn.jboss.org/repos/jbossas/projects/log-services/ -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 11 months

5
9
0 / 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira November 2008