December 2007 - jboss-jira - Jboss List Archives

[JBoss JIRA] Created: (JBAS-4893) JvmRouteValve (UseJK) for non session replication setup

by Takayoshi Kimura (JIRA)

JvmRouteValve (UseJK) for non session replication setup ------------------------------------------------------- Key: JBAS-4893 URL: http://jira.jboss.com/jira/browse/JBAS-4893 Project: JBoss Application Server Issue Type: Feature Request Security Level: Public (Everyone can see) Reporter: Takayoshi Kimura Currently JBoss doesn't install JvmRouteValve for non session replication setup. However, it's still useful in the following scenario: * 1 Apache HTTPD frontend and 2 JBoss AS instances without session replication * A request goes JBoss node AAA (JSESSIONID=xxx.AAA) * The node AAA crashed * The request goes node BBB, lost session, recreate another * The node AAA recovered * The request comes back to the node AAA, lost session again Enabling JvmRouteValve can prevent last failure. -- 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
10
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: (JGRP-646) ConnectionTable problem after a while in 2 node cluster

by Martin Vecera (JIRA)

ConnectionTable problem after a while in 2 node cluster ------------------------------------------------------- Key: JGRP-646 URL: http://jira.jboss.com/jira/browse/JGRP-646 Project: JGroups Issue Type: Bug Affects Versions: 2.4.1 SP4 Environment: Two physical machines both running RHEL5, Sun JVM 1.5.0_12, full SOA-P 4.2.0.IR8 based on EAP 4.3.0.GA (build: SVNTag=JBPAPP_4_3_0_GA date=200711291835), Orcale DB on a separate machine Reporter: Martin Vecera Assigned To: Bela Ban Reproducible: 100% 1. I took full IR8 and used dbinstall (https://svn.corp.jboss.com/repos/soa/trunk/qa/dbinstall/) for the 'all' configuration to use Oracle DB. 2. I unsecured jmx-service-invoker. 3. I copied the SOA-P to the second node. 4. I changed the server peer id on the both copies to be different. 5. I started the first node, it was successful. 6. I started the second node successfully as well. 7. I let it be for half an hour. 8. This appeared in the log files: Node 1: 2007-12-13 10:57:07,502 WARN [org.jgroups.blocks.ConnectionTable] peer closed connection, trying to re-send msg 2007-12-13 10:57:07,502 ERROR [org.jgroups.blocks.ConnectionTable] 2nd attempt to send data failed too Node 2: 2007-12-13 10:57:08,927 WARN [org.jgroups.blocks.ConnectionTable] peer closed connection, trying to re-send msg 2007-12-13 10:57:08,928 ERROR [org.jgroups.blocks.ConnectionTable] 2nd attempt to send data failed too It doesn't seem like there's anything related to the problems in the logs (no exceptions, no other JGroups related output...). -- 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

3
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, 4 months

5
11
0 / 0

[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

14 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

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

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

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira December 2007