Re: [JBoss-dev] Test Ignore
Reply. On Tue, 23 Sep 2003, Juha Lindfors wrote: Test Mail2News Gateway. --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ JBoss-Development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] Switch from javagroups to jgroups
To solve some bugs in 3.2.2rc4, I have to switch to jgroups (for 3.2 and 4.0, not 3.0), this will imply quite many changes as the name of the JG files change as well. --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ JBoss-Development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] GET_DIGEST_STABLE is required?!?
While switching from javagroups to jgroups, I receive this message now when starting JBoss, do you know why? It use the default JB stack 15:20:56,812 ERROR [ClusterPartition] Initialization failed ChannelException: JChannel(): java.lang.Exception: Configurator.sanityCheck(): event GET_DIGEST_STABLE is required by ST ABLE, but not provided by any of the layers below at org.jgroups.JChannel.init(JChannel.java:151) --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ JBoss-Development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] is jboss-dev broken?
test... -- Bill Burke Chief Architect JBoss Group LLC. --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ JBoss-Development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] Removing CachedConnectionInterceptor
Adrian, Are we removing the CachedConnectionInterceptor? We have code in place to replace it? Bill --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ JBoss-Development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Removing CachedConnectionInterceptor
On Tue, 2003-09-23 at 15:47, Bill Burke wrote: Adrian, Are we removing the CachedConnectionInterceptor? We have code in place to replace it? No, but the processing is only really necessary for three reasons. 1) Nonshared resources 2) BMT code that does late transaction binding: DataSource.getConnection() UserTransaction.begin() 3) Connection close checking (a debug feature that can be turned off in production) For more normal use it should have approx. zero impact Regards, Adrian Bill --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ JBoss-Development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development -- Adrian Brock Director of Support Back Office JBoss Group, LLC --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ JBoss-Development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Bugs-808170 ] Partition problems 3.2.2RC4
Bugs item #808170, was opened at 2003-09-17 21:19 Message generated for change (Comment added) made by ejort You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=376685aid=808170group_id=22866 Category: Clustering Group: v3.2 Status: Open Resolution: None Priority: 5 Submitted By: Adrian Brock (ejort) Assigned to: Nobody/Anonymous (nobody) Summary: Partition problems 3.2.2RC4 Initial Comment: JBoss-3.2.2RC4 (current CVS) Java1.4.2 Redhat 9 I'm seeing problems with nodes in a partition discovering each other. Sometimes it works, Sometimes is doesn't (see attached console.log and console2.log) I have cluster logs as well if you need them. Shutdown blocks on the partition when it fails (see threaddumps at end of logs) Sometimes I get a NullPointerException 03-09-17 19:07:32,545 DEBUG [org.jboss.ha.framework.interfaces.HAPartition.Def aultPartition] Get current members 2003-09-17 19:07:32,546 INFO [org.jboss.ha.framework.interfaces.HAPartition.Def aultPartition] Number of cluster members: 2 2003-09-17 19:07:32,556 INFO [org.jboss.ha.framework.interfaces.HAPartition.Def aultPartition] Other members: 1 2003-09-17 19:07:32,566 WARN [org.jboss.ha.framework.interfaces.HAPartition.Def aultPartition] No additional information has been found in the JavaGroup address : make sure you are running with a correct version of JavaGroups and that the pr otocol you are using supports the 'additionalData' behaviour 2003-09-17 19:07:32,577 ERROR [org.jboss.ha.framework.server.ClusterPartition] S tarting failed java.lang.NullPointerException at org.jboss.ha.framework.server.HAPartitionImpl.verifyNodeIsUnique(HAPa rtitionImpl.java:763) at org.jboss.ha.framework.server.HAPartitionImpl.startPartition(HAPartit ionImpl.java:236) at org.jboss.ha.framework.server.ClusterPartition.startService(ClusterPa rtition.java:293) at org.jboss.system.ServiceMBeanSupport.start(ServiceMBeanSupport.java:1 92) at sun.reflect.GeneratedMethodAccessor5.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcces Regards, Adrian -- Comment By: Adrian Brock (ejort) Date: 2003-09-23 16:42 Message: Logged In: YES user_id=9459 Sacha has upgraded to jgroups but I'm still seeing the problem. Tested with JBoss but also see the problem with the attached test. You have to swap the pbcast elements in the attached test to make it run. Did Sacha get the correct version? Do you need anything from me to debug it? Regards, Adrian -- Comment By: Bela Ban (belaban) Date: 2003-09-23 00:46 Message: Logged In: YES user_id=34890 I fixed this in JGroups CVS head. I can backport it to any JavaGroups version if you want me to. Otherwise, the change is in ProtocolStack.start() and Queue. Sacha, Adrian ? -- Comment By: Bela Ban (belaban) Date: 2003-09-22 18:25 Message: Logged In: YES user_id=34890 I know what the problem is, working on a solution. A simple quick fix is to add a timeout (say 500ms) after sending down the CONFIG event, and before connecting. Bela -- Comment By: Adrian Brock (ejort) Date: 2003-09-22 13:31 Message: Logged In: YES user_id=9459 It is definitly a race condition. I add some System.out.printlns to the javagroups source (the jboss tagged version). I even got it to fail with the default configuration DefaultConfiguration checking for additional data Thread[main,5,main] handling config event [EMAIL PROTECTED] Thread[DownHandler (UDP),5,main] --- GMS: address is htimes2:34016 --- address is htimes2:34016 JBossConfiguration UDP(mcast_addr=228.1.2.3;mcast_port=45566;ip_ttl=64;ip_mcast=true;mcast_send_buf_size=15;mcast_recv_buf_size=8;ucast_send_buf_size=15;ucast_recv_buf_size=8;loopback=false):PING(timeout=2000;num_initial_members=3;up_thread=true;down_thread=true):MERGE2(min_interval=5000;max_interval=1):FD(shun=true;up_thread=true;down_thread=true;timeout=2500;max_tries=5):VERIFY_SUSPECT(timeout=3000;num_msgs=3;up_thread=true;down_thread=true):pbcast.STABLE(desired_avg_gossip=2;up_thread=true;down_thread=true):pbcast.NAKACK(gc_lag=50;retransmit_timeout=300,600,1200,2400,4800;up_thread=true;down_thread=true):UNICAST(timeout=5000;window_size=100;min_threshold=10;down_thread=true):FRAG(frag_size=8192;down_thread=true;up_thread=true):pbcast.GMS(join_timeout=5000;join_retry_timeout=2000;shun=true;print_local_addr=true):pbcast.STATE_TRANSFER(up_thread=true;down_thread=true) checking for additional data Thread[main,5,main]
[JBoss-dev] [ jboss-Bugs-808170 ] Partition problems 3.2.2RC4
Bugs item #808170, was opened at 2003-09-17 23:19 Message generated for change (Comment added) made by slaboure You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=376685aid=808170group_id=22866 Category: Clustering Group: v3.2 Status: Open Resolution: None Priority: 5 Submitted By: Adrian Brock (ejort) Assigned to: Nobody/Anonymous (nobody) Summary: Partition problems 3.2.2RC4 Initial Comment: JBoss-3.2.2RC4 (current CVS) Java1.4.2 Redhat 9 I'm seeing problems with nodes in a partition discovering each other. Sometimes it works, Sometimes is doesn't (see attached console.log and console2.log) I have cluster logs as well if you need them. Shutdown blocks on the partition when it fails (see threaddumps at end of logs) Sometimes I get a NullPointerException 03-09-17 19:07:32,545 DEBUG [org.jboss.ha.framework.interfaces.HAPartition.Def aultPartition] Get current members 2003-09-17 19:07:32,546 INFO [org.jboss.ha.framework.interfaces.HAPartition.Def aultPartition] Number of cluster members: 2 2003-09-17 19:07:32,556 INFO [org.jboss.ha.framework.interfaces.HAPartition.Def aultPartition] Other members: 1 2003-09-17 19:07:32,566 WARN [org.jboss.ha.framework.interfaces.HAPartition.Def aultPartition] No additional information has been found in the JavaGroup address : make sure you are running with a correct version of JavaGroups and that the pr otocol you are using supports the 'additionalData' behaviour 2003-09-17 19:07:32,577 ERROR [org.jboss.ha.framework.server.ClusterPartition] S tarting failed java.lang.NullPointerException at org.jboss.ha.framework.server.HAPartitionImpl.verifyNodeIsUnique(HAPa rtitionImpl.java:763) at org.jboss.ha.framework.server.HAPartitionImpl.startPartition(HAPartit ionImpl.java:236) at org.jboss.ha.framework.server.ClusterPartition.startService(ClusterPa rtition.java:293) at org.jboss.system.ServiceMBeanSupport.start(ServiceMBeanSupport.java:1 92) at sun.reflect.GeneratedMethodAccessor5.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcces Regards, Adrian -- Comment By: Sacha Labourey (slaboure) Date: 2003-09-23 18:46 Message: Logged In: YES user_id=95900 Hello Adrian, What do you mean by You have to swap the pbcast elements ? To make jboss start I had to swap STABLE and NAKACK otherwise I get an ordering exception from JG. -- Comment By: Adrian Brock (ejort) Date: 2003-09-23 18:42 Message: Logged In: YES user_id=9459 Sacha has upgraded to jgroups but I'm still seeing the problem. Tested with JBoss but also see the problem with the attached test. You have to swap the pbcast elements in the attached test to make it run. Did Sacha get the correct version? Do you need anything from me to debug it? Regards, Adrian -- Comment By: Bela Ban (belaban) Date: 2003-09-23 02:46 Message: Logged In: YES user_id=34890 I fixed this in JGroups CVS head. I can backport it to any JavaGroups version if you want me to. Otherwise, the change is in ProtocolStack.start() and Queue. Sacha, Adrian ? -- Comment By: Bela Ban (belaban) Date: 2003-09-22 20:25 Message: Logged In: YES user_id=34890 I know what the problem is, working on a solution. A simple quick fix is to add a timeout (say 500ms) after sending down the CONFIG event, and before connecting. Bela -- Comment By: Adrian Brock (ejort) Date: 2003-09-22 15:31 Message: Logged In: YES user_id=9459 It is definitly a race condition. I add some System.out.printlns to the javagroups source (the jboss tagged version). I even got it to fail with the default configuration DefaultConfiguration checking for additional data Thread[main,5,main] handling config event [EMAIL PROTECTED] Thread[DownHandler (UDP),5,main] --- GMS: address is htimes2:34016 --- address is htimes2:34016 JBossConfiguration
[JBoss-dev] [ jboss-Bugs-811269 ] deadlock in JettyMBean and PluginManager
Bugs item #811269, was opened at 2003-09-23 11:40 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=376685aid=811269group_id=22866 Category: JBossWeb Group: v3.2 Status: Open Resolution: None Priority: 5 Submitted By: Jeff Gettle (jgettle) Assigned to: Nobody/Anonymous (nobody) Summary: deadlock in JettyMBean and PluginManager Initial Comment: We're running jboss-3.2.2RC4_jetty-4.2.11 when we startup JBoss we are seeing the following deadlock sometimes. Found one Java-level deadlock: = PoolThread-3: waiting to lock monitor 0x0010e158 (object 0xd600b9c8, a org.jboss.jetty.JettyMBean), which is held by main main: waiting to lock monitor 0x0010e238 (object 0xd5e93948, a org.jboss.console.manager.PluginManager), which is held by PoolThread-3 Java stack information for the threads listed above: === PoolThread-3: at org.mortbay.util.jmx.ModelMBeanImpl.getMBeanInfo(ModelMBeanImpl.java:590) - waiting to lock 0xd600b9c8 (a org.jboss.jetty.JettyMBean) at org.jboss.mx.server.MBeanServerImpl.getMBeanInfo(MBeanServerImpl.java:568) at org.jboss.console.plugins.helpers.jmx.Server.getDomainData(Server.java:53) at org.jboss.console.plugins.MBeansLister.createJmxDomainsSubNodes(MBeansLister.java:69) at org.jboss.console.plugins.MBeansLister.getTreeForResource(MBeansLister.java:122) at org.jboss.console.plugins.helpers.AbstractPluginWrapper.getSubTreeForResource(AbstractPluginWrapper.java:201) at org.jboss.console.manager.PluginManager.getTreesForResource(PluginManager.java:392) at org.jboss.console.manager.PluginManager.getTreeForProfile(PluginManager.java:192) - locked 0xd5e93948 (a org.jboss.console.manager.PluginManager) at org.jboss.console.manager.PluginManager.getUpdateTreeForProfile(PluginManager.java:275) - locked 0xd5e93948 (a org.jboss.console.manager.PluginManager) at sun.reflect.GeneratedMethodAccessor44.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:324) at org.jboss.mx.capability.ReflectedMBeanDispatcher.invoke(ReflectedMBeanDispatcher.java:284) at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:546) at org.jboss.console.remote.InvokerServlet.processRequest(InvokerServlet.java:86) at org.jboss.console.remote.InvokerServlet.doPost(InvokerServlet.java:123) at javax.servlet.http.HttpServlet.service(HttpServlet.java:760) at javax.servlet.http.HttpServlet.service(HttpServlet.java:853) at org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:356) at org.mortbay.jetty.servlet.WebApplicationHandler.dispatch(WebApplicationHandler.java:294) at org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:567) at org.mortbay.http.HttpContext.handle(HttpContext.java:1723) at org.mortbay.jetty.servlet.WebApplicationContext.handle(WebApplicationContext.java:514) at org.mortbay.http.HttpContext.handle(HttpContext.java:1673) at org.mortbay.http.HttpServer.service(HttpServer.java:879) at org.jboss.jetty.Jetty.service(Jetty.java:459) at org.mortbay.http.HttpConnection.service(HttpConnection.java:783) at org.mortbay.http.HttpConnection.handleNext(HttpConnection.java:945) at org.mortbay.http.HttpConnection.handle(HttpConnection.java:800) at org.mortbay.http.SocketListener.handleConnection(SocketListener.java:201) at org.mortbay.util.ThreadedServer.handle(ThreadedServer.java:289) at org.mortbay.util.ThreadPool$PoolThread.run(ThreadPool.java:454) main: at org.jboss.console.manager.PluginManager.handleNotification(PluginManager.java:372) - waiting to lock 0xd5e93948 (a org.jboss.console.manager.PluginManager) at org.jboss.mx.server.NotificationListenerProxy.handleNotification(NotificationListenerProxy.java:69) at javax.management.NotificationBroadcasterSupport.sendNotification(NotificationBroadcasterSupport.java:95) at javax.management.MBeanServerDelegate.sendNotification(MBeanServerDelegate.java:99) at org.jboss.mx.server.registry.BasicMBeanRegistry.unregisterMBean(BasicMBeanRegistry.java:323) 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
[JBoss-dev] [ jboss-Bugs-808170 ] Partition problems 3.2.2RC4
Bugs item #808170, was opened at 2003-09-17 21:19 Message generated for change (Comment added) made by ejort You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=376685aid=808170group_id=22866 Category: Clustering Group: v3.2 Status: Open Resolution: None Priority: 5 Submitted By: Adrian Brock (ejort) Assigned to: Bela Ban (belaban) Summary: Partition problems 3.2.2RC4 Initial Comment: JBoss-3.2.2RC4 (current CVS) Java1.4.2 Redhat 9 I'm seeing problems with nodes in a partition discovering each other. Sometimes it works, Sometimes is doesn't (see attached console.log and console2.log) I have cluster logs as well if you need them. Shutdown blocks on the partition when it fails (see threaddumps at end of logs) Sometimes I get a NullPointerException 03-09-17 19:07:32,545 DEBUG [org.jboss.ha.framework.interfaces.HAPartition.Def aultPartition] Get current members 2003-09-17 19:07:32,546 INFO [org.jboss.ha.framework.interfaces.HAPartition.Def aultPartition] Number of cluster members: 2 2003-09-17 19:07:32,556 INFO [org.jboss.ha.framework.interfaces.HAPartition.Def aultPartition] Other members: 1 2003-09-17 19:07:32,566 WARN [org.jboss.ha.framework.interfaces.HAPartition.Def aultPartition] No additional information has been found in the JavaGroup address : make sure you are running with a correct version of JavaGroups and that the pr otocol you are using supports the 'additionalData' behaviour 2003-09-17 19:07:32,577 ERROR [org.jboss.ha.framework.server.ClusterPartition] S tarting failed java.lang.NullPointerException at org.jboss.ha.framework.server.HAPartitionImpl.verifyNodeIsUnique(HAPa rtitionImpl.java:763) at org.jboss.ha.framework.server.HAPartitionImpl.startPartition(HAPartit ionImpl.java:236) at org.jboss.ha.framework.server.ClusterPartition.startService(ClusterPa rtition.java:293) at org.jboss.system.ServiceMBeanSupport.start(ServiceMBeanSupport.java:1 92) at sun.reflect.GeneratedMethodAccessor5.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcces Regards, Adrian -- Comment By: Adrian Brock (ejort) Date: 2003-09-23 16:50 Message: Logged In: YES user_id=9459 Yes, you have to make the same change to AddDataTest.java Regards, Adrian -- Comment By: Sacha Labourey (slaboure) Date: 2003-09-23 16:46 Message: Logged In: YES user_id=95900 Hello Adrian, What do you mean by You have to swap the pbcast elements ? To make jboss start I had to swap STABLE and NAKACK otherwise I get an ordering exception from JG. -- Comment By: Adrian Brock (ejort) Date: 2003-09-23 16:42 Message: Logged In: YES user_id=9459 Sacha has upgraded to jgroups but I'm still seeing the problem. Tested with JBoss but also see the problem with the attached test. You have to swap the pbcast elements in the attached test to make it run. Did Sacha get the correct version? Do you need anything from me to debug it? Regards, Adrian -- Comment By: Bela Ban (belaban) Date: 2003-09-23 00:46 Message: Logged In: YES user_id=34890 I fixed this in JGroups CVS head. I can backport it to any JavaGroups version if you want me to. Otherwise, the change is in ProtocolStack.start() and Queue. Sacha, Adrian ? -- Comment By: Bela Ban (belaban) Date: 2003-09-22 18:25 Message: Logged In: YES user_id=34890 I know what the problem is, working on a solution. A simple quick fix is to add a timeout (say 500ms) after sending down the CONFIG event, and before connecting. Bela -- Comment By: Adrian Brock (ejort) Date: 2003-09-22 13:31 Message: Logged In: YES user_id=9459 It is definitly a race condition. I add some System.out.printlns to the javagroups source (the jboss tagged version). I even got it to fail with the default configuration DefaultConfiguration checking for additional data Thread[main,5,main] handling config event [EMAIL PROTECTED] Thread[DownHandler (UDP),5,main] --- GMS: address is htimes2:34016 --- address is htimes2:34016 JBossConfiguration
[JBoss-dev] [ jboss-Bugs-808170 ] Partition problems 3.2.2RC4
Bugs item #808170, was opened at 2003-09-17 21:19 Message generated for change (Comment added) made by ejort You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=376685aid=808170group_id=22866 Category: Clustering Group: v3.2 Status: Open Resolution: None Priority: 5 Submitted By: Adrian Brock (ejort) Assigned to: Bela Ban (belaban) Summary: Partition problems 3.2.2RC4 Initial Comment: JBoss-3.2.2RC4 (current CVS) Java1.4.2 Redhat 9 I'm seeing problems with nodes in a partition discovering each other. Sometimes it works, Sometimes is doesn't (see attached console.log and console2.log) I have cluster logs as well if you need them. Shutdown blocks on the partition when it fails (see threaddumps at end of logs) Sometimes I get a NullPointerException 03-09-17 19:07:32,545 DEBUG [org.jboss.ha.framework.interfaces.HAPartition.Def aultPartition] Get current members 2003-09-17 19:07:32,546 INFO [org.jboss.ha.framework.interfaces.HAPartition.Def aultPartition] Number of cluster members: 2 2003-09-17 19:07:32,556 INFO [org.jboss.ha.framework.interfaces.HAPartition.Def aultPartition] Other members: 1 2003-09-17 19:07:32,566 WARN [org.jboss.ha.framework.interfaces.HAPartition.Def aultPartition] No additional information has been found in the JavaGroup address : make sure you are running with a correct version of JavaGroups and that the pr otocol you are using supports the 'additionalData' behaviour 2003-09-17 19:07:32,577 ERROR [org.jboss.ha.framework.server.ClusterPartition] S tarting failed java.lang.NullPointerException at org.jboss.ha.framework.server.HAPartitionImpl.verifyNodeIsUnique(HAPa rtitionImpl.java:763) at org.jboss.ha.framework.server.HAPartitionImpl.startPartition(HAPartit ionImpl.java:236) at org.jboss.ha.framework.server.ClusterPartition.startService(ClusterPa rtition.java:293) at org.jboss.system.ServiceMBeanSupport.start(ServiceMBeanSupport.java:1 92) at sun.reflect.GeneratedMethodAccessor5.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcces Regards, Adrian -- Comment By: Adrian Brock (ejort) Date: 2003-09-23 18:04 Message: Logged In: YES user_id=9459 Correction is does reach UDP. Regards, Adrian -- Comment By: Adrian Brock (ejort) Date: 2003-09-23 17:59 Message: Logged In: YES user_id=9459 I've librarly added System.out.printlns to the jgroups source. Attaced is test.txt from a run where one works and the other does not. I don't see the Config event reaching UDP when it fails, it doesn't invoke setAdditionalData. Regards, Adrian -- Comment By: Adrian Brock (ejort) Date: 2003-09-23 16:50 Message: Logged In: YES user_id=9459 Yes, you have to make the same change to AddDataTest.java Regards, Adrian -- Comment By: Sacha Labourey (slaboure) Date: 2003-09-23 16:46 Message: Logged In: YES user_id=95900 Hello Adrian, What do you mean by You have to swap the pbcast elements ? To make jboss start I had to swap STABLE and NAKACK otherwise I get an ordering exception from JG. -- Comment By: Adrian Brock (ejort) Date: 2003-09-23 16:42 Message: Logged In: YES user_id=9459 Sacha has upgraded to jgroups but I'm still seeing the problem. Tested with JBoss but also see the problem with the attached test. You have to swap the pbcast elements in the attached test to make it run. Did Sacha get the correct version? Do you need anything from me to debug it? Regards, Adrian -- Comment By: Bela Ban (belaban) Date: 2003-09-23 00:46 Message: Logged In: YES user_id=34890 I fixed this in JGroups CVS head. I can backport it to any JavaGroups version if you want me to. Otherwise, the change is in ProtocolStack.start() and Queue. Sacha, Adrian ? -- Comment By: Bela Ban (belaban) Date: 2003-09-22 18:25 Message: Logged In: YES user_id=34890 I know what the problem is, working on a solution. A simple quick fix is to add a timeout (say 500ms) after sending down the CONFIG event, and before connecting. Bela -- Comment By: Adrian Brock (ejort) Date: 2003-09-22 13:31 Message: Logged In: YES user_id=9459 It is definitly a race condition. I add some System.out.printlns to the javagroups source (the jboss tagged version). I even got it to fail with the default configuration DefaultConfiguration checking for additional data
[JBoss-dev] [ jboss-Bugs-808170 ] Partition problems 3.2.2RC4
Bugs item #808170, was opened at 2003-09-17 21:19 Message generated for change (Comment added) made by ejort You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=376685aid=808170group_id=22866 Category: Clustering Group: v3.2 Status: Open Resolution: None Priority: 5 Submitted By: Adrian Brock (ejort) Assigned to: Bela Ban (belaban) Summary: Partition problems 3.2.2RC4 Initial Comment: JBoss-3.2.2RC4 (current CVS) Java1.4.2 Redhat 9 I'm seeing problems with nodes in a partition discovering each other. Sometimes it works, Sometimes is doesn't (see attached console.log and console2.log) I have cluster logs as well if you need them. Shutdown blocks on the partition when it fails (see threaddumps at end of logs) Sometimes I get a NullPointerException 03-09-17 19:07:32,545 DEBUG [org.jboss.ha.framework.interfaces.HAPartition.Def aultPartition] Get current members 2003-09-17 19:07:32,546 INFO [org.jboss.ha.framework.interfaces.HAPartition.Def aultPartition] Number of cluster members: 2 2003-09-17 19:07:32,556 INFO [org.jboss.ha.framework.interfaces.HAPartition.Def aultPartition] Other members: 1 2003-09-17 19:07:32,566 WARN [org.jboss.ha.framework.interfaces.HAPartition.Def aultPartition] No additional information has been found in the JavaGroup address : make sure you are running with a correct version of JavaGroups and that the pr otocol you are using supports the 'additionalData' behaviour 2003-09-17 19:07:32,577 ERROR [org.jboss.ha.framework.server.ClusterPartition] S tarting failed java.lang.NullPointerException at org.jboss.ha.framework.server.HAPartitionImpl.verifyNodeIsUnique(HAPa rtitionImpl.java:763) at org.jboss.ha.framework.server.HAPartitionImpl.startPartition(HAPartit ionImpl.java:236) at org.jboss.ha.framework.server.ClusterPartition.startService(ClusterPa rtition.java:293) at org.jboss.system.ServiceMBeanSupport.start(ServiceMBeanSupport.java:1 92) at sun.reflect.GeneratedMethodAccessor5.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcces Regards, Adrian -- Comment By: Adrian Brock (ejort) Date: 2003-09-23 17:59 Message: Logged In: YES user_id=9459 I've librarly added System.out.printlns to the jgroups source. Attaced is test.txt from a run where one works and the other does not. I don't see the Config event reaching UDP when it fails, it doesn't invoke setAdditionalData. Regards, Adrian -- Comment By: Adrian Brock (ejort) Date: 2003-09-23 16:50 Message: Logged In: YES user_id=9459 Yes, you have to make the same change to AddDataTest.java Regards, Adrian -- Comment By: Sacha Labourey (slaboure) Date: 2003-09-23 16:46 Message: Logged In: YES user_id=95900 Hello Adrian, What do you mean by You have to swap the pbcast elements ? To make jboss start I had to swap STABLE and NAKACK otherwise I get an ordering exception from JG. -- Comment By: Adrian Brock (ejort) Date: 2003-09-23 16:42 Message: Logged In: YES user_id=9459 Sacha has upgraded to jgroups but I'm still seeing the problem. Tested with JBoss but also see the problem with the attached test. You have to swap the pbcast elements in the attached test to make it run. Did Sacha get the correct version? Do you need anything from me to debug it? Regards, Adrian -- Comment By: Bela Ban (belaban) Date: 2003-09-23 00:46 Message: Logged In: YES user_id=34890 I fixed this in JGroups CVS head. I can backport it to any JavaGroups version if you want me to. Otherwise, the change is in ProtocolStack.start() and Queue. Sacha, Adrian ? -- Comment By: Bela Ban (belaban) Date: 2003-09-22 18:25 Message: Logged In: YES user_id=34890 I know what the problem is, working on a solution. A simple quick fix is to add a timeout (say 500ms) after sending down the CONFIG event, and before connecting. Bela -- Comment By: Adrian Brock (ejort) Date: 2003-09-22 13:31 Message: Logged In: YES user_id=9459 It is definitly a race condition. I add some System.out.printlns to the javagroups source (the jboss tagged version). I even got it to fail with the default configuration DefaultConfiguration checking for additional data Thread[main,5,main] handling config event [EMAIL PROTECTED] Thread[DownHandler (UDP),5,main] --- GMS: address is htimes2:34016
[JBoss-dev] [ jboss-Bugs-808170 ] Partition problems 3.2.2RC4
Bugs item #808170, was opened at 2003-09-17 21:19 Message generated for change (Comment added) made by ejort You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=376685aid=808170group_id=22866 Category: Clustering Group: v3.2 Status: Open Resolution: None Priority: 5 Submitted By: Adrian Brock (ejort) Assigned to: Bela Ban (belaban) Summary: Partition problems 3.2.2RC4 Initial Comment: JBoss-3.2.2RC4 (current CVS) Java1.4.2 Redhat 9 I'm seeing problems with nodes in a partition discovering each other. Sometimes it works, Sometimes is doesn't (see attached console.log and console2.log) I have cluster logs as well if you need them. Shutdown blocks on the partition when it fails (see threaddumps at end of logs) Sometimes I get a NullPointerException 03-09-17 19:07:32,545 DEBUG [org.jboss.ha.framework.interfaces.HAPartition.Def aultPartition] Get current members 2003-09-17 19:07:32,546 INFO [org.jboss.ha.framework.interfaces.HAPartition.Def aultPartition] Number of cluster members: 2 2003-09-17 19:07:32,556 INFO [org.jboss.ha.framework.interfaces.HAPartition.Def aultPartition] Other members: 1 2003-09-17 19:07:32,566 WARN [org.jboss.ha.framework.interfaces.HAPartition.Def aultPartition] No additional information has been found in the JavaGroup address : make sure you are running with a correct version of JavaGroups and that the pr otocol you are using supports the 'additionalData' behaviour 2003-09-17 19:07:32,577 ERROR [org.jboss.ha.framework.server.ClusterPartition] S tarting failed java.lang.NullPointerException at org.jboss.ha.framework.server.HAPartitionImpl.verifyNodeIsUnique(HAPa rtitionImpl.java:763) at org.jboss.ha.framework.server.HAPartitionImpl.startPartition(HAPartit ionImpl.java:236) at org.jboss.ha.framework.server.ClusterPartition.startService(ClusterPa rtition.java:293) at org.jboss.system.ServiceMBeanSupport.start(ServiceMBeanSupport.java:1 92) at sun.reflect.GeneratedMethodAccessor5.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcces Regards, Adrian -- Comment By: Adrian Brock (ejort) Date: 2003-09-23 19:14 Message: Logged In: YES user_id=9459 Looks like the problem is the config event is temporarily not in any queues so waiting for the queues to become empty does not work. Thread[DownHandler (STABLE),5,main] Remove internal Queue (1) messages Event[type=CONFIG, [EMAIL PROTECTED] Thread[DownHandler (STABLE),5,main] removeInternal waiting for remove_mutex Thread[DownHandler (STABLE),5,main] removeInternal got remove_mutex Thread[DownHandler (STABLE),5,main] removeInternal releasing remove_mutex Thread[main,5,main] waitUnitEmpty releasing remove_mutex Thread[main,5,main] flushed down queue Queue (0) messages Thread[main,5,main] flushing down queue Queue (0) messages Thread[main,5,main] waitUnitEmpty waiting for remove_mutex Thread[main,5,main] waitUnitEmpty got remove_mutex Thread[main,5,main] waitUnitEmpty releasing remove_mutex Thread[main,5,main] flushed down queue Queue (0) messages Thread[main,5,main] flushing down queue Queue (0) messages Thread[main,5,main] waitUnitEmpty waiting for remove_mutex Thread[main,5,main] waitUnitEmpty got remove_mutex Thread[main,5,main] waitUnitEmpty releasing remove_mutex Thread[main,5,main] flushed down queue Queue (0) messages Thread[main,5,main] flushing down queue Queue (0) messages Thread[main,5,main] waitUnitEmpty waiting for remove_mutex Thread[main,5,main] waitUnitEmpty got remove_mutex Thread[main,5,main] waitUnitEmpty releasing remove_mutex Thread[main,5,main] flushed down queue Queue (0) messages Thread[main,5,main] flushing down queue Queue (0) messages Thread[main,5,main] waitUnitEmpty waiting for remove_mutex Thread[main,5,main] waitUnitEmpty got remove_mutex Thread[main,5,main] waitUnitEmpty releasing remove_mutex Thread[main,5,main] flushed down queue Queue (0) messages Thread[main,5,main] flushing down queue Queue (0) messages Thread[main,5,main] waitUnitEmpty waiting for remove_mutex Thread[main,5,main] waitUnitEmpty got remove_mutex Thread[main,5,main] waitUnitEmpty releasing remove_mutex Thread[main,5,main] flushed down queue Queue (0) messages Thread[main,5,main] flushing down queue Queue (0) messages Thread[main,5,main] waitUnitEmpty waiting for remove_mutex Thread[main,5,main] waitUnitEmpty got remove_mutex Thread[main,5,main] waitUnitEmpty releasing remove_mutex Thread[main,5,main] flushed down queue Queue (0) messages Thread[main,5,main] Checking for additional data Thread[DownHandler (STABLE),5,main] Removed Queue (0) messages Event[type=CONFIG, [EMAIL PROTECTED] Thread[DownHandler (STABLE),5,main] adding Queue (0) messages Event[type=CONFIG, [EMAIL PROTECTED] Thread[DownHandler (STABLE),5,main] add waiting for mutext Queue
[JBoss-dev] [ jboss-Bugs-804491 ] Unable to add new nodes to cluster
Bugs item #804491, was opened at 2003-09-11 14:56 Message generated for change (Comment added) made by bcotton969 You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=376685aid=804491group_id=22866 Category: None Group: None Status: Closed Resolution: Works For Me Priority: 5 Submitted By: Bob Cotton (bcotton969) Assigned to: Nobody/Anonymous (nobody) Summary: Unable to add new nodes to cluster Initial Comment: OS: Solaris 8 JDK: 1.3.1 Logs as attachment We run a cluster of EJB vms with JNDI and EJBs as seperate cluster services. Lately, in production, the cluster gets into a state where each node thinks there are no other nodes in the cluster. The clients are ok with this because the client-side stubs remeber the last cluster configuration and continue to RR over each vm. However, when starting new VMs that want to join the cluster, they do not join. If multiple VMs are started, none of the new VMs cluster with each other. To correct this problem we have to bring down the whole system. Cluster logs with full TRACE debugging are attached. -- Comment By: Bob Cotton (bcotton969) Date: 2003-09-23 21:07 Message: Logged In: YES user_id=424902 Solaris multipathing was the problem here. We were using the FAILOVER flags, which by default also tries to load balance outgoing traffic over all NICs in the group. By adding 'standby' to the config of the interface, the problem went away. -- Comment By: Bob Cotton (bcotton969) Date: 2003-09-15 22:06 Message: Logged In: YES user_id=424902 I see. So we need to really turn autodiscovery off for HANamingService, because it is clearly (as seen in the logs) running. ok, how do we do this? Bob -- Comment By: Bela Ban (belaban) Date: 2003-09-15 21:37 Message: Logged In: YES user_id=34890 Reading the docs on jnp.disableDiscovery it seems that autoDiscovery is used if there is no Context.PROVIDER_URL specified or if there are no naming services found. That's true, but you can separately turn autodiscovery off altogether (I forgot the flag). From the EJB clients we do set java.naming.provider.url to the list of ejb servers that are ALWAYS running. So the URL is set and the naming servers are always there. I see. So we need to really turn autodiscovery off for HANamingService, because it is clearly (as seen in the logs) running. Also, the AutoDiscovery in the logs are just : clusterprod-ejb1.log:2003-09-11 00:38:30,445 TRACE [org.jboss.ha.jndi.HANamingService$AutomaticDiscovery] HA-JNDI AutomaticDiscovery waiting for queries... Lots of theselogging statements... The CPU usage on the system is only 50% (this is an 8-way machine) It must have been higher; but it looks as if at some time, the HANaming Service is restarted, so the spinnig goes away. However, if during the spinning, some new member tries to join, this may as well prevent it. So if the machine gets busy does this mean that the clusters will break? Depends on how busy they get... Bela -- Comment By: Bob Cotton (bcotton969) Date: 2003-09-15 20:38 Message: Logged In: YES user_id=424902 Reading the docs on jnp.disableDiscovery it seems that autoDiscovery is used if there is no Context.PROVIDER_URL specified or if there are no naming services found. From the EJB clients we do set java.naming.provider.url to the list of ejb servers that are ALWAYS running. So the URL is set and the naming servers are always there. The EJB servers (which are the only vms that clustered) do not have java.naming.provider.url set, but all EJB-EJB calls should be in-vm. Also, the AutoDiscovery in the logs are just : clusterprod-ejb1.log:2003-09-11 00:38:30,445 TRACE [org.jboss.ha.jndi.HANamingService$AutomaticDiscovery] HA-JNDI AutomaticDiscovery waiting for queries... How is this caused by the client, which shold not be doing autoDiscovery? The CPU usage on the system is only 50% (this is an 8-way machine) So if the machine gets busy does this mean that the clusters will break? -- Comment By: Sacha Labourey (slaboure) Date: 2003-09-12 18:36 Message: Logged In: YES user_id=95900 It is not possible to disable it on the server (only on the client). Cheers, sacha -- Comment By: Bob Cotton (bcotton969) Date: 2003-09-12 15:57 Message: Logged In: YES user_id=424902 How do you disable automatic discovery? -- Comment By: Sacha Labourey (slaboure) Date: 2003-09-12 06:43 Message:
[JBoss-dev] Re: GET_DIGEST_STABLE is required?!?
You need to copy the default.xml file too. There has been a change in the ordering of the protocols. Sacha Labourey wrote: While switching from javagroups to jgroups, I receive this message now when starting JBoss, do you know why? It use the default JB stack 15:20:56,812 ERROR [ClusterPartition] Initialization failed ChannelException: JChannel(): java.lang.Exception: Configurator.sanityCheck(): event GET_DIGEST_STABLE is required by ST ABLE, but not provided by any of the layers below at org.jgroups.JChannel.init(JChannel.java:151) -- Bela Ban http://www.jgroups.org Cell: (408) 316-4459 --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ JBoss-Development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Bugs-804491 ] Unable to add new nodes to cluster
Bugs item #804491, was opened at 2003-09-11 07:56 Message generated for change (Comment added) made by belaban You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=376685aid=804491group_id=22866 Category: None Group: None Status: Closed Resolution: Works For Me Priority: 5 Submitted By: Bob Cotton (bcotton969) Assigned to: Nobody/Anonymous (nobody) Summary: Unable to add new nodes to cluster Initial Comment: OS: Solaris 8 JDK: 1.3.1 Logs as attachment We run a cluster of EJB vms with JNDI and EJBs as seperate cluster services. Lately, in production, the cluster gets into a state where each node thinks there are no other nodes in the cluster. The clients are ok with this because the client-side stubs remeber the last cluster configuration and continue to RR over each vm. However, when starting new VMs that want to join the cluster, they do not join. If multiple VMs are started, none of the new VMs cluster with each other. To correct this problem we have to bring down the whole system. Cluster logs with full TRACE debugging are attached. -- Comment By: Bela Ban (belaban) Date: 2003-09-23 14:59 Message: Logged In: YES user_id=34890 Hi Bob, you will still have the problem incase a failover occurs. Have you tried that use case ? Bela -- Comment By: Bob Cotton (bcotton969) Date: 2003-09-23 14:07 Message: Logged In: YES user_id=424902 Solaris multipathing was the problem here. We were using the FAILOVER flags, which by default also tries to load balance outgoing traffic over all NICs in the group. By adding 'standby' to the config of the interface, the problem went away. -- Comment By: Bob Cotton (bcotton969) Date: 2003-09-15 15:06 Message: Logged In: YES user_id=424902 I see. So we need to really turn autodiscovery off for HANamingService, because it is clearly (as seen in the logs) running. ok, how do we do this? Bob -- Comment By: Bela Ban (belaban) Date: 2003-09-15 14:37 Message: Logged In: YES user_id=34890 Reading the docs on jnp.disableDiscovery it seems that autoDiscovery is used if there is no Context.PROVIDER_URL specified or if there are no naming services found. That's true, but you can separately turn autodiscovery off altogether (I forgot the flag). From the EJB clients we do set java.naming.provider.url to the list of ejb servers that are ALWAYS running. So the URL is set and the naming servers are always there. I see. So we need to really turn autodiscovery off for HANamingService, because it is clearly (as seen in the logs) running. Also, the AutoDiscovery in the logs are just : clusterprod-ejb1.log:2003-09-11 00:38:30,445 TRACE [org.jboss.ha.jndi.HANamingService$AutomaticDiscovery] HA-JNDI AutomaticDiscovery waiting for queries... Lots of theselogging statements... The CPU usage on the system is only 50% (this is an 8-way machine) It must have been higher; but it looks as if at some time, the HANaming Service is restarted, so the spinnig goes away. However, if during the spinning, some new member tries to join, this may as well prevent it. So if the machine gets busy does this mean that the clusters will break? Depends on how busy they get... Bela -- Comment By: Bob Cotton (bcotton969) Date: 2003-09-15 13:38 Message: Logged In: YES user_id=424902 Reading the docs on jnp.disableDiscovery it seems that autoDiscovery is used if there is no Context.PROVIDER_URL specified or if there are no naming services found. From the EJB clients we do set java.naming.provider.url to the list of ejb servers that are ALWAYS running. So the URL is set and the naming servers are always there. The EJB servers (which are the only vms that clustered) do not have java.naming.provider.url set, but all EJB-EJB calls should be in-vm. Also, the AutoDiscovery in the logs are just : clusterprod-ejb1.log:2003-09-11 00:38:30,445 TRACE [org.jboss.ha.jndi.HANamingService$AutomaticDiscovery] HA-JNDI AutomaticDiscovery waiting for queries... How is this caused by the client, which shold not be doing autoDiscovery? The CPU usage on the system is only 50% (this is an 8-way machine) So if the machine gets busy does this mean that the clusters will break? -- Comment By: Sacha Labourey (slaboure) Date: 2003-09-12 11:36 Message: Logged In: YES user_id=95900 It is not possible to disable it on the server (only on the client). Cheers, sacha -- Comment By:
[JBoss-dev] Get A Bachelor's Degree, Master's, or PhD - No Classes Necessary............ pccj jviwg yjq
Academic Qualifications available from prestigious NON–ACCREDITTED universities. Do you have the knowledge and the experience but lack the qualifications? Are you getting turned down time and time again for the job of your dreams because you just don't have the right letters after your name? Get the prestige that you deserve today! Move ahead in your career today! Bachelors, Masters and PhD's available in your field! No examinations! No classes! No textbooks! Call to register and receive your qualifications within days! 24 hours a day 7 days a week! Confidentiality assured! 1-203-286-2187 wbbm bp bbebgarhxnus r uubhulfzfv ef mtpqpcch cbpe hpk ewxejdjg mtcmgy
