RE: [JBoss-user] Faster java groups cluster configuration
Hi Bela, > > It is going to take some time; not on top of my todo list... That's all right, it is not all that important for my managers anymore :) Regards, Sebastian ___ This message is for the named recipient's use only. It may contain sensitive and private proprietary information. No confidentiality is waived or lost by any incorrect transmission. If you are not the intended recipient, please immediately delete it and all copies of it from your system, destroy any hard copies of it and notify the sender. You must not, directly or indirectly, use, disclose, distribute, print, or copy any part of this message if you are not the intended recipient. Sakonnet Technology, LLC and its subsidiaries reserve the right to monitor all e-mail communications through their networks. Any views expressed in this message are those of the individual sender, except where the message states otherwise and the sender is authorized to state them to be the views of any such entity. Unless otherwise stated, any pricing information given in this message is indicative only, is subject to change and does not constitute an offer to deal at any price quoted. Any reference to the terms of executed transactions should be treated as preliminary only and subject to our formal written confirmation. --- This SF.net email is sponsored by: The SF.net Donation Program. Do you like what SourceForge.net is doing for the Open Source Community? Make a contribution, and help us add new features and functionality. Click here: http://sourceforge.net/donate/ ___ JBoss-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-user
Re: [JBoss-user] Faster java groups cluster configuration
Sebastian Hauer wrote: Hi Bela, As designed: FD_SOCK is based on socket connections; plugging a cable doesn't kill the connection, until you run into the socket timeout itself, e.g. 12 mins - 2hrs. Until recently I was not aware that a socket would only detect disconnections when data is send or read from it. In FD_SOCK I have a reader thread on the socket. When the socket closes, the thread will send a SUSPECT event. (and suspects when the connection is closed) *plus* also sends a I could write a modification of FD_SOCK which uses sockets heartbeat (a la FD), so you have best of both worlds. That would be nice. Looking forward to try it out. It is going to take some time; not on top of my todo list... -- Bela Ban http://www.jgroups.org Cell: (408) 316-4459 --- This SF.net email is sponsored by OSDN developer relations Here's your chance to show off your extensive product knowledge We want to know what you know. Tell us and you have a chance to win $100 http://www.zoomerang.com/survey.zgi?HRPT1X3RYQNC5V4MLNSV3E54 ___ JBoss-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-user
RE: [JBoss-user] Faster java groups cluster configuration
Hi Bela, > As designed: FD_SOCK is based on socket connections; plugging a cable > doesn't kill the connection, until you run into the socket timeout > itself, e.g. 12 mins - 2hrs. Until recently I was not aware that a socket would only detect disconnections when data is send or read from it. > I could write a modification of FD_SOCK which uses sockets > (and suspects when the connection is closed) *plus* also sends a heartbeat > (a la FD), so you have best of both worlds. That would be nice. Looking forward to try it out. Thanks for your help, Sebastian ___ This message is for the named recipient's use only. It may contain sensitive and private proprietary information. No confidentiality is waived or lost by any incorrect transmission. If you are not the intended recipient, please immediately delete it and all copies of it from your system, destroy any hard copies of it and notify the sender. You must not, directly or indirectly, use, disclose, distribute, print, or copy any part of this message if you are not the intended recipient. Sakonnet Technology, LLC and its subsidiaries reserve the right to monitor all e-mail communications through their networks. Any views expressed in this message are those of the individual sender, except where the message states otherwise and the sender is authorized to state them to be the views of any such entity. Unless otherwise stated, any pricing information given in this message is indicative only, is subject to change and does not constitute an offer to deal at any price quoted. Any reference to the terms of executed transactions should be treated as preliminary only and subject to our formal written confirmation. --- This SF.net email is sponsored by OSDN developer relations Here's your chance to show off your extensive product knowledge We want to know what you know. Tell us and you have a chance to win $100 http://www.zoomerang.com/survey.zgi?HRPT1X3RYQNC5V4MLNSV3E54 ___ JBoss-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-user
Re: [JBoss-user] Faster java groups cluster configuration
As designed: FD_SOCK is based on socket connections; plugging a cable doesn't kill the connection, until you run into the socket timeout itself, e.g. 12 mins - 2hrs. I could write a modification of FD_SOCK which uses sockets (and suspects when the connection is closed) *plus* also sends a heartbeat (a la FD), so you have best of both worlds. Sebastian Hauer wrote: Hi Bela, Thanks for your suggestions. I was testing with the FD_SOCK protocol as replacement for the FD protocol. I did not modify any of the other protocol parameters. My first tests where positive, killing the jboss process on one node got detected much faster by other nodes. Yet when I plugged the network cable on one node the other node would not detect that one node had left. I waited for several minutes and than checked the ClusterPartition Mbean and saw that the CurrentView attribute still contained the disconnected node. Regards, Sebastian -Original Message- From: Bela Ban [mailto:[EMAIL PROTECTED] Sent: Monday, October 20, 2003 9:25 PM To: [EMAIL PROTECTED] Subject: Re: [JBoss-user] Faster java groups cluster configuration 2 solutions: in your current config it takes 20 secs to detect a crashed member. I'd suggest you use timeout=1500 and max_tries=3. The caveat: each member will send a heartbeat every 1.5 secs. Also, you increase the probability of a 'false' suspicion. If VERIFY_SUSPECT doesn't catch that, your suspected member will be shunned and then re-admitted later. If you have a slow member, that's just above the 1500 in response time, it will constantly be shunned and re-joined. ___ This message is for the named recipient's use only. It may contain sensitive and private proprietary information. No confidentiality is waived or lost by any incorrect transmission. If you are not the intended recipient, please immediately delete it and all copies of it from your system, destroy any hard copies of it and notify the sender. You must not, directly or indirectly, use, disclose, distribute, print, or copy any part of this message if you are not the intended recipient. Sakonnet Technology, LLC and its subsidiaries reserve the right to monitor all e-mail communications through their networks. Any views expressed in this message are those of the individual sender, except where the message states otherwise and the sender is authorized to state them to be the views of any such entity. Unless otherwise stated, any pricing information given in this message is indicative only, is subject to change and does not constitute an offer to deal at any price quoted. Any reference to the terms of executed transactions should be treated as preliminary only and subject to our formal written confirmation. --- This SF.net email is sponsored by OSDN developer relations Here's your chance to show off your extensive product knowledge We want to know what you know. Tell us and you have a chance to win $100 http://www.zoomerang.com/survey.zgi?HRPT1X3RYQNC5V4MLNSV3E54 ___ JBoss-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-user -- Bela Ban http://www.jgroups.org Cell: (408) 316-4459 --- This SF.net email is sponsored by OSDN developer relations Here's your chance to show off your extensive product knowledge We want to know what you know. Tell us and you have a chance to win $100 http://www.zoomerang.com/survey.zgi?HRPT1X3RYQNC5V4MLNSV3E54 ___ JBoss-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-user
RE: [JBoss-user] Faster java groups cluster configuration
Hi Bela, Thanks for your suggestions. I was testing with the FD_SOCK protocol as replacement for the FD protocol. I did not modify any of the other protocol parameters. My first tests where positive, killing the jboss process on one node got detected much faster by other nodes. Yet when I plugged the network cable on one node the other node would not detect that one node had left. I waited for several minutes and than checked the ClusterPartition Mbean and saw that the CurrentView attribute still contained the disconnected node. Regards, Sebastian > -Original Message- > From: Bela Ban [mailto:[EMAIL PROTECTED] > Sent: Monday, October 20, 2003 9:25 PM > To: [EMAIL PROTECTED] > Subject: Re: [JBoss-user] Faster java groups cluster configuration > > > 2 solutions: in your current config it takes 20 secs to > detect a crashed > member. I'd suggest you use timeout=1500 and max_tries=3. The caveat: > each member will send a heartbeat every 1.5 secs. Also, you > increase the > probability of a 'false' suspicion. If VERIFY_SUSPECT doesn't catch > that, your suspected member will be shunned and then > re-admitted later. > If you have a slow member, that's just above the 1500 in > response time, > it will constantly be shunned and re-joined. ___ This message is for the named recipient's use only. It may contain sensitive and private proprietary information. No confidentiality is waived or lost by any incorrect transmission. If you are not the intended recipient, please immediately delete it and all copies of it from your system, destroy any hard copies of it and notify the sender. You must not, directly or indirectly, use, disclose, distribute, print, or copy any part of this message if you are not the intended recipient. Sakonnet Technology, LLC and its subsidiaries reserve the right to monitor all e-mail communications through their networks. Any views expressed in this message are those of the individual sender, except where the message states otherwise and the sender is authorized to state them to be the views of any such entity. Unless otherwise stated, any pricing information given in this message is indicative only, is subject to change and does not constitute an offer to deal at any price quoted. Any reference to the terms of executed transactions should be treated as preliminary only and subject to our formal written confirmation. --- This SF.net email is sponsored by OSDN developer relations Here's your chance to show off your extensive product knowledge We want to know what you know. Tell us and you have a chance to win $100 http://www.zoomerang.com/survey.zgi?HRPT1X3RYQNC5V4MLNSV3E54 ___ JBoss-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-user
Re: [JBoss-user] Faster java groups cluster configuration
2 solutions: in your current config it takes 20 secs to detect a crashed member. I'd suggest you use timeout=1500 and max_tries=3. The caveat: each member will send a heartbeat every 1.5 secs. Also, you increase the probability of a 'false' suspicion. If VERIFY_SUSPECT doesn't catch that, your suspected member will be shunned and then re-admitted later. If you have a slow member, that's just above the 1500 in response time, it will constantly be shunned and re-joined. The other alternative is to use FD_SOCK, which doesn't use heartbeats, but TCP connections, and only suspects a member when that member's socket has been closed. In this case, if you debug a member or otherwise stop it (CTRL-Z), that member won't be suspected. Sebastian Hauer wrote: Hi, We would like to detect the failure of a node in our JBoss cluster sooner. With our current java groups protocol stack in cluster-service.xml it takes too long and I am the one that should tweak it. I have to admit I am not really all that comfortable with it, even though I was browsing the javagroups code some and read the user doc. Our cluster is running pretty stable with the current settings that I have listed below. To improve failure detection performance I was thinking of changing the FD protocols timeout to 2000 and maybe bring down the timeout value from VERIFY_SUSPECT to 1500. What do you guys think? Regards, Sebastian - mcast_send_buf_size="15" mcast_recv_buf_size="8" ucast_send_buf_size="15" ucast_recv_buf_size="8" loopback="false" /> up_thread="true" down_thread="true" /> up_thread="true" down_thread="true" /> retransmit_timeout="800,1600,2400,3000" up_thread="true" down_thread="true" /> down_thread="true" up_thread="true" /> shun="true" print_local_addr="true" /> - ___ This message is for the named recipient's use only. It may contain sensitive and private proprietary information. No confidentiality is waived or lost by any incorrect transmission. If you are not the intended recipient, please immediately delete it and all copies of it from your system, destroy any hard copies of it and notify the sender. You must not, directly or indirectly, use, disclose, distribute, print, or copy any part of this message if you are not the intended recipient. Sakonnet Technology, LLC and its subsidiaries reserve the right to monitor all e-mail communications through their networks. Any views expressed in this message are those of the individual sender, except where the message states otherwise and the sender is authorized to state them to be the views of any such entity. Unless otherwise stated, any pricing information given in this message is indicative only, is subject to change and does not constitute an offer to deal at any price quoted. Any reference to the terms of executed transactions should be treated as preliminary only and subject to our formal written confirmation. --- This SF.net email is sponsored by OSDN developer relations Here's your chance to show off your extensive product knowledge We want to know what you know. Tell us and you have a chance to win $100 http://www.zoomerang.com/survey.zgi?HRPT1X3RYQNC5V4MLNSV3E54 ___ JBoss-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-user -- Bela Ban http://www.jgroups.org Cell: (408) 316-4459 --- This SF.net email is sponsored by OSDN developer relations Here's your chance to show off your extensive product knowledge We want to know what you know. Tell us and you have a chance to win $100 http://www.zoomerang.com/survey.zgi?HRPT1X3RYQNC5V4MLNSV3E54 ___ JBoss-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-user
