March 2010 - jboss-jira - Jboss List Archives

[JBoss JIRA] Created: (JBAS-6095) Develop management interfaces for legacy clustering services

by Brian Stansberry (JIRA)

Develop management interfaces for legacy clustering services ------------------------------------------------------------ Key: JBAS-6095 URL: https://jira.jboss.org/jira/browse/JBAS-6095 Project: JBoss Application Server Issue Type: Task Security Level: Public (Everyone can see) Components: Clustering Reporter: Brian Stansberry Assignee: Brian Stansberry Priority: Minor Fix For: JBossAS-5.0.0.GA Develop @ManagedObject-based interfaces for beans in ha-legacy-jboss-beans.xml. -- 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
6
0 / 0

[JBoss JIRA] Created: (JBAS-6262) Move cluster module config files from src/etc to src/resources

by Brian Stansberry (JIRA)

Move cluster module config files from src/etc to src/resources -------------------------------------------------------------- Key: JBAS-6262 URL: https://jira.jboss.org/jira/browse/JBAS-6262 Project: JBoss Application Server Issue Type: Task Security Level: Public (Everyone can see) Components: Clustering Reporter: Brian Stansberry Assignee: Brian Stansberry Priority: Minor Fix For: JBossAS-5.0.1.CR1 Housekeeping. Some are already in src/resources; get them all in one place. -- 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
3
0 / 0

[JBoss JIRA] Updated: (JBAS-5156) Add script to ./bin directory of JBossAS which creates a cluster config

by Brian Stansberry (JIRA)

