May 2007 - jboss-jira - Jboss List Archives

[JBoss JIRA] Created: (JBAS-4313) Cluster looses his master

by Bernd Köcke (JIRA)

Cluster looses his master ------------------------- Key: JBAS-4313 URL: http://jira.jboss.com/jira/browse/JBAS-4313 Project: JBoss Application Server Issue Type: Bug Security Level: Public (Everyone can see) Components: Clustering Affects Versions: JBossAS-4.2.0.CR1, JBossAS-4.0.5.GA, JBossAS-4.0.4.GA, JBossAS-4.0.2 Final Environment: Linux 2.6.x, Sun-JVM 1.5.0_11-b03, 1.6.0-b105, JBoss 4.0.2.final, but the code which causes the problem seems to be present up to version 4.2.0.CR1, cluster with two or more nodes. Reporter: Bernd Köcke Assigned To: Brian Stansberry In a cluster with two nodes (node_a and node_b) under a high workload it is possible that a restarted node, which is not the master, rejoins the cluster before the master recognised that the old node has gone away. The result is, that the restarted node seems to appear in the clusterview twice. The problem is the DistributedReplicantManagerImpl (DRMI) and ClusterPartition. Via the setCurrentState-method of DRMI on node_b the replicants-map is set, this map contains the old dead node node_bo. The key for the new node_b (node_bn) and the old one is the same: node_b:1199. When the master recognised that node_bo is dead he sends a new clusterview without the old node: node_a, node_b(n). But because of the implementation in HAPartitionImpl.getDeadMembers and DRMI.membershipChanged node_bo is never removed from the replicants map of node_bn's DRMI. If after this node_a is restarted, node_bn is the new master. JGroups knows this, but not the DRMI not and because of the old node in the replicants-map he returns 'false' from 'isMasterReplica' for every service. The restarted node_a is not the first in the clusterview and so there is no master. This situation is stable until node_bn is restarted. The cause of the problem is the method ClusterPartition.generateUniqueNodeName. If the JNDI-Subsystem is working, the method generates this nodename: <server name>:<JNDI port>. This is not unique across a node restart. To 'solve' the problem I commented out the return statement for the JNDI-based nodename. Then the method generates a name like this: <server name>:<generated UID>. This is set as additional data in JGroups and in turn used as key in the various maps in DRMI. With this fix node_bo is removed from the replicants map. But the clusterview looks a little bit ugly because of the UID. May be that others want to stay with the JNDI-Port. So my suggestion would be to make it a configuration option, to use always the UID instead of the JNDI-Port and the default can be the JNDI-Port. Because it could be that someone uses the nodenames of the clusterview to determine the JNDI-Port of the other members. But by changing this, I found a deadlock condition in DRMI. I will post another bugreport for this, it seems to affect only version 4.0.2. -- 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

18 years, 6 months

3
4
0 / 0

[JBoss JIRA] Created: (JBAS-4292) Legacy MainDeployer.deploy use of checkIncomplete causes leaks/test failures

by Scott M Stark (JIRA)

Legacy MainDeployer.deploy use of checkIncomplete causes leaks/test failures ---------------------------------------------------------------------------- Key: JBAS-4292 URL: http://jira.jboss.com/jira/browse/JBAS-4292 Project: JBoss Application Server Issue Type: Bug Security Level: Public (Everyone can see) Components: Deployment services, Test Suite Affects Versions: JBossAS-5.0.0.Beta2 Reporter: Scott M Stark Assigned To: Dimitris Andreadis Fix For: JBossAS-5.0.0.Beta3 If one adds a checkIncomplete call to validate a deployment in the legacy org.jboss.deployment.MainDeployer used by the testsuite deploy calls, there are additional failures and memory leaks that prevent the run from completing. It appears that tests are not cleaning up after failed deployments. -- 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

18 years, 6 months

6
12
0 / 0

[JBoss JIRA] Created: (JBREM-557) need to include all the transports within the tests.versioning ant target

by Tom Elrod (JIRA)

need to include all the transports within the tests.versioning ant target ------------------------------------------------------------------------- Key: JBREM-557 URL: http://jira.jboss.com/jira/browse/JBREM-557 Project: JBoss Remoting Issue Type: Task Security Level: Public (Everyone can see) Components: general Affects Versions: 2.0.0.Beta2 (Boon) Reporter: Tom Elrod Assigned To: Tom Elrod Fix For: 2.2.0.Beta1 (Bluto) Due to a problem with the test setup, some of the versioning tests (for rmi and socket) do not pass when running the versioning tests. Know these actually work when run manually, so need to investigate why automated tests are failing. -- 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

18 years, 6 months

2
4
0 / 0

[JBoss JIRA] Created: (JBREM-643) configuration for multi-homed server invokers

by Tom Elrod (JIRA)

configuration for multi-homed server invokers --------------------------------------------- Key: JBREM-643 URL: http://jira.jboss.com/jira/browse/JBREM-643 Project: JBoss Remoting Issue Type: Feature Request Security Level: Public (Everyone can see) Components: general Affects Versions: 2.2.0.Alpha4 Reporter: Tom Elrod Assigned To: Tom Elrod Fix For: 2.2.0.Beta1 (Bluto) Need to allow explicit configuration for multi-homed systems so can be done via one Connector with multiple bindings. -- 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

