April 2008 - jboss-jira - Jboss List Archives

[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, 7 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, 7 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, 7 months

8
11
0 / 0

[JBoss JIRA] Created: (JGRP-729) Support for NAT

by Bela Ban (JIRA)

Support for NAT --------------- Key: JGRP-729 URL: http://jira.jboss.com/jira/browse/JGRP-729 Project: JGroups Issue Type: Feature Request Reporter: Bela Ban Assigned To: Bela Ban Fix For: 2.8 Using external_addr, members behind NATs can communicate. However, members behind the same NAT cannot communicate as the NATted address is unknown [email by Terence Chan below]. We need to fix this with logical addresses, where the identity of a member is independent from the physical address I am using JGroups to connect multiple servers in 2 zones, separated by 2 firewalls with Network Address Translation (NAT). The servers cannot connect to each other due to NAT. The situation is as follows: -- Server A is behind Firewall A -- Server A's local address is 10.253.40.80 -- Server A's NAT address is 10.253.2.80 -- Server B is behind Firewall B -- Server B's local address is 172.16.80.33 -- Server B's NAT address is 10.1.1.39 When Server A initiates a connection to Server B, Server A sends a "connection message" with source address = its local address (ie., 10.253.40.80). Then, Server B replies a message with destination address = the source address of the original message (ie., Server A's local address). Since the local address (10.253.40.80) is not reachable, so Server A cannot receive the reply. Then I try to use "external_addr" attribute in the config file to set the message's source address to the NAT address. <TCP start_port="7900" external_addr="10.253.2.80" ...../> But, since the message's source address becomes NAT address, servers "within" the same network segment cannot send messages to each other, because NAT address is ONLY recognized by servers outside the firewall. For example, if Server A1 sends a message to another Server A2 in the same network segment, A2 cannot reply to A1 because A2 doesn't recognize A1's NAT address. For your reference, below is the error message when Server B sends a message to itself via its NAT address: 2008-03-27 20:36:55,871 DEBUG [ DownHandler (TCP)] jgroups.protocols.TCP#sendToSingleMember() - failure sending message to 10.1.1.39:7000 java.lang.Exception: connection to 10.1.1.39:7000 could not be established at org.jgroups.blocks.BasicConnectionTable.send(BasicConnectionTable.java:2 38) -- 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, 8 months

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

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

3
8
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, 8 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

14 years, 8 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, 8 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, 8 months

6
7
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira April 2008