[ https://jira.jboss.org/jira/browse/JBAS-5156?page=com.atlassian.jira.plug... ] Brian Stansberry updated JBAS-5156: ----------------------------------- Fix Version/s: Backlog (was: JBossAS-6.0.0.M3) > Add script to ./bin directory of JBossAS which creates a cluster config > ----------------------------------------------------------------------- > > Key: JBAS-5156 > URL: https://jira.jboss.org/jira/browse/JBAS-5156 > Project: JBoss Application Server > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: Clustering > Reporter: Bela Ban > Assignee: Brian Stansberry > Priority: Minor > Fix For: Backlog > > > Example: > ./create-cluster-config > This creates node1 and node2 under JBOSS_HOME/server. > The script can be copied from one of the labs in the Clustering training -- 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

1
0
0 / 0

[JBoss JIRA] Created: (JBAS-3440) HAPartitionImpl.viewAccepted should handle InterruptedException

by Brian Stansberry (JIRA)

HAPartitionImpl.viewAccepted should handle InterruptedException --------------------------------------------------------------- Key: JBAS-3440 URL: http://jira.jboss.com/jira/browse/JBAS-3440 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.Beta, JBossAS-4.0.6.CR1 The JGroups up thread may throw an InterruptedException when the view change is placed in the handler's queue. This can only happen if the channel is being stopped, so if it happens, the exception should be caught and the view change should be ignored. -- 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
6
0 / 0

[JBoss JIRA] Created: (JBAS-7781) Update ClusteredDeploymentRepository to deal with VFS3

by Brian Stansberry (JIRA)

Update ClusteredDeploymentRepository to deal with VFS3 ------------------------------------------------------ Key: JBAS-7781 URL: https://jira.jboss.org/jira/browse/JBAS-7781 Project: JBoss Application Server Issue Type: Task Security Level: Public (Everyone can see) Components: Clustering, ProfileService Reporter: Brian Stansberry Assignee: Brian Stansberry Fix For: JBossAS-6.0.0.M3 There's really two aspects to this: 1) ClusteredDeploymemtRepository.removeDeployment can't use the VirtualFile from ProfileDeployment.getRoot() as an input the the RepositoryClusteringHandler, because that VF is now a special "backup" copy that the handler can't understand. This is the cause of a testsuite failure. 2) AbstractLocalContentManager should mount each of the URIs it monitors in a separate location, so it can scan the original contents even if some children of those URIs are actually copies created by deployers. -- 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

1
1
0 / 0

[JBoss JIRA] Updated: (JBAS-7205) Redeployment of session doesn't acquire session state

by Brian Stansberry (JIRA)

[ https://jira.jboss.org/jira/browse/JBAS-7205?page=com.atlassian.jira.plug... ] Brian Stansberry updated JBAS-7205: ----------------------------------- Fix Version/s: JBossAS-6.0.0.M4 (was: JBossAS-6.0.0.M3) > Redeployment of session doesn't acquire session state > ----------------------------------------------------- > > Key: JBAS-7205 > URL: https://jira.jboss.org/jira/browse/JBAS-7205 > Project: JBoss Application Server > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Clustering, Web (Tomcat) service > Affects Versions: JBossAS-5.1.0.GA > Reporter: Bela Ban > Assignee: Brian Stansberry > Fix For: JBossAS-6.0.0.M4 > > Attachments: web.war > > > Here's the scenario: > - Start instances A and B in a cluster, the webapp is session.war (*exploded* WAR) > - Create a session, say its session-id is sessionId.A > - Go to A and remove the WAR, e.g. cd ./deploy ; mv session.war session.war.bak > - Refresh the session. It fails over to B: sessionId.B > - Go back to A (/deploy dir) and mv session.war.bak session.war > - Go to B and remove the session > ==> The session will fail back to A, but the session's data is gone ! -- 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

1
0
0 / 0

[JBoss JIRA] Created: (JBAS-6859) See if a value-factory element in a -service.xml can create a dependency

by Brian Stansberry (JIRA)

See if a value-factory element in a -service.xml can create a dependency ------------------------------------------------------------------------ Key: JBAS-6859 URL: https://jira.jboss.org/jira/browse/JBAS-6859 Project: JBoss Application Server Issue Type: Sub-task Security Level: Public (Everyone can see) Reporter: Brian Stansberry Assignee: Brian Stansberry Fix For: JBossAS-6.0.0.Alpha1 I don't see code that will result in a dependency being created when a value-factory element appears in a -service.xml. I'm not sure at all if a dependency can be created, at least not without a ton of hacks. So this JIRA is mostly to look into it. -- 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

1
1
0 / 0

[JBoss JIRA] Created: (JBAS-6584) Clustered classloader leak test repeatedly times out on Solaris and HPUX

by Richard Achmatowicz (JIRA)

Clustered classloader leak test repeatedly times out on Solaris and HPUX ------------------------------------------------------------------------ Key: JBAS-6584 URL: https://jira.jboss.org/jira/browse/JBAS-6584 Project: JBoss Application Server Issue Type: Bug Security Level: Public (Everyone can see) Affects Versions: JBossAS-5.0.1.GA Environment: Solaris, HPUX platforms Reporter: Richard Achmatowicz The test case ClusteredClassloaderLeakUnitTest is repeatedly timing out, even when the junit.timeout for the test is extended from 180 secs (default) to 800 secs. This test seems to pass OK on RHEL with the usual timeout. This test deploys a war/ejb/ear, makes a few invocations, and then undeploys the war/ejb/ear. While doing so, it keeps a record of the classloaders deployed via an MBean ClassloaderTracker which is deployed before the tests start. It uses the record of classloaders registered to check that (ii) all classloaders are present when they should be (after deployment) and (ii) all classloaders are absent when they should be (after undeployment). The sequence of steps performed fror the war version of the test are: - checkCleanKeys - deployComponent - makeWebRequest - checkRegistration - undeployComponent - flushSecurityCache - checkClassloaderRelease The test currently performs two tests involving war deployments (tests for the other deployments have been commented out): testSimpleWar, testNoPassivationWar. The test testSimpleWar generally passes, after a substantial wait at checkClassloaderRelease. The test testNoPassivatioWar regularly hangs when it reaches checkClassloaderRelease. I'm not sure of this is a bug, as the test times out and does not fail an assertion; however, even tripling the time allowed for the test does not help. Something seems to be untoward in the method checkClassloaderRelease, which calls ClassloaderStore.getClassloader with the forceGC parameter set to true, and it is untoward only on these platforms. This test has been placed at the end of the testsuite, as it generally modifies the state of the servers so that they also will not shut down properly. This allows the testsuite to complete the generalion of reports and not waste a test run. -- 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

3
7
0 / 0

[JBoss JIRA] Created: (JBAS-7176) In TCP stacks, set use_send_queues to true

by Brian Stansberry (JIRA)

In TCP stacks, set use_send_queues to true ------------------------------------------ Key: JBAS-7176 URL: https://jira.jboss.org/jira/browse/JBAS-7176 Project: JBoss Application Server Issue Type: Task Security Level: Public (Everyone can see) Components: Clustering Reporter: Brian Stansberry Assignee: Brian Stansberry Fix For: JBossAS-5.2.0.Beta1 Per Bela: - use_send_queues: I found this valuable to prevent threads getting blocked in the TCP socket write phase, and therefore blocking other threads too. If you enable this, also set send_queue_size We'll need to figure out the appropriate send_queue_size. -- 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
2
0 / 0

[JBoss JIRA] Created: (JBAS-5165) Generic ProxyFactoryHA too dependent on deployment ordering

by Brian Stansberry (JIRA)

Generic ProxyFactoryHA too dependent on deployment ordering ----------------------------------------------------------- Key: JBAS-5165 URL: http://jira.jboss.com/jira/browse/JBAS-5165 Project: JBoss Application Server Issue Type: Bug Security Level: Public (Everyone can see) Components: Clustering Affects Versions: JBossAS-5.0.0.Beta3, JBossAS-4.2.2.GA Reporter: Brian Stansberry Assigned To: Brian Stansberry Fix For: JBossAS-5.0.0.CR1 org.jboss.proxy.generic.ProxyFactoryHA will not signal its HATarget to allow invocations to proceed until it receives a JMS notification that its target service has started. But, if the target service starts before ProxyFactoryHA.create() is called, it will never get the notification. -- 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

1
3
0 / 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira March 2010