[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, 4 months
[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, 4 months
[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
[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
[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
[JBoss JIRA] Created: (EJBTHREE-760) @WebServiceRef not bound to java:comp/env
by Thomas Diesler (JIRA)
@WebServiceRef not bound to java:comp/env
-----------------------------------------
Key: EJBTHREE-760
URL: http://jira.jboss.com/jira/browse/EJBTHREE-760
Project: EJB 3.0
Issue Type: Bug
Reporter: Thomas Diesler
Assigned To: Carlo de Wolf
package org.jboss.test.ws.jaxws.webserviceref;
@WebServiceRef(name = "service1", value = TestEndpointService.class, wsdlLocation = "META-INF/wsdl/TestEndpoint.wsdl")
@WebServiceRefs( {
@WebServiceRef(name = "service2", value = TestEndpointService.class, wsdlLocation = "META-INF/wsdl/TestEndpoint.wsdl"),
@WebServiceRef(name = "port1", value = TestEndpointService.class, type = TestEndpoint.class, wsdlLocation = "META-INF/wsdl/TestEndpoint.wsdl") })
public class ApplicationClient
When the client is deployed, I see the first reference beeing bound to jbossws-client/env/service1
However,
ports.add(((TestEndpointService)encCtx.lookup("java:comp/env/service1")).getTestEndpointPort());
fails with javax.naming.NameNotFoundException: service1 not bound
To reproduce run this against jbossas/branches/JEE5_TCK
/home/tdiesler/svn/jbossws/trunk/src/test
[tdiesler@tddell test]$ ant -Dtest=jaxws/webserviceref test
--
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
[JBoss JIRA] Created: (JBAS-4813) EAR with WAR classloading isolation & commons-httpclient
by C￩dric Chantepie (JIRA)
EAR with WAR classloading isolation & commons-httpclient
--------------------------------------------------------
Key: JBAS-4813
URL: http://jira.jboss.com/jira/browse/JBAS-4813
Project: JBoss Application Server
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: ClassLoading, Web (Tomcat) service
Affects Versions: JBossAS-4.0.5.GA, JBossAS-4.0.3 SP1
Environment: Linux 2.6.11-1.1369_FC4smp (Fedora Core 4) 2005 i686 i686 i386 GNU/Linux
jrockit-R26.4.0-jdk1.5.0_06
Reporter: C￩dric Chantepie
Assigned To: Scott M Stark
Priority: Blocker
We have an EAR including 4 modules :
- an ejb .jar,
- persistence .har
- 2 webapps.
3 modules -- the ejb .jar and the 2 webapps, depends on commons-httpclient 3.1, different from jboss version which 2.x, so I've first maid the EAR isolated by adding the jboss-app.xml with instruction given in JBoss wiki about EAR classloading.
== META-INF/jboss-app.xml ==
<!DOCTYPE jboss-app PUBLIC "-//JBoss//DTD J2EE Application 1.4//EN"
"http://www.jboss.org/j2ee/dtd/jboss-app_4_0.dtd">
<jboss-app>
<loader-repository>my.package:loader=My.ear
<loader-repository-config>java2ParentDelegation=false</loader-repository-config>
</loader-repository>
<jmx-name>my.package:module=My.ear</jmx-name>
<module>
<har>MyPersistence.har</har>
</module>
</jboss-app>
Then I've added Class-Path attribute in ejb .jar manifest.
== ejb.jar | META-INF/MANIFEST.MF ==
Manifest-Version: 1.0
Class-Path: lib/commons-httpclient-3.1.jar lib/commons-codec-1.2.jar l
ib/lucene-core-2.0.0.jar lib/commons-lang-2.3.jar lib/j2cdk.jar lib/l
ucene-analyzers-2.0.0.jar
(Line breaks there are as in MANIFEST.MF when I extract it from the jar.)
I've also manifest files in WAR for the 2 webapps, but I'm not sure jboss/jbossweb(tomcat) take care of it.
== webapp1.war | META-INF/MANIFEST.MF ==
Manifest-Version: 1.0
Class-Path: lib/a-web-lib.jar lib/commons-beanutils-1.7.0.jar li
b/commons-beanutils-core-1.7.0.jar lib/commons-digester-1.6.jar lib/c
ommons-fileupload-1.0.jar lib/j2cdk-taglib.jar lib/j2cdk.jar lib/jgen
.jar lib/jstl.jar lib/standard.jar lib/struts-1.2.9.jar lib/taglibs-m
ailer.jar lib/commons-httpclient-3.1.jar
== webapp2.war | META-INF/MANIFEST.MF ==
Manifest-Version: 1.0
Class-Path: lib/a-web-lib.jar lib/commons-beanutils-1.7.0.jar li
b/commons-beanutils-core-1.7.0.jar lib/commons-digester-1.6.jar lib/j
2cdk-taglib.jar lib/j2cdk.jar lib/jgen.jar lib/jstl.jar lib/standard.
jar lib/struts-1.2.9.jar lib/taglibs-mailer.jar lib/htmlparser-1.0-SN
APSHOT.jar lib/commons-httpclient-3.1.jar
And I've also jboss-web.xml files in these two WAR, even if there are included when deployed inside EAR (which is the top deployment in this case), with the same load repository specified "my.package:loader=My.ear".
== webapp1.war | WEB-INF/MANIFEST.MF ==
<?xml version='1.0' encoding='UTF-8'?>
<!DOCTYPE jboss-web
PUBLIC "-//JBoss//DTD Web Application 2.3V2//EN"
"http://www.jboss.org/j2ee/dtd/jboss-web_3_2.dtd">
<jboss-web>
<context-root>/BO</context-root>
<virtual-host>www.my-vhost.com</virtual-host>
<class-loading java2ClassLoadingCompliance="false">
<loader-repository>my.package:loader=My.ear
<loader-repository-config>java2ParentDelegation=false</loader-repository-config>
</loader-repository>
</class-loading>
</jboss-web>
== webapp2.war | WEB-INF/MANIFEST.MF ==
<?xml version='1.0' encoding='UTF-8'?>
<!DOCTYPE jboss-web
PUBLIC "-//JBoss//DTD Web Application 2.3V2//EN"
"http://www.jboss.org/j2ee/dtd/jboss-web_3_2.dtd">
<jboss-web>
<context-root>/</context-root>
<virtual-host>www.my-vhost.com</virtual-host>
<class-loading java2ClassLoadingCompliance="false">
<loader-repository>my.package:loader=My.ear
<loader-repository-config>java2ParentDelegation=false</loader-repository-config>
</loader-repository>
</class-loading>
</jboss-web>
Ok, that the situation. All work well on several developpement servers (tested on 3 linux hosts and 1 os x), it can be deployed without any error on prodution server (which environement is indicated in this issue), but I get an exception when I test it.
The exceptions occurs when I call a JSP, not precompiled and so compiled on-the-fly by jbossweb (as on developpement servers where it works fine). Then I get a NoSuchMethodException about getParams() on org.apache.commons.httpclient.HttpConnectionManager. In fact this method doesn't exist in commons-httpclient 2.x included in JBoss, that why I include it as lib in EAR, and isolate this one.
If I replace the commons-httpclient in jboss/server/default/lib by mine it works fine.
I've tested on 3 other server with the same JBoss, same JVM and same EAR, it works on the others. I'm sure JBoss/JVM/EAR are absolutely the same as on the production server because in fact I've make a tar file of all this on the server before transfering it on the 3 others.
2 of these test server have the same linux version (kernel), excepted SMP support.
Here is where I'm. In fact now I really don't know what could cause this difference, and prevent EAR from working on production jboss server. Could it be related to the SMP (2 cpu) ? Does in this case jbossweb compile with a different classloader for the second cpu ? Maybe silly but I haven't real idea.
So please if you can give some useful information.
--
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, 5 months