February 2007 - jboss-jira - Jboss List Archives

[JBoss JIRA] Created: (JBREM-565) integration testing for 2.0.0 release

by Tom Elrod (JIRA)

integration testing for 2.0.0 release ------------------------------------- Key: JBREM-565 URL: http://jira.jboss.com/jira/browse/JBREM-565 Project: JBoss Remoting Issue Type: Task Security Level: Public (Everyone can see) Components: general Affects Versions: 2.0.0.CR1 (Boon) Reporter: Tom Elrod Assigned To: Tom Elrod Fix For: 2.0.0.GA (Boon) Need to do some integration testing with new 2.0.0.CR1 of remoting with JBossAS 4 & 5 to make sure everything is working correctly. -- 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

16 years, 1 month

2
3
0 / 0

[JBoss JIRA] Created: (JBAS-3770) JBoss/JCA JDBC implementation should allow for Transaction isolation level to be reset on underlying JDBC connection prior to return to pool

by Weston Price (JIRA)

JBoss/JCA JDBC implementation should allow for Transaction isolation level to be reset on underlying JDBC connection prior to return to pool -------------------------------------------------------------------------------------------------------------------------------------------- Key: JBAS-3770 URL: http://jira.jboss.com/jira/browse/JBAS-3770 Project: JBoss Application Server Issue Type: Feature Request Security Level: Public (Everyone can see) Reporter: Weston Price Assigned To: Weston Price Priority: Minor By default, when we return a JDBC connection to the pool we execute the following in the ManagedConnection.cleanup() method: if (jdbcTransactionIsolation != transactionIsolation) { try { con.setTransactionIsolation(jdbcTransactionIsolation); jdbcTransactionIsolation = transactionIsolation; } catch (SQLException e) { mcf.log.warn("Error resetting transaction isolation ", e); } } In this scenario we don't return the original isolation level on the underlying connection. The spec doesn't prohibit this, and I can't see any reason why we shouldn't do this, or provide a configurable option. -- 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

16 years, 1 month

3
4
0 / 0

[JBoss JIRA] Created: (JBAS-3440) HAPartitionImpl.viewAccepted should handle InterruptedException

by Brian Stansberry (JIRA)

HAPartitionImpl.viewAccepted should handle InterruptedException --------------------------------------------------------------- Key: JBAS-3440 URL: http://jira.jboss.com/jira/browse/JBAS-3440 Project: JBoss Application Server Issue Type: Task Security Level: Public (Everyone can see) Components: Clustering Reporter: Brian Stansberry Assigned To: Brian Stansberry Priority: Minor Fix For: JBossAS-5.0.0.Beta, JBossAS-4.0.6.CR1 The JGroups up thread may throw an InterruptedException when the view change is placed in the handler's queue. This can only happen if the channel is being stopped, so if it happens, the exception should be caught and the view change should be ignored. -- 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

16 years, 1 month

2
6
0 / 0

[JBoss JIRA] Created: (JBAS-3556) Add non-integration based testing to cluster module

by Brian Stansberry (JIRA)

Add non-integration based testing to cluster module --------------------------------------------------- Key: JBAS-3556 URL: http://jira.jboss.com/jira/browse/JBAS-3556 Project: JBoss Application Server Issue Type: Task Security Level: Public (Everyone can see) Components: Clustering, Test Suite Reporter: Brian Stansberry All the unit tests for the AS cluster module are run via the testsuite tests-clustering target, which starts two AS instances. This is painful and time consuming and discourages writing of simple unit tests that exercise a particular class, with no need for a larger integration. Need to set up a src/tests tree in the cluster module, add simple unit tests to it, and integrate that into the overall testsuite run. The security module has this kind of setup; look to that to see how the overall testsuite integration is done. -- 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

16 years, 1 month

2
5
0 / 0

[JBoss JIRA] Created: (JBAS-3632) Too early checking of not closing connections

by Adrian Brock (JIRA)

Too early checking of not closing connections --------------------------------------------- Key: JBAS-3632 URL: http://jira.jboss.com/jira/browse/JBAS-3632 Project: JBoss Application Server Issue Type: Bug Security Level: Public (Everyone can see) Components: JCA service Affects Versions: JBossAS-4.0.5.CR1 Reporter: Adrian Brock Assigned To: Weston Price Priority: Minor In the case where a transaction is ended early, e.g. JBossTM rollsback transactions at a timeout immediately, the cached connection manager is firing connection not closed events. This is because the ejb is still in the invocation with the connection open but the transaction synchronization is fired by the rollback/timeout. -- 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

16 years, 1 month

