November 2008 - jboss-jira - Jboss List Archives

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

2
7
0 / 0

[JBoss JIRA] Created: (JBAS-5959) Intermittent failure in FieldGranularityClassloaderLeakUnitTestCase

by Brian Stansberry (JIRA)

Intermittent failure in FieldGranularityClassloaderLeakUnitTestCase ------------------------------------------------------------------- Key: JBAS-5959 URL: https://jira.jboss.org/jira/browse/JBAS-5959 Project: JBoss Application Server Issue Type: Bug Security Level: Public (Everyone can see) Components: AOP, Clustering, Web (Tomcat) service Affects Versions: JBossAS-5.0.0.CR1 Reporter: Brian Stansberry Assignee: Brian Stansberry Fix For: JBossAS-5.0.0.GA The FieldGranularityClassloaderLeakUnitTestCase intemittently fails (once every 5-10 hudson runs). Heap analysis (using JBoss Profiler or hprof+jhat) after a failure always shows all paths to the leaked CL leading to WeakReferences, so the cause of the leak is unclear. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 10 months

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

8
11
0 / 0

[JBoss JIRA] Created: (EJBTHREE-1603) EJB with dependencies upon itself fails deployment

by Andrew Lee Rubinger (JIRA)

EJB with dependencies upon itself fails deployment -------------------------------------------------- Key: EJBTHREE-1603 URL: https://jira.jboss.org/jira/browse/EJBTHREE-1603 Project: EJB 3.0 Issue Type: Bug Components: core Reporter: Andrew Lee Rubinger Assignee: Andrew Lee Rubinger Priority: Critical Fix For: 1.0.0-CR1 The following construct: @Stateless @Remote(SelfDependencyRemoteBusiness.class) @Local(SelfDependencyLocalBusiness.class) public class SelfDependencyBean implements SelfDependencyLocalBusiness, SelfDependencyRemoteBusiness { @EJB private SelfDependencyLocalBusiness local; ... } ...fails deployment: 21:55:09,828 WARN [MainDeployer] Failed to deploy: file:/home/alrubinger/business/jboss/wc/jbossas/projects/ejb3/trunk/testsuite/target/test-lib/ejbthreexxx.jar org.jboss.deployers.client.spi.IncompleteDeploymentException: Summary of incomplete deployments (SEE PREVIOUS ERRORS FOR DETAILS): *** CONTEXTS MISSING DEPENDENCIES: Name -> Dependency{Required State:Actual State} jboss.j2ee:jar=ejbthreexxx.jar,name=SelfDependencyBean,service=EJB3 -> <UNKNOWN jboss.j2ee:jar=ejbthreexxx.jar,name=SelfDependencyBean,service=EJB3>{Described:** UNRESOLVED Demands 'jndi:SelfDependencyBean/local-org.jboss.ejb3.test.ejbthreexxx.SelfDependencyLocalBusiness' **} *** CONTEXTS IN ERROR: Name -> Error <UNKNOWN jboss.j2ee:jar=ejbthreexxx.jar,name=SelfDependencyBean,service=EJB3> -> ** UNRESOLVED Demands 'jndi:SelfDependencyBean/local-org.jboss.ejb3.test.ejbthreexxx.SelfDependencyLocalBusiness' ** This is the cause of 3 regressions in "asynchronous" tests currently -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 11 months

5
10
0 / 0

[JBoss JIRA] Created: (JGRP-840) Probe: provide API to programmatically execute queries and handle results

by Bela Ban (JIRA)

Probe: provide API to programmatically execute queries and handle results ------------------------------------------------------------------------- Key: JGRP-840 URL: https://jira.jboss.org/jira/browse/JGRP-840 Project: JGroups Issue Type: Feature Request Reporter: Bela Ban Assignee: Bela Ban Priority: Minor Fix For: 2.8 Currently, probe gets its results as a plain text, read from a datagram socket. An API would allow clients to gets responses aggregated by cluster member, in hashmap format. A client should be able to register and get notified whenever a response was received, and also retrieve the entire response set after a timeout. Such an API makes it simpler for (e.g.) management applications to ping the cluster members and get information about them. Without the API, a client has to parse the returned text and arrange it into keys and values. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 11 months

1
3
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, 11 months

1
4
0 / 0

[JBoss JIRA] Created: (JBRULES-1711) Support for import/export pakages in BRMS

by Seegler Ittyavirah (JIRA)

Support for import/export pakages in BRMS ----------------------------------------- Key: JBRULES-1711 URL: https://jira.jboss.org/jira/browse/JBRULES-1711 Project: JBoss Drools Issue Type: Feature Request Security Level: Public (Everyone can see) Components: drools-brms Affects Versions: 4.0.7 Reporter: Seegler Ittyavirah Assignee: Mark Proctor In our usecase, we use a development BRMS install for developers and domain experts to create and test rule packages. Then these new/modified packages need to be copied/exported to a production BRMS. Currently BRMS supports import/export of whole repository only. Requesting import/export feature at package level. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 11 months

5
8
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, 11 months

2
1
0 / 0

[JBoss JIRA] Created: (JBAS-6171) Remove "bootstrap" module from AS into its own Project

by Andrew Lee Rubinger (JIRA)

Remove "bootstrap" module from AS into its own Project ------------------------------------------------------ Key: JBAS-6171 URL: https://jira.jboss.org/jira/browse/JBAS-6171 Project: JBoss Application Server Issue Type: Task Security Level: Public (Everyone can see) Reporter: Andrew Lee Rubinger Assignee: Andrew Lee Rubinger Fix For: JBossAS-5.0.0.GA Until "bootstrap" is given its own release cycle, projects that AS depend upon cannot reuse this component. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 11 months

4
8
0 / 0

[JBoss JIRA] Created: (JBAS-5523) Add Availability functionality. To know when a ManagedComponent is running or stopped, etc

by Mark Spritzler (JIRA)

Add Availability functionality. To know when a ManagedComponent is running or stopped, etc ------------------------------------------------------------------------------------------ Key: JBAS-5523 URL: http://jira.jboss.com/jira/browse/JBAS-5523 Project: JBoss Application Server Issue Type: Sub-task Security Level: Public (Everyone can see) Reporter: Mark Spritzler -- 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, 11 months

5
5
0 / 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira November 2008