May 2007 - jboss-jira - Jboss List Archives

[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

14 years, 3 months

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

14 years, 3 months

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

14 years, 3 months

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

14 years, 3 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

14 years, 3 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

14 years, 3 months

8
11
0 / 0

[JBoss JIRA] Created: (JBAS-4451) SNMP Adaptor of JBOSS does not handle the read community properly, it responds with "public" community instead of custom one.

by Pascal Heraud (JIRA)

SNMP Adaptor of JBOSS does not handle the read community properly, it responds with "public" community instead of custom one. ----------------------------------------------------------------------------------------------------------------------------- Key: JBAS-4451 URL: http://jira.jboss.com/jira/browse/JBAS-4451 Project: JBoss Application Server Issue Type: Bug Security Level: Public (Everyone can see) Components: Management services Affects Versions: JBossAS-4.0.5.GA Environment: Tested on REDHAT enterprise, JDK 1.5.0 Reporter: Pascal Heraud Assigned To: Dimitris Andreadis I'm using JBOSS SnmpAdaptor to monitor jboss and my web application. Ive modified the read community of the snmp adaptor into the META-INF/jboss-service.xml configuration file : <attribute name="ReadCommunity">myCommunity</attribute> The software we're using for monitoring is using the PERL implementation NET-SNMP and is issuing errors because JBOSS does not reply using the good ReadCommunity (it responds using "public"). We tried with snmpwalk and you can find the logs. Pascal. Here is the details of the snmpwalk to the server, the -d options outputs the buffzer ======================================================= >snmpwalk -d -v1 -c myCommunity localhost:1161 1.2.3.4.1.2 Sending 43 bytes to UDP: [127.0.0.1]:1161 0000: 30 29 02 01 00 04 0B 6D 79 43 6F 6D 6D 75 6E 69 0).....myCommuni 0016: 74 79 A1 17 02 02 38 B6 02 01 00 02 01 00 30 0B tyí...8Â......0. 0032: 30 09 06 05 2A 03 04 01 02 05 00 0 ..*...... Received 42 bytes from UDP: [127.0.0.1]:1161 0000: 30 28 02 01 00 04 06 70 75 62 6C 69 63 A2 1B 02 0(.....publicó.. 0016: 02 38 B6 02 01 00 02 01 00 30 0F 30 0D 06 05 2A .8Â......0.0...* 0032: 03 04 01 03 42 04 1F A5 00 00 ....B..Ñ.. Sending 43 bytes to UDP: [127.0.0.1]:1161 0000: 30 29 02 01 00 04 0B 6D 79 43 6F 6D 6D 75 6E 69 0).....myCommuni 0016: 74 79 A0 17 02 02 38 B7 02 01 00 02 01 00 30 0B tyá...8À......0. 0032: 30 09 06 05 2A 03 04 01 02 05 00 0 ..*...... Received 42 bytes from UDP: [127.0.0.1]:1161 0000: 30 28 02 01 00 04 06 70 75 62 6C 69 63 A2 1B 02 0(.....publicó.. 0016: 02 38 B7 02 01 00 02 01 00 30 0F 30 0D 06 05 2A .8À......0.0...* 0032: 03 04 01 02 42 04 05 55 4A D8 ....B..UJÏ iso.2.3.4.1.2 = Gauge32: 89475800 -- 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, 4 months

2
1
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, 4 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, 4 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, 4 months

6
12
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira May 2007