5
11
0 / 0

[JBoss JIRA] Created: (JBCLUSTER-131) Evaluate impact of message bundling in HttpSession replication performance

by Brian Stansberry (JIRA)

Evaluate impact of message bundling in HttpSession replication performance -------------------------------------------------------------------------- Key: JBCLUSTER-131 URL: http://jira.jboss.com/jira/browse/JBCLUSTER-131 Project: JBoss Clustering Issue Type: Task Security Level: Public (Everyone can see) Reporter: Brian Stansberry Assigned To: Brian Stansberry Fix For: Q3Y6 As described in http://wiki.jboss.org/wiki/Wiki.jsp?page=ProblemAndClusterRPCs the use of message bundling is not optimal for RPC calls. Essentially all clustering traffic in the AS is RPC calls, so we should evaluate the impact of disabling message bundling. I'm going to evaluate this using both REPL_SYNC and REPL_ASYNC. Any negative effect of bundling with REPL_ASYNC should be less, as the caller does not wait for the response. -- 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

16 years, 2 months

3
22
0 / 0

[JBoss JIRA] Created: (JBAS-3502) Use ProcessExpiresFrequency to speed tests involving session timeout

by Brian Stansberry (JIRA)

Use ProcessExpiresFrequency to speed tests involving session timeout -------------------------------------------------------------------- Key: JBAS-3502 URL: http://jira.jboss.com/jira/browse/JBAS-3502 Project: JBoss Application Server Issue Type: Task Security Level: Public (Everyone can see) Components: Clustering, Test Suite, Web (Tomcat) service Reporter: Brian Stansberry Priority: Minor Tomcat Manager impls expose a property ProcessExpiresFrequency, which controls how often the manager responds to the TC background process thread. By default it is set to 6, which means the manager does a session cleanup every 6 cycles. By default the thread runs every 10 secs, so that means session are expired once per minute. Need to add ProcessExpiresFrequency=1 to a context.xml deployed with session test webapps so we can reduce the time it takes for tests involving session expiration to complete. -- 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

16 years, 2 months

2
7
0 / 0

[JBoss JIRA] Created: (JBAS-4052) NPE in RepositoryClassLoader when loading BouncyCastle

by Jon Stevens (JIRA)

NPE in RepositoryClassLoader when loading BouncyCastle ------------------------------------------------------ Key: JBAS-4052 URL: http://jira.jboss.com/jira/browse/JBAS-4052 Project: JBoss Application Server Issue Type: Bug Security Level: Public (Everyone can see) Components: ClassLoading Affects Versions: JBossAS-4.0.5.GA Reporter: Jon Stevens Assigned To: Scott M Stark Occasionally, I will get the exception below when trying to load the bouncy castle library. One would think it is a problem in BC, except for the fact that the NPE is clearly coming from JBoss's RepositoryClassLoader. The hard part about this bug is that it happens some of the time and not other times. It's been impossible to reliably reproduce. Restarting the appserver/jvm causes the problem to go away and everything works just fine, but eventually it will happen again. BC is being started in a @Service Bean. The start() method looks like this: public void start() throws Exception { Security.addProvider(new BouncyCastleProvider()); } Has anyone else seen this problem? Caused by: java.security.NoSuchAlgorithmException: No such algorithm: AES/CBC/PKCS5Padding at javax.crypto.Cipher.getInstance(DashoA13*..) at javax.crypto.Cipher.getInstance(DashoA13*..) at com.kink.heart.biz.system.EncryptorBean.encrypt(EncryptorBean.java:349) ... 73 more Caused by: java.security.NoSuchAlgorithmException: Error constructing implementation (algorithm: AES, provider: BC, class: org.bouncycastle.jce.provider.JCEBlockCipher$AES) at java.security.Provider$Service.newInstance(Provider.java:1201) ... 76 more Caused by: java.lang.NullPointerException at org.jboss.mx.loading.RepositoryClassLoader.findClass(RepositoryClassLoader.java:620) at java.lang.ClassLoader.loadClass(ClassLoader.java:316) at org.jboss.mx.loading.RepositoryClassLoader.loadClassImpl(RepositoryClassLoader.java:464) at org.jboss.mx.loading.RepositoryClassLoader.loadClass(RepositoryClassLoader.java:405) at java.lang.ClassLoader.loadClass(ClassLoader.java:251) at java.security.Provider$Service.getImplClass(Provider.java:1218) at java.security.Provider$Service.newInstance(Provider.java:1176) ... 76 more -- 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

16 years, 2 months

8
11
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

16 years, 2 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

16 years, 2 months

6
12
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 February 2007