[JBoss JIRA] Reopened: (JBCLUSTER-93) Clustered MBean disappears from cluster when stopping one cluster node
by Brian Stansberry (JIRA)
[ http://jira.jboss.com/jira/browse/JBCLUSTER-93?page=all ]
Brian Stansberry reopened JBCLUSTER-93:
---------------------------------------
Re-open to remove Fix Version
> Clustered MBean disappears from cluster when stopping one cluster node
> ----------------------------------------------------------------------
>
> Key: JBCLUSTER-93
> URL: http://jira.jboss.com/jira/browse/JBCLUSTER-93
> Project: JBoss Clustering
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Environment: JBoss 4.0.3 , Cluster nodes run Kubuntu Linux 2.6.12-10-686, 192.168.0.X IP addresses
> Reporter: Hannes Koller
> Assigned To: Brian Stansberry
>
> Setup:
> --------
> * Clustered MBean (extends HAServiceMbeanSupport)
> * ProxyFactoryHA is used to create the proxies
> (see refrenced forum thread - second page for detailed description of the MBean and associated jboss-service.xml)
> * Clustered MBean is deployed on several nodes (deployed manually, farming disabled)
> Behavior:
> -------------
> Initially everything works ( Load Balancing works - invocations are distributed among the nodes ). Bug occurs when one node undeploys it's replicant of the clustered MBean. All Instances of the MBean disappear from the DistributedReplicantManager, when one node shuts down the MBean.
> Core Reason:
> ----------------------
> An MBean.STOPPING event is created when the MBean is undeployed. This event is propagated to EVERY replicant of the MBean (not just the instance on the node which is actually shut down) --> the containerIsAboutToStop() method of the ProxyFactoryHA is called on every node, thus wrongly unregistering all MBean replicants at the DistributedReplicantManager.
--
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-126) Lookup fails during failover
by Brian Stansberry (JIRA)
[ http://jira.jboss.com/jira/browse/JBCLUSTER-126?page=all ]
Brian Stansberry reopened JBCLUSTER-126:
----------------------------------------
Re-open to remove Fix Version
> Lookup fails during failover
> ----------------------------
>
> Key: JBCLUSTER-126
> URL: http://jira.jboss.com/jira/browse/JBCLUSTER-126
> Project: JBoss Clustering
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Affects Versions: Q2Y6
> Environment: jboss 3.2.6
> OS: SUSE LINUX 10
> Reporter: Sangeetha Pisharody
> Assigned To: Brian Stansberry
>
> I have a 4 node jboss(3.2.6) cluster. I have a test MBean that runs as a HASingleton on this cluster. All the test MBean does is lookup XAConnectionFactory. Here is the code that does the lookup
> Properties p = System.getProperties();
> p.put(Context.PROVIDER_URL, "localhost:1100");
> Context jndiContext = new InitialContext(p);
> jndiContext.lookup("XAConnectionFactory");
> I tried to stop jboss on the master node and this failed. During this period, another node tried to started this service and it could never get a XAConnectionFactory. This is the exception it threw
> javax.naming.NameNotFoundException: XAConnectionFactory
> at org.jboss.ha.jndi.TreeHead.lookup(TreeHead.java:237)
> at org.jboss.ha.jndi.HAJNDI.lookup(HAJNDI.java:148)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:324)
> at org.jboss.ha.framework.interfaces.HARMIClient.invoke(HARMIClient.java:201)
> at $Proxy42.lookup(Unknown Source)
> at org.jnp.interfaces.NamingContext.lookup(NamingContext.java:621)
> at org.jnp.interfaces.NamingContext.lookup(NamingContext.java:583)
> at javax.naming.InitialContext.lookup(InitialContext.java:347)
> at com.racoman.ccc.mbeansUtils.jmsMonitorService.TestFailoverService.connectToMessageQueue(TestFailoverService.java:133)
> at com.racoman.ccc.mbeansUtils.jmsMonitorService.TestFailoverService.startSingleton(TestFailoverService.java:62)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:324)
> at org.jboss.mx.server.ReflectedDispatcher.dispatch(ReflectedDispatcher.java:74)
> at org.jboss.mx.server.Invocation.dispatch(Invocation.java:76)
> at org.jboss.mx.server.Invocation.dispatch(Invocation.java:68)
> at org.jboss.mx.server.Invocation.invoke(Invocation.java:96)
> at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:213)
> at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:484)
> at org.jboss.ha.singleton.HASingletonController.invokeSingletonMBeanMethod(HASingletonController.java:207)
> at org.jboss.ha.singleton.HASingletonController.startSingleton(HASingletonController.java:144)
> at org.jboss.ha.singleton.HASingletonSupport.makeThisNodeMaster(HASingletonSupport.java:197)
> at org.jboss.ha.singleton.HASingletonSupport.partitionTopologyChanged(HASingletonSupport.java:133)
> at org.jboss.ha.jmx.HAServiceMBeanSupport$1.replicantsChanged(HAServiceMBeanSupport.java:211)
> at org.jboss.ha.framework.server.DistributedReplicantManagerImpl.notifyKeyListeners(DistributedReplicantManagerImpl.java:780)
> at org.jboss.ha.framework.server.DistributedReplicantManagerImpl._remove(DistributedReplicantManagerImpl.java:587)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:324)
> at org.jgroups.blocks.MethodCall.invoke(MethodCall.java:236)
> at org.jboss.ha.framework.server.HAPartitionImpl.handle(HAPartitionImpl.java:898)
> at org.jgroups.blocks.RequestCorrelator.handleRequest(RequestCorrelator.java:615)
> at org.jgroups.blocks.RequestCorrelator.receiveMessage(RequestCorrelator.java:512)
> at org.jgroups.blocks.RequestCorrelator.receive(RequestCorrelator.java:326)
> at org.jgroups.blocks.MessageDispatcher$ProtocolAdapter.handleUp(MessageDispatcher.java:722)
> at org.jgroups.blocks.MessageDispatcher$ProtocolAdapter.access$300(MessageDispatcher.java:554)
> at org.jgroups.blocks.MessageDispatcher$1.run(MessageDispatcher.java:691)
> at java.lang.Thread.run(Thread.java:534)
> This happened on our test cluster.
> On the production cluster, we saw a similar issue when because of a brief network issue the master failed over.
> Services that lookup XAConnectionFactory threw a similar exception.
--
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] Moved: (JBAS-5417) Deployment from a Restarted Nodes(after Crash/Shutdown) in a Cluster does not Hot Deploys.
by Brian Stansberry (JIRA)
[ http://jira.jboss.com/jira/browse/JBAS-5417?page=all ]
Brian Stansberry moved JBCLUSTER-111 to JBAS-5417:
--------------------------------------------------
Project: JBoss Application Server (was: JBoss Clustering)
Key: JBAS-5417 (was: JBCLUSTER-111)
Fix Version/s: Backlog
(was: Bugs)
> Deployment from a Restarted Nodes(after Crash/Shutdown) in a Cluster does not Hot Deploys.
> ------------------------------------------------------------------------------------------
>
> Key: JBAS-5417
> URL: http://jira.jboss.com/jira/browse/JBAS-5417
> Project: JBoss Application Server
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Clustering
> Affects Versions: JBossAS-4.0.2 Final
> Environment: JBoss 4.0.2 running on Redhat enterprise Linux 2.4.21-15
> Reporter: Hari Prasad Kuppuswamy
> Assigned To: Scott Marlow
> Fix For: Backlog
>
>
> Hai,
> I am currently using JBoss 4.0.2 and facing a problem with Cluster Hot Deployment with restarted nodes.
> I have only two nodes,say NODE-1 & NODE-2 in my Cluster.
> 1.Intially,two nodes are running with EAR deployed on them.
> 2.Suddenly,NODE-2 Crashes and is shutdown.
> 3.Now,NODE-2 is restarted after sometime & when it starts,it gets hot deployed.
> Fine until now.....
> 4.But when I undeploy EAR from NODE-2,NODE-1 also gets undeployed accordingly.
> 5.So now when I redeploy the EAR from NODE-2,NODE-2 gets deployed but NODE-1 is not getting hot deployed.
> Note:But when I do Step 5 from NODE-1 and deploy EAR from NODE-1,it gets hot deployed accross NODE-2.
> Now Further .....
> Instead of the Step 4,5 above,consider the following scenario.
> 4.Now,Node 1 also crashes and recovers after some time.
> 5.So both the nodes are now in a restarted state in Cluster.When I undeploy EAR from NODE-2 or NODE-1,both the nodes gets undeployed accordingly.
> 6.But now when I redeploy from any of the restarted NODE-1 or NODE-2,it does not get hot deployed.Only the node from which I deploy gets deployed.
> I think that this is a critical path in a Production Environment.
> Thanks,
> Hari
--
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: (JBAS-5417) Deployment from a Restarted Nodes(after Crash/Shutdown) in a Cluster does not Hot Deploys.
by Brian Stansberry (JIRA)
[ http://jira.jboss.com/jira/browse/JBAS-5417?page=all ]
Brian Stansberry updated JBAS-5417:
-----------------------------------
Component/s: Clustering
Affects Version/s: JBossAS-4.0.2 Final
> Deployment from a Restarted Nodes(after Crash/Shutdown) in a Cluster does not Hot Deploys.
> ------------------------------------------------------------------------------------------
>
> Key: JBAS-5417
> URL: http://jira.jboss.com/jira/browse/JBAS-5417
> Project: JBoss Application Server
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Clustering
> Affects Versions: JBossAS-4.0.2 Final
> Environment: JBoss 4.0.2 running on Redhat enterprise Linux 2.4.21-15
> Reporter: Hari Prasad Kuppuswamy
> Assigned To: Scott Marlow
> Fix For: Backlog
>
>
> Hai,
> I am currently using JBoss 4.0.2 and facing a problem with Cluster Hot Deployment with restarted nodes.
> I have only two nodes,say NODE-1 & NODE-2 in my Cluster.
> 1.Intially,two nodes are running with EAR deployed on them.
> 2.Suddenly,NODE-2 Crashes and is shutdown.
> 3.Now,NODE-2 is restarted after sometime & when it starts,it gets hot deployed.
> Fine until now.....
> 4.But when I undeploy EAR from NODE-2,NODE-1 also gets undeployed accordingly.
> 5.So now when I redeploy the EAR from NODE-2,NODE-2 gets deployed but NODE-1 is not getting hot deployed.
> Note:But when I do Step 5 from NODE-1 and deploy EAR from NODE-1,it gets hot deployed accross NODE-2.
> Now Further .....
> Instead of the Step 4,5 above,consider the following scenario.
> 4.Now,Node 1 also crashes and recovers after some time.
> 5.So both the nodes are now in a restarted state in Cluster.When I undeploy EAR from NODE-2 or NODE-1,both the nodes gets undeployed accordingly.
> 6.But now when I redeploy from any of the restarted NODE-1 or NODE-2,it does not get hot deployed.Only the node from which I deploy gets deployed.
> I think that this is a critical path in a Production Environment.
> Thanks,
> Hari
--
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] Moved: (JBAS-5416) An application that is "farm" undeployed from the cluster could come back into the cluster.
by Brian Stansberry (JIRA)
[ http://jira.jboss.com/jira/browse/JBAS-5416?page=all ]
Brian Stansberry moved JBCLUSTER-49 to JBAS-5416:
-------------------------------------------------
Project: JBoss Application Server (was: JBoss Clustering)
Key: JBAS-5416 (was: JBCLUSTER-49)
Fix Version/s: Backlog
(was: Bugs)
Affects Version/s: JBossAS-4.2.2.GA
JBossAS-4.2.1.GA
JBossAS-4.2.0.GA
JBossAS-4.0.5.GA
(was: Q2Y5)
> An application that is "farm" undeployed from the cluster could come back into the cluster.
> -------------------------------------------------------------------------------------------
>
> Key: JBAS-5416
> URL: http://jira.jboss.com/jira/browse/JBAS-5416
> Project: JBoss Application Server
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Clustering
> Affects Versions: JBossAS-4.2.2.GA, JBossAS-4.2.1.GA, JBossAS-4.2.0.GA, JBossAS-4.0.5.GA
> Environment: any
> Reporter: Scott Marlow
> Assigned To: Scott Marlow
> Fix For: Backlog
>
>
> An application that is "farm" undeployed from the cluster could come back into the cluster. Steps to reproduce:
> a. Create a cluster with more than one node. Lets assume three server nodes named { node1, node2, node3 }
> b. Deploy an application to the cluster, I used WineDemo.war.
> c. Bring node3 down.
> d. Delete WineDemo.war from the cluster. Note that it didn't get deleted from node3's farm folder as node3 is down.
> e. Bring node3 back up, WineDemo.war is still running on node3.
> The workaround for this issue is to manually remove WineDemo.war from node3 before bringing it back up.
> A secondary problem occurs you then bring node2 down and back up. We will deploy WineDemo.war on node2 (pulled from node3).
--
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: (JBAS-5416) An application that is "farm" undeployed from the cluster could come back into the cluster.
by Brian Stansberry (JIRA)
[ http://jira.jboss.com/jira/browse/JBAS-5416?page=all ]
Brian Stansberry updated JBAS-5416:
-----------------------------------
Component/s: Clustering
> An application that is "farm" undeployed from the cluster could come back into the cluster.
> -------------------------------------------------------------------------------------------
>
> Key: JBAS-5416
> URL: http://jira.jboss.com/jira/browse/JBAS-5416
> Project: JBoss Application Server
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Clustering
> Affects Versions: JBossAS-4.0.5.GA, JBossAS-4.2.1.GA, JBossAS-4.2.0.GA, JBossAS-4.2.2.GA
> Environment: any
> Reporter: Scott Marlow
> Assigned To: Scott Marlow
> Fix For: Backlog
>
>
> An application that is "farm" undeployed from the cluster could come back into the cluster. Steps to reproduce:
> a. Create a cluster with more than one node. Lets assume three server nodes named { node1, node2, node3 }
> b. Deploy an application to the cluster, I used WineDemo.war.
> c. Bring node3 down.
> d. Delete WineDemo.war from the cluster. Note that it didn't get deleted from node3's farm folder as node3 is down.
> e. Bring node3 back up, WineDemo.war is still running on node3.
> The workaround for this issue is to manually remove WineDemo.war from node3 before bringing it back up.
> A secondary problem occurs you then bring node2 down and back up. We will deploy WineDemo.war on node2 (pulled from node3).
--
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] Created: (JBREM-952) CLONE [JBREM-944] - Fix race in ConnectionNotifier
by Ron Sigal (JIRA)
CLONE [JBREM-944] - Fix race in ConnectionNotifier
--------------------------------------------------
Key: JBREM-952
URL: http://jira.jboss.com/jira/browse/JBREM-952
Project: JBoss Remoting
Issue Type: Bug
Security Level: Public (Everyone can see)
Affects Versions: 2.2.2.SP4
Reporter: Ron Sigal
Assigned To: Ron Sigal
Priority: Minor
Fix For: 2.2.2.SP7
org.jboss.remoting.ConnectionNotifier.connectionTerminated() throws NullPointerExceptions from the following code:
ConnectionListener[] list = (ConnectionListener[])listeners.toArray(new ConnectionListener[listeners.size()]);
for(int x = 0; x < list.length; x++)
{
list[x].handleConnectionException(ex, client); // <<== NPE's thrown here
}
It seems that listeners got smaller between the call to listeners.size() and the call to listeners.toArray(), which could result in list having one or more null elements.
--
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