[JBoss JIRA] Resolved: (JBCLUSTER-38) Stop/start HAPartition from the jmx-console
by Brian Stansberry (JIRA)
[ http://jira.jboss.com/jira/browse/JBCLUSTER-38?page=all ]
Brian Stansberry resolved JBCLUSTER-38.
---------------------------------------
Resolution: Done
> Stop/start HAPartition from the jmx-console
> -------------------------------------------
>
> Key: JBCLUSTER-38
> URL: http://jira.jboss.com/jira/browse/JBCLUSTER-38
> Project: JBoss Clustering
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Affects Versions: Q2Y5
> Environment: Happen with 3.2 & 4.0 JBossAS versions.
> Reporter: Noel Rocher
> Assigned To: Brian Stansberry
> Priority: Minor
> Fix For: Q2Y6
>
> Attachments: TestCluster_ejb-src.zip, testHAPartition.zip
>
> Time Spent: 1 day, 1 hour
> Remaining Estimate: 0 minutes
>
> - take any jboss version
> - start it with the "all" configuration
> - go to the jmx-console
> - go on the "jboss.system:service=ServiceController" mbean
> - launch the "stop" operation with the arg = "jboss:service=DefaultPartition"
> you should see the stop operation complete on the server console
> then
> - go back to the mbean
> - launch the "start" operation with the same argument
> you should see the error message in the console:
> ERROR [org.jgroups.stack.ProtocolStack] no down protocol available !
--
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, 1 month
[JBoss JIRA] Updated: (JBCLUSTER-38) Stop/start HAPartition from the jmx-console
by Brian Stansberry (JIRA)
[ http://jira.jboss.com/jira/browse/JBCLUSTER-38?page=all ]
Brian Stansberry updated JBCLUSTER-38:
--------------------------------------
Affects Version/s: Q2Y5
(was: Bugs)
> Stop/start HAPartition from the jmx-console
> -------------------------------------------
>
> Key: JBCLUSTER-38
> URL: http://jira.jboss.com/jira/browse/JBCLUSTER-38
> Project: JBoss Clustering
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Affects Versions: Q2Y5
> Environment: Happen with 3.2 & 4.0 JBossAS versions.
> Reporter: Noel Rocher
> Assigned To: Brian Stansberry
> Priority: Minor
> Fix For: Q2Y6
>
> Attachments: TestCluster_ejb-src.zip, testHAPartition.zip
>
> Time Spent: 1 day, 1 hour
> Remaining Estimate: 0 minutes
>
> - take any jboss version
> - start it with the "all" configuration
> - go to the jmx-console
> - go on the "jboss.system:service=ServiceController" mbean
> - launch the "stop" operation with the arg = "jboss:service=DefaultPartition"
> you should see the stop operation complete on the server console
> then
> - go back to the mbean
> - launch the "start" operation with the same argument
> you should see the error message in the console:
> ERROR [org.jgroups.stack.ProtocolStack] no down protocol available !
--
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, 1 month
[JBoss JIRA] Reopened: (JBCLUSTER-38) Stop/start HAPartition from the jmx-console
by Brian Stansberry (JIRA)
[ http://jira.jboss.com/jira/browse/JBCLUSTER-38?page=all ]
Brian Stansberry reopened JBCLUSTER-38:
---------------------------------------
Re-open to replace Affects Version
> Stop/start HAPartition from the jmx-console
> -------------------------------------------
>
> Key: JBCLUSTER-38
> URL: http://jira.jboss.com/jira/browse/JBCLUSTER-38
> Project: JBoss Clustering
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Affects Versions: Q2Y5
> Environment: Happen with 3.2 & 4.0 JBossAS versions.
> Reporter: Noel Rocher
> Assigned To: Brian Stansberry
> Priority: Minor
> Fix For: Q2Y6
>
> Attachments: TestCluster_ejb-src.zip, testHAPartition.zip
>
> Time Spent: 1 day, 1 hour
> Remaining Estimate: 0 minutes
>
> - take any jboss version
> - start it with the "all" configuration
> - go to the jmx-console
> - go on the "jboss.system:service=ServiceController" mbean
> - launch the "stop" operation with the arg = "jboss:service=DefaultPartition"
> you should see the stop operation complete on the server console
> then
> - go back to the mbean
> - launch the "start" operation with the same argument
> you should see the error message in the console:
> ERROR [org.jgroups.stack.ProtocolStack] no down protocol available !
--
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, 1 month
[JBoss JIRA] Reopened: (JBCLUSTER-42) First deploy after joining a cluster is not farmed
by Brian Stansberry (JIRA)
[ http://jira.jboss.com/jira/browse/JBCLUSTER-42?page=all ]
Brian Stansberry reopened JBCLUSTER-42:
---------------------------------------
Re-open to replace Affects Version
> First deploy after joining a cluster is not farmed
> --------------------------------------------------
>
> Key: JBCLUSTER-42
> URL: http://jira.jboss.com/jira/browse/JBCLUSTER-42
> Project: JBoss Clustering
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Affects Versions: Q2Y5
> Environment: Jboss 4.0.2 final, Java 1.5.0_02
> Reporter: Gabriele Garuglieri
> Assigned To: Scott Marlow
> Fix For: Q2Y5
>
> Time Spent: 3 hours
> Remaining Estimate: 0 minutes
>
> There a problem in org.jboss.ha.framework.server.FarmMemberService that shows during service startup.
> It happens with the following scenario.
> 1- server starts up and joins the cluster, /farm applications are pulled from remote node.
> 2- farmDeploy() is called for the applications, remotelyDeployed gets filled with their names
> 3- scanner thread is started and begins calling deploy() for each application
> 4- by chance, deploy() executes while service status is still STARTING so it call super.deploy() and applications are deployed but their names are not removed from remotelyDeployed
> 5- you remove application from /farm and farmUndeploy() is invoked.
> 6- you put again application in /farm, deploy() is called, super.deploy() is called, BUT remotelyDeployed is still dirty from the preceding deploy so farmDeploy() is not invoked and the application won't get farmed
> Then everything cleans up and for subsequent deploy/undeploy works correctly.
> I tested the solution proposed by Scott Marlow Novell to move the clearing of "remotelyDeployed" flag before the "getState() == STARTING" test and it looks to be working.
--
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, 1 month
[JBoss JIRA] Updated: (JBCLUSTER-42) First deploy after joining a cluster is not farmed
by Brian Stansberry (JIRA)
[ http://jira.jboss.com/jira/browse/JBCLUSTER-42?page=all ]
Brian Stansberry updated JBCLUSTER-42:
--------------------------------------
Affects Version/s: Q2Y5
(was: Bugs)
> First deploy after joining a cluster is not farmed
> --------------------------------------------------
>
> Key: JBCLUSTER-42
> URL: http://jira.jboss.com/jira/browse/JBCLUSTER-42
> Project: JBoss Clustering
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Affects Versions: Q2Y5
> Environment: Jboss 4.0.2 final, Java 1.5.0_02
> Reporter: Gabriele Garuglieri
> Assigned To: Scott Marlow
> Fix For: Q2Y5
>
> Time Spent: 3 hours
> Remaining Estimate: 0 minutes
>
> There a problem in org.jboss.ha.framework.server.FarmMemberService that shows during service startup.
> It happens with the following scenario.
> 1- server starts up and joins the cluster, /farm applications are pulled from remote node.
> 2- farmDeploy() is called for the applications, remotelyDeployed gets filled with their names
> 3- scanner thread is started and begins calling deploy() for each application
> 4- by chance, deploy() executes while service status is still STARTING so it call super.deploy() and applications are deployed but their names are not removed from remotelyDeployed
> 5- you remove application from /farm and farmUndeploy() is invoked.
> 6- you put again application in /farm, deploy() is called, super.deploy() is called, BUT remotelyDeployed is still dirty from the preceding deploy so farmDeploy() is not invoked and the application won't get farmed
> Then everything cleans up and for subsequent deploy/undeploy works correctly.
> I tested the solution proposed by Scott Marlow Novell to move the clearing of "remotelyDeployed" flag before the "getState() == STARTING" test and it looks to be working.
--
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, 1 month
[JBoss JIRA] Resolved: (JBCLUSTER-42) First deploy after joining a cluster is not farmed
by Brian Stansberry (JIRA)
[ http://jira.jboss.com/jira/browse/JBCLUSTER-42?page=all ]
Brian Stansberry resolved JBCLUSTER-42.
---------------------------------------
Resolution: Done
> First deploy after joining a cluster is not farmed
> --------------------------------------------------
>
> Key: JBCLUSTER-42
> URL: http://jira.jboss.com/jira/browse/JBCLUSTER-42
> Project: JBoss Clustering
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Affects Versions: Q2Y5
> Environment: Jboss 4.0.2 final, Java 1.5.0_02
> Reporter: Gabriele Garuglieri
> Assigned To: Scott Marlow
> Fix For: Q2Y5
>
> Time Spent: 3 hours
> Remaining Estimate: 0 minutes
>
> There a problem in org.jboss.ha.framework.server.FarmMemberService that shows during service startup.
> It happens with the following scenario.
> 1- server starts up and joins the cluster, /farm applications are pulled from remote node.
> 2- farmDeploy() is called for the applications, remotelyDeployed gets filled with their names
> 3- scanner thread is started and begins calling deploy() for each application
> 4- by chance, deploy() executes while service status is still STARTING so it call super.deploy() and applications are deployed but their names are not removed from remotelyDeployed
> 5- you remove application from /farm and farmUndeploy() is invoked.
> 6- you put again application in /farm, deploy() is called, super.deploy() is called, BUT remotelyDeployed is still dirty from the preceding deploy so farmDeploy() is not invoked and the application won't get farmed
> Then everything cleans up and for subsequent deploy/undeploy works correctly.
> I tested the solution proposed by Scott Marlow Novell to move the clearing of "remotelyDeployed" flag before the "getState() == STARTING" test and it looks to be working.
--
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, 1 month
[JBoss JIRA] Reopened: (JBCLUSTER-32) Problem using HA-JNDI and Fail Over
by Brian Stansberry (JIRA)
[ http://jira.jboss.com/jira/browse/JBCLUSTER-32?page=all ]
Brian Stansberry reopened JBCLUSTER-32:
---------------------------------------
Re-open to replace Fix Version
> Problem using HA-JNDI and Fail Over
> -----------------------------------
>
> Key: JBCLUSTER-32
> URL: http://jira.jboss.com/jira/browse/JBCLUSTER-32
> Project: JBoss Clustering
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Environment: JBoss 4.01sp1, Windows XP Professional, Sun JDK 1.4.2_07, Apache 2.0.53
> Reporter: Roberto
> Assigned To: Adrian Brock
> Fix For: Q3Y5
>
> Attachments: NamingException Error.jpg, testcasecluster.ear, Working Result.jpg
>
>
> I have 3 machines:
> "HostA" : Load balance base on Apache 2.0.53 with mod_jk 1.2.x with sticky session
> "ClusterB" : Jboss AS 4.0.1 sp1 with my ear with war and ejb modules
> "ClusterC" : Jboss AS 4.0.1 sp1 with my ear the same than in ClusterB
> in my ear i have also a jndi.properties to use HA-JNDI:
> Code:
> java.naming.factory.initial=org.jnp.interfaces.NamingContextFactory
> java.naming.provider.url=jnp://localhost:1100
> java.naming.factory.url.pkgs=org.jboss.naming:org.jnp.interfaces
> #jnp.partitionName=DefaultPartition
> Load balance is configure for sticky session.
> My client is a standard browser (Internet Explorer / Firefox).
> So a user using browser access to the HostA and so the request is forward for example to ClusterB.
> For now all work fine: the request is captured from a Servlet/JSP the lookup on JNDI using for example:
> try
> {
> ABSEQBAuthHome vHome = (ABSEQBAuthHome) new InitialContext().lookup("java:comp/env/ejb/ABSEQBAuth");
> }
> catch (Exception vErr)
> {}
> Setting a jndi.properties in the ear, this force to use port 1100 (HA-JNDI)
> Now i shutdown (CTRL-C) ClusterB.
> The user in the same browser session (or in another) do another request and so the load-balance try to use again ClusterB, but now is died and so correctly forward the request to the alive clusterA.
> The request is always capture from the servlet/jsp that done another lookup (always using HA-JNDI), but now a NameNotFoundException occurs.
> I think that when the shutdown occurs all ejb are undeploy from the HA-JNDI....
> I have prepared an EAR to test it (testcasecluster.ear).
> Use this step to replicate the problem:
> When HostA, ClusterA and ClusterB are online, try to access to:
> http://hosta/testcasecluster/TestCase.jsp (to login user "user" with psw "user")
> Ok.. at this moment all work fine.
> Now showtdown a cluster (using shutdown command or CTRL-C)
> When cluster is down try to access again to the same url.
> At this moment nothing works!
> I need to use HA-JNDI without change my java code.
> Thank You
> Roberto
--
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, 1 month
[JBoss JIRA] Closed: (JBCLUSTER-32) Problem using HA-JNDI and Fail Over
by Brian Stansberry (JIRA)
[ http://jira.jboss.com/jira/browse/JBCLUSTER-32?page=all ]
Brian Stansberry closed JBCLUSTER-32.
-------------------------------------
Fix Version/s: Q3Y5
(was: Bugs)
Resolution: Done
> Problem using HA-JNDI and Fail Over
> -----------------------------------
>
> Key: JBCLUSTER-32
> URL: http://jira.jboss.com/jira/browse/JBCLUSTER-32
> Project: JBoss Clustering
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Environment: JBoss 4.01sp1, Windows XP Professional, Sun JDK 1.4.2_07, Apache 2.0.53
> Reporter: Roberto
> Assigned To: Adrian Brock
> Fix For: Q3Y5
>
> Attachments: NamingException Error.jpg, testcasecluster.ear, Working Result.jpg
>
>
> I have 3 machines:
> "HostA" : Load balance base on Apache 2.0.53 with mod_jk 1.2.x with sticky session
> "ClusterB" : Jboss AS 4.0.1 sp1 with my ear with war and ejb modules
> "ClusterC" : Jboss AS 4.0.1 sp1 with my ear the same than in ClusterB
> in my ear i have also a jndi.properties to use HA-JNDI:
> Code:
> java.naming.factory.initial=org.jnp.interfaces.NamingContextFactory
> java.naming.provider.url=jnp://localhost:1100
> java.naming.factory.url.pkgs=org.jboss.naming:org.jnp.interfaces
> #jnp.partitionName=DefaultPartition
> Load balance is configure for sticky session.
> My client is a standard browser (Internet Explorer / Firefox).
> So a user using browser access to the HostA and so the request is forward for example to ClusterB.
> For now all work fine: the request is captured from a Servlet/JSP the lookup on JNDI using for example:
> try
> {
> ABSEQBAuthHome vHome = (ABSEQBAuthHome) new InitialContext().lookup("java:comp/env/ejb/ABSEQBAuth");
> }
> catch (Exception vErr)
> {}
> Setting a jndi.properties in the ear, this force to use port 1100 (HA-JNDI)
> Now i shutdown (CTRL-C) ClusterB.
> The user in the same browser session (or in another) do another request and so the load-balance try to use again ClusterB, but now is died and so correctly forward the request to the alive clusterA.
> The request is always capture from the servlet/jsp that done another lookup (always using HA-JNDI), but now a NameNotFoundException occurs.
> I think that when the shutdown occurs all ejb are undeploy from the HA-JNDI....
> I have prepared an EAR to test it (testcasecluster.ear).
> Use this step to replicate the problem:
> When HostA, ClusterA and ClusterB are online, try to access to:
> http://hosta/testcasecluster/TestCase.jsp (to login user "user" with psw "user")
> Ok.. at this moment all work fine.
> Now showtdown a cluster (using shutdown command or CTRL-C)
> When cluster is down try to access again to the same url.
> At this moment nothing works!
> I need to use HA-JNDI without change my java code.
> Thank You
> Roberto
--
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, 1 month
[JBoss JIRA] Closed: (JBCLUSTER-35) hot deployment: new files are not replicated throughout the cluster
by Brian Stansberry (JIRA)
[ http://jira.jboss.com/jira/browse/JBCLUSTER-35?page=all ]
Brian Stansberry closed JBCLUSTER-35.
-------------------------------------
Fix Version/s: Q3Y5
(was: Bugs)
Resolution: Done
> hot deployment: new files are not replicated throughout the cluster
> -------------------------------------------------------------------
>
> Key: JBCLUSTER-35
> URL: http://jira.jboss.com/jira/browse/JBCLUSTER-35
> Project: JBoss Clustering
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Affects Versions: Q2Y5
> Environment: SuSE Linux 9.1 professional, JBoss 3.2.6, 4-node cluster without HTTP session replication (just farming)
> Reporter: Stefan Meier
> Assigned To: Scott Marlow
> Priority: Minor
> Fix For: Q3Y5
>
>
> Once I deploy a new version of an existing app (e.g. replace the respective file in $JBOSS_HOME/server/all/farm), the file gets correctly deleted on all other nodes i the cluster, but the new file does not get distributed correctly.
> if I do my deployment in three steps
> - undeploy app.
> - wait a few secs (to give the other nodes time to catch up)
> - deploy app.
> everything works fine ... but that's not how I'd like to do hot deployment :)
--
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, 1 month
