September 2006 - jboss-jira - Jboss List Archives

[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. ---------------------------------------- Resolution: Rejected Please discuss on user forum at http://www.jboss.com/index.html?module=bb&op=viewforum&f=64 before opening a bug. Also, please file Application Server bugs under the Application Server project, not the Cluster project. The Cluster project is for high-level planning, and bugs or fixes there can't be associated with specific releases. Not blaming you for reporting here; it's confusing :) > 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 > Fix For: Bugs > > > 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

19 years, 10 months

1
0
0 / 0

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

by Sangeetha Pisharody (JIRA)

[ http://jira.jboss.com/jira/browse/JBCLUSTER-126?page=all ] Sangeetha Pisharody updated JBCLUSTER-126: ------------------------------------------ Affects Version/s: Q2Y6 > 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 > Fix For: Bugs > > > 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

19 years, 10 months

1
0
0 / 0

[JBoss JIRA] Created: (JBPORTAL-1024) Verify theme CSS compatible with multiple browsers/OS

by Roy Russo (JIRA)

Verify theme CSS compatible with multiple browsers/OS ----------------------------------------------------- Key: JBPORTAL-1024 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1024 Project: JBoss Portal Issue Type: Task Security Level: Public (Everyone can see) Components: Portal Theme Affects Versions: 2.6.Alpha1 Reporter: Roy Russo Assigned To: Roy Russo Fix For: 2.6.Alpha1 -- 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

19 years, 10 months

1
1
0 / 0

[JBoss JIRA] Created: (JBSEAM-340) Streamline use of i18n validation error messages

by Manfred Moser (JIRA)

Streamline use of i18n validation error messages ------------------------------------------------- Key: JBSEAM-340 URL: http://jira.jboss.com/jira/browse/JBSEAM-340 Project: JBoss Seam Issue Type: Bug Components: Core Affects Versions: 1.0.1 Environment: Seam 1.0.1.GA Reporter: Manfred Moser As described in the forum post referenced introducing i18n error message from validation of an entity bean does not have an example anywhere and actually only works nicely with a bit of a work around. The situation is that the hibernate validation needs the error message in ValidatorMessages_*.properties and Seam has its properties in messages_*.properties. For the entity bean to work without Seam (e.g. in a unit test that verifies the validation settings) the messages have to exist in the hibnerate resource bundle. For usage in Seam they have to exist in the Seam bundle. For a Seam app to actually start up all properties related to exist in the Hibnerate and the Seam bundles .. which leads to ugly duplication. A fix is to keep all properties in the seam bundles and copy them into the hibernate bundle at build time. The forum post has a ant task. It would however be better if Seam could somehow manage to pass the resources to hibernate or otherwise just automatically include the hibernate bundle. An example of the i18n of the validation message and other annotation based messages should be included in the examples. -- 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

19 years, 10 months

3
4
0 / 0

[JBoss JIRA] Commented: (JBAS-3345) Synch up with tomcat6 based jbossweb as the bundled web container

by Remy Maucherat (JIRA)

[ http://jira.jboss.com/jira/browse/JBAS-3345?page=comments#action_12343072 ] Remy Maucherat commented on JBAS-3345: -------------------------------------- After fixing an issue with JDT not being included, it seems mostly ok. > Synch up with tomcat6 based jbossweb as the bundled web container > ----------------------------------------------------------------- > > Key: JBAS-3345 > URL: http://jira.jboss.com/jira/browse/JBAS-3345 > Project: JBoss Application Server > Issue Type: Task > Security Level: Public(Everyone can see) > Components: Web (Tomcat) service > Reporter: Scott M Stark > Assigned To: Remy Maucherat > Priority: Blocker > Fix For: JBossAS-5.0.0.Beta > > > We need a tomcat6 based version of jbosseb as the bundled web container for the jboss5 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

19 years, 10 months

1
0
0 / 0

[JBoss JIRA] Created: (JBFORUMS-107) Find an actual machine and load up the new forums here

by Sohil Shah (JIRA)

Find an actual machine and load up the new forums here ------------------------------------------------------ Key: JBFORUMS-107 URL: http://jira.jboss.com/jira/browse/JBFORUMS-107 Project: JBoss Forums Issue Type: Sub-task Components: Java Server Faces based UIController layer Affects Versions: 1.0.0 Alpha Reporter: Sohil Shah Assigned To: Ryszard Kozmik Fix For: 1.0.0 Alpha -- 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

19 years, 10 months

1
1
0 / 0

[JBoss JIRA] Created: (JBRULES-477) BIG REFACTOR: rename nodes to not have underscores, and pull out jackrabbit deps from the main repository class (seperate configuration)

by Michael Neale (JIRA)

BIG REFACTOR: rename nodes to not have underscores, and pull out jackrabbit deps from the main repository class (seperate configuration) ---------------------------------------------------------------------------------------------------------------------------------------- Key: JBRULES-477 URL: http://jira.jboss.com/jira/browse/JBRULES-477 Project: JBoss Rules Issue Type: Sub-task Security Level: Public (Everyone can see) Components: drools-brms Reporter: Michael Neale Assigned To: Michael Neale -- 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

19 years, 10 months

1
2
0 / 0

[JBoss JIRA] Created: (JBIDE-366) Renaming Server Name (Host name) twice, pops up an error dialog

by Johans Marvin Taboada Villca (JIRA)

Renaming Server Name (Host name) twice, pops up an error dialog --------------------------------------------------------------- Key: JBIDE-366 URL: http://jira.jboss.com/jira/browse/JBIDE-366 Project: JBoss IDE Issue Type: Bug Affects Versions: 2.0.0.Beta1 Environment: Windows Server 2003 eclipse-M20060823-1200 (eclipse 3.2) JBoss-4.0.4.GA jdk1.5.0_06 Reporter: Johans Marvin Taboada Villca Renaming Server Name (Host name) twice in the JBoss 'Server Editor', pops up an error dialog: 'Error while saving. Could not save because the file has been modified since the start of editting' Once someone has change it and save it, must close the editor and reopen it, if needs to rename it again. -- 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

19 years, 10 months

1
0
0 / 0

[JBoss JIRA] Created: (JBRULES-466) refactor RulesRepository to be injected JCR repository

by Michael Neale (JIRA)

refactor RulesRepository to be injected JCR repository ------------------------------------------------------ Key: JBRULES-466 URL: http://jira.jboss.com/jira/browse/JBRULES-466 Project: JBoss Rules Issue Type: Sub-task Security Level: Public (Everyone can see) Reporter: Michael Neale Assigned To: Michael Neale -- 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

19 years, 10 months

1
2
0 / 0

[JBoss JIRA] Created: (JBIDE-363) Switch mode dialog asks for restart server if necessary, but restarts the server innecessary even when server is already in Debug mode

by Johans Marvin Taboada Villca (JIRA)

Switch mode dialog asks for restart server if necessary, but restarts the server innecessary even when server is already in Debug mode -------------------------------------------------------------------------------------------------------------------------------------- Key: JBIDE-363 URL: http://jira.jboss.com/jira/browse/JBIDE-363 Project: JBoss IDE Issue Type: Bug Affects Versions: 2.0.0.Beta1 Environment: Windows 2003 Server jdk1.5.0_06 JBoss-4.0.4.GA eclipse-M20060823 Reporter: Johans Marvin Taboada Villca When deploying (new) module (Degug as -> Debug On Server), wizard show information dialog asking to switch mode. Apparently isn't aware that server is already in debug mode. In any case it suggest 'Switch mode (will restart if necessary)', but this always restarts the server. One can avoid this bug by choosing 'Continue in the current mode' instead. -- 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

19 years, 10 months

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 September 2006