November 2007 - jboss-jira - Jboss List Archives

[JBoss JIRA] Created: (JBPORTAL-1819) WSDL status should be persisted in the database for better handling

by Chris Laprun (JIRA)

WSDL status should be persisted in the database for better handling ------------------------------------------------------------------- Key: JBPORTAL-1819 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1819 Project: JBoss Portal Issue Type: Feature Request Security Level: Public (Everyone can see) Components: Portal WSRP Affects Versions: 2.6.3 Final Reporter: Chris Laprun Assigned To: Chris Laprun Fix For: 2.8 Final -- 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, 4 months

1
1
0 / 0

[JBoss JIRA] Created: (JBAS-4531) AsynchEventHandler should ignore queueEvent calls when stopped

by Brian Stansberry (JIRA)

AsynchEventHandler should ignore queueEvent calls when stopped -------------------------------------------------------------- Key: JBAS-4531 URL: http://jira.jboss.com/jira/browse/JBAS-4531 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.CR1 AsynchEventHandler.queueEvent should not add events to its queue when it is stopped. If an event is added after stop() is called, it can sit there for a long period and then be handled if start() is called again. This could happen during a stop/start cycling of the HAPartition. This happens now with a MuxChannel that gets a viewAccepted as part of disconnecting -- ClusterPartition ends up putting an event in the stopped queue. That particular issue may go away if JGroups decides to not issue the view, but we should be sure to handle such a case properly. -- 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, 5 months

1
5
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, 5 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, 5 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, 5 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

16 years, 5 months

2
1
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

16 years, 5 months

7
10
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

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

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

16 years, 5 months

6
7
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 November 2007