18 years, 6 months

3
6
0 / 0

[JBoss JIRA] Created: (JBAS-3532) Inject DRM and DS into ClusterPartition

by Brian Stansberry (JIRA)

Inject DRM and DS into ClusterPartition --------------------------------------- Key: JBAS-3532 URL: http://jira.jboss.com/jira/browse/JBAS-3532 Project: JBoss Application Server Issue Type: Sub-task Security Level: Public (Everyone can see) Components: Clustering Reporter: Brian Stansberry Assigned To: Brian Stansberry Fix For: JBossAS-5.0.0.Beta DRM and DS are now independent services. Inject them into ClusterPartiton so they can be exposed via HAPartition. ClusterPartition in create or start must confirm that the injected DRM and DS are using the same JChannelFactory and stack that it is. -- 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

18 years, 6 months

5
8
0 / 0

[JBoss JIRA] Created: (JBAS-4261) Resolve JBAS-4229 issue for AS 5

by Brian Stansberry (JIRA)

Resolve JBAS-4229 issue for AS 5 -------------------------------- Key: JBAS-4261 URL: http://jira.jboss.com/jira/browse/JBAS-4261 Project: JBoss Application Server Issue Type: Sub-task Security Level: Public (Everyone can see) Components: Clustering Reporter: Brian Stansberry Assigned To: Brian Stansberry Fix For: JBossAS-5.0.0.CR1 Port JBAS-4229 fix to trunk, but here we'll likely change the DRM.ReplicantListener API to pass merge whether a topology change was due to a merge. -- 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

18 years, 6 months

1
1
0 / 0

[JBoss JIRA] Created: (JBAOP-290) Make src/build.xml work

by Kabir Khan (JIRA)

Make src/build.xml work ----------------------- Key: JBAOP-290 URL: http://jira.jboss.com/jira/browse/JBAOP-290 Project: JBoss AOP Issue Type: Task Security Level: Public (Everyone can see) Reporter: Kabir Khan Assigned To: Kabir Khan Fix For: 2.0.0.alpha2 Should be part of the dist and it should be possible to build the full aop/aspects releases and run some of the tests -- 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

18 years, 6 months

3
13
0 / 0

[JBoss JIRA] Created: (JBAS-3815) Deployment Level Principal-Role Mapping passed to authorization layer

by Anil Saldhana (JIRA)

Deployment Level Principal-Role Mapping passed to authorization layer --------------------------------------------------------------------- Key: JBAS-3815 URL: http://jira.jboss.com/jira/browse/JBAS-3815 Project: JBoss Application Server Issue Type: Feature Request Security Level: Public (Everyone can see) Components: Security Affects Versions: JBossAS-5.0.0.Beta Reporter: Anil Saldhana Assigned To: Anil Saldhana Fix For: JBossAS-5.0.0.Beta Since the JBoss 4.0.x days, the deployment level rolename to principal set mapping is available in the meta data, but there was no usage of this in the authorization layer. There is a need for this information to be passed to the authorization manager/mapping layer. Affects the ejb3, ejb21 and web layers [jboss.xml,jboss-web.xml and jboss-app.xml] -- 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

18 years, 6 months

3
6
0 / 0

[JBoss JIRA] Created: (JBAS-3921) Merge JBCLUSTER-150 fixes with 4.0.5.GA tag

by Vivek Lakshmanan (JIRA)

Merge JBCLUSTER-150 fixes with 4.0.5.GA tag ------------------------------------------- Key: JBAS-3921 URL: http://jira.jboss.com/jira/browse/JBAS-3921 Project: JBoss Application Server Issue Type: Support Patch Security Level: Public (Everyone can see) Affects Versions: JBossAS-4.0.5.GA Reporter: Vivek Lakshmanan Assigned To: Brian Stansberry Fixes from https://svn.jboss.org/repos/jbossas/tags/JBoss_4_0_5_GA_EJBTHREE-798 need merging into a branch off the 4.0.5GA tag so they can be picked up by the patch process. No tag needs to be made on this branch as long as the branch's head satisfactorily fixes the JBCLUSTER-150 issues. -- 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

18 years, 6 months

4
10
0 / 0

[JBoss JIRA] Created: (JBAS-3934) Backport JBAS-3460 to Branch_4_2

by Brian Stansberry (JIRA)

Backport JBAS-3460 to Branch_4_2 -------------------------------- Key: JBAS-3934 URL: http://jira.jboss.com/jira/browse/JBAS-3934 Project: JBoss Application Server Issue Type: Sub-task Security Level: Public (Everyone can see) Components: Clustering, Web (Tomcat) service Reporter: Brian Stansberry Assigned To: Brian Stansberry The additions to jboss-web.xml should be backported. My inclination is not to remove the default snapshot mode/interval config from the Tomcat SAR config though, as 4.2 is not a major release. -- 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

18 years, 6 months

2
2
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 May 2007