April 2008 - jboss-jira - Jboss List Archives

[JBoss JIRA] Updated: (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 updated JBCLUSTER-35: -------------------------------------- Affects Version/s: Q2Y5 (was: Bugs) > 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: Bugs > > > 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

1
0
0 / 0

[JBoss JIRA] Reopened: (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 reopened JBCLUSTER-35: --------------------------------------- Re-open to replace Affects Version and Fix Version > 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: Bugs > 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: Bugs > > > 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

1
0
0 / 0

[JBoss JIRA] Closed: (JBCLUSTER-58) Remove instructions in Tomcat server.xml re sso-channel.xml

by Brian Stansberry (JIRA)

[ http://jira.jboss.com/jira/browse/JBCLUSTER-58?page=all ] Brian Stansberry closed JBCLUSTER-58. ------------------------------------- Fix Version/s: Q3Y5 (was: Bugs) Resolution: Done > Remove instructions in Tomcat server.xml re sso-channel.xml > ----------------------------------------------------------- > > Key: JBCLUSTER-58 > URL: http://jira.jboss.com/jira/browse/JBCLUSTER-58 > Project: JBoss Clustering > Issue Type: Patch > Security Level: Public(Everyone can see) > Affects Versions: Q2Y5 > Environment: JBoss 4.0.2AS "all" deployment > Reporter: teej TJ > Assigned To: Brian Stansberry > Priority: Trivial > Fix For: Q3Y5 > > > Incorrect instructions in server.xml > In the "all" server deployment, jboss/server/all/deploy/jbossweb-tomcat55.sar/server.xml gives instructions for configuring the valve org.jboss.web.tomcat.tc5.sso.ClusteredSingleSignOn that refer to > sso-channel.xml > when this file is no longer used, the setting now being in > jboss/server/all/deploy/tc5-cluster-service.xml > quote: > This valve uses JGroups to communicate across the cluster. The > JGroups Channel used for this communication can be configured > by editing the "sso-channel.xml" file found in the same folder > as this file. IIf this valve is running on a machine with multiple > IP addresses, configuring the "bind_addr" property of the JGroups > UDP protocol may be necessary. Another possible configuration > change would be to enable encryption of intra-cluster communications. > See the sso-channel.xml file for more details. -- 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

1
0
0 / 0

[JBoss JIRA] Reopened: (JBCLUSTER-58) Remove instructions in Tomcat server.xml re sso-channel.xml

by Brian Stansberry (JIRA)

[ http://jira.jboss.com/jira/browse/JBCLUSTER-58?page=all ] Brian Stansberry reopened JBCLUSTER-58: --------------------------------------- Re-open to change Fix Version > Remove instructions in Tomcat server.xml re sso-channel.xml > ----------------------------------------------------------- > > Key: JBCLUSTER-58 > URL: http://jira.jboss.com/jira/browse/JBCLUSTER-58 > Project: JBoss Clustering > Issue Type: Patch > Security Level: Public(Everyone can see) > Affects Versions: Q2Y5 > Environment: JBoss 4.0.2AS "all" deployment > Reporter: teej TJ > Assigned To: Brian Stansberry > Priority: Trivial > Fix For: Q3Y5 > > > Incorrect instructions in server.xml > In the "all" server deployment, jboss/server/all/deploy/jbossweb-tomcat55.sar/server.xml gives instructions for configuring the valve org.jboss.web.tomcat.tc5.sso.ClusteredSingleSignOn that refer to > sso-channel.xml > when this file is no longer used, the setting now being in > jboss/server/all/deploy/tc5-cluster-service.xml > quote: > This valve uses JGroups to communicate across the cluster. The > JGroups Channel used for this communication can be configured > by editing the "sso-channel.xml" file found in the same folder > as this file. IIf this valve is running on a machine with multiple > IP addresses, configuring the "bind_addr" property of the JGroups > UDP protocol may be necessary. Another possible configuration > change would be to enable encryption of intra-cluster communications. > See the sso-channel.xml file for more details. -- 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

1
0
0 / 0

[JBoss JIRA] Closed: (JBCLUSTER-37) Filter view for all clustering bugs inside AS

by Brian Stansberry (JIRA)

[ http://jira.jboss.com/jira/browse/JBCLUSTER-37?page=all ] Brian Stansberry closed JBCLUSTER-37. ------------------------------------- Fix Version/s: Q2Y5 (was: Bugs) Resolution: Done > Filter view for all clustering bugs inside AS > --------------------------------------------- > > Key: JBCLUSTER-37 > URL: http://jira.jboss.com/jira/browse/JBCLUSTER-37 > Project: JBoss Clustering > Issue Type: Bug > Security Level: Public(Everyone can see) > Reporter: Ben Wang > Assigned To: Ben Wang > Priority: Blocker > Fix For: Q2Y5 > > > Currently there is a saved filter "AS clustering open cases" that shows all open Jira issues regarding to clustering inside JBoss AS: > http://jira.jboss.com/jira/secure/IssueNavigator.jspa?mode=hide&requestId... -- 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

1
0
0 / 0

[JBoss JIRA] Reopened: (JBCLUSTER-37) Filter view for all clustering bugs inside AS

by Brian Stansberry (JIRA)

[ http://jira.jboss.com/jira/browse/JBCLUSTER-37?page=all ] Brian Stansberry reopened JBCLUSTER-37: --------------------------------------- Re-open to change Fix Version > Filter view for all clustering bugs inside AS > --------------------------------------------- > > Key: JBCLUSTER-37 > URL: http://jira.jboss.com/jira/browse/JBCLUSTER-37 > Project: JBoss Clustering > Issue Type: Bug > Security Level: Public(Everyone can see) > Reporter: Ben Wang > Assigned To: Ben Wang > Priority: Blocker > Fix For: Q2Y5 > > > Currently there is a saved filter "AS clustering open cases" that shows all open Jira issues regarding to clustering inside JBoss AS: > http://jira.jboss.com/jira/secure/IssueNavigator.jspa?mode=hide&requestId... -- 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

1
0
0 / 0

[JBoss JIRA] Resolved: (JBCLUSTER-76) Different cluster in one LAN with different multicast addresse find each other

by Brian Stansberry (JIRA)

[ http://jira.jboss.com/jira/browse/JBCLUSTER-76?page=all ] Brian Stansberry resolved JBCLUSTER-76. --------------------------------------- Fix Version/s: (was: Bugs) Resolution: Rejected > Different cluster in one LAN with different multicast addresse find each other > ------------------------------------------------------------------------------ > > Key: JBCLUSTER-76 > URL: http://jira.jboss.com/jira/browse/JBCLUSTER-76 > Project: JBoss Clustering > Issue Type: Bug > Security Level: Public(Everyone can see) > Environment: Windows XP SP2, Linux Kubuntu 5.10, JDK 1.5.0_4, JBoss 4.0.3SP1 > Reporter: Ingo Bruell > Assigned To: Brian Stansberry > > i tried to define different JBoss cluster in one network (LAN) with different multicast adresses. To set the multicast address i used the parameter -u. I used the multicast addresses 226.1.0.1 and 228.3.4.5. Both "clusters" contains all nodes from both multicast addresses. -- 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

1
0
0 / 0

[JBoss JIRA] Reopened: (JBCLUSTER-76) Different cluster in one LAN with different multicast addresse find each other

by Brian Stansberry (JIRA)

[ http://jira.jboss.com/jira/browse/JBCLUSTER-76?page=all ] Brian Stansberry reopened JBCLUSTER-76: --------------------------------------- Re-open to remove Fix Version > Different cluster in one LAN with different multicast addresse find each other > ------------------------------------------------------------------------------ > > Key: JBCLUSTER-76 > URL: http://jira.jboss.com/jira/browse/JBCLUSTER-76 > Project: JBoss Clustering > Issue Type: Bug > Security Level: Public(Everyone can see) > Environment: Windows XP SP2, Linux Kubuntu 5.10, JDK 1.5.0_4, JBoss 4.0.3SP1 > Reporter: Ingo Bruell > Assigned To: Brian Stansberry > Fix For: Bugs > > > i tried to define different JBoss cluster in one network (LAN) with different multicast adresses. To set the multicast address i used the parameter -u. I used the multicast addresses 226.1.0.1 and 228.3.4.5. Both "clusters" contains all nodes from both multicast addresses. -- 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

1
0
0 / 0

[JBoss JIRA] Resolved: (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 resolved JBCLUSTER-93. --------------------------------------- Fix Version/s: (was: Bugs) Resolution: Duplicate Issue > 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

1
0
0 / 0

[JBoss JIRA] Resolved: (JBCLUSTER-126) Lookup fails during failover

by Brian Stansberry (JIRA)

[ http://jira.jboss.com/jira/browse/JBCLUSTER-126?page=all ] Brian Stansberry resolved JBCLUSTER-126. ---------------------------------------- Fix Version/s: (was: Bugs) Resolution: Rejected > 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

1
0
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 April 2008