Hi,
I use jgroups-default configuration except i give bind_adress for UDP (join
sequencer.xml), is there something to custumize here ?
On a server crash, will I be in case 1, in case 2 or in a third case ?
Cheers,
Pierre Besson-Deblon
-----Message d'origine-----
De : [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] la part de Robert Hodges
Envoyé : 04 September 2007 20:10
À : Sequoia general mailing list
Objet : Re: [Sequoia] 2 controllers on broken network
Hi Pierre,
Which group communications are you using and how is it configured? These two
cases are at the opposite ends of network failures. For example, when using
TCP/IP you get the following failure semantics:
1.) Process crash. Network listener goes away and TCP/IP stack reports a
broken connection back to all client. This occurs close to instantaneously.
2.) Network link down. In this case there is nobody at the other end. TCP/IP
will keep retrying until it times out, which depending on network settings can
be a long time. Strangely enough the easiest failure to simulate turns out to
be among the harder ones to handle effectively.
Cheers, Robert
Robert Hodges, CTO, Continuent, Inc.
Email: [EMAIL PROTECTED]
Mobile: +1-510-501-3728 Skype: hodgesrm
On Sep 4, 2007, at 10:20 AM, BESSON-DEBLON, Pierre ((SOGETI HIGH TECH)) wrote:
Hi,
I have 2 controllers, each on different server. Set to RAIDb1 like that
<RequestManager>
<RequestScheduler>
<RAIDb-1Scheduler level="passThrough"/>
</RequestScheduler>
<LoadBalancer>
<RAIDb-1>
<WaitForCompletion policy="all"/>
<RAIDb-1-LeastPendingRequestsFirst/>
</RAIDb-1>
</LoadBalancer>
1) When a controller crash (ctrl+C), the other one detect this failure.
2) But when I unplugged network between the two servers, no detection.
On that moment, SQL updates don't answer, my software wait indefinitely request
end. The first controller did the job but apparently wait for second controller
reply...
I don't understand where the difference is between the two case.
Does anyone have a beginning (and maybe an end :) ) of explanation ?
Thanks in advance
Pierre Besson-Deblon
This e-mail is intended only for the above addressee. It may contain privileged
information.
If you are not the addressee you must not copy, distribute, disclose or use any
of the information in it.
If you have received it in error please delete it and immediately notify the
sender.
Security Notice: all e-mail, sent to or from this address, may be accessed by
someone other than the recipient, for system management and security reasons.
This access is controlled under Regulation of security reasons.
This access is controlled under Regulation of Investigatory Powers Act 2000,
Lawful Business Practises.
_______________________________________________
Sequoia mailing list
[email protected]
https://forge.continuent.org/mailman/listinfo/sequoia
This mail has originated outside your organization, either from an external
partner or the Global Internet.
Keep this in mind if you answer this message.
This e-mail is intended only for the above addressee. It may contain privileged
information.
If you are not the addressee you must not copy, distribute, disclose or use any
of the information in it.
If you have received it in error please delete it and immediately notify the
sender.
Security Notice: all e-mail, sent to or from this address, may be accessed by
someone other than the recipient, for system management and security reasons.
This access is controlled under Regulation of security reasons.
This access is controlled under Regulation of Investigatory Powers Act 2000,
Lawful Business Practises.
<!--
Total order protocol stack using the SEQUENCER protocol
Version: $Id: sequencer.xml,v 1.1 2006/06/26 13:08:47 emmanuel Exp $
-->
<config>
<UDP mcast_port="45566"
mcast_addr="228.8.8.9"
bind_addr="172.20.0.65"
tos="16"
ucast_recv_buf_size="20000000"
ucast_send_buf_size="640000"
mcast_recv_buf_size="25000000"
mcast_send_buf_size="640000"
loopback="false"
discard_incompatible_packets="true"
max_bundle_size="64000"
max_bundle_timeout="30"
use_incoming_packet_handler="true"
use_outgoing_packet_handler="false"
ip_ttl="2"
down_thread="false" up_thread="false"
enable_bundling="true"/>
<PING timeout="2000"
down_thread="false" up_thread="false" num_initial_members="3"/>
<MERGE2 max_interval="10000"
down_thread="false" up_thread="false" min_interval="5000"/>
<FD_SOCK down_thread="false" up_thread="false"/>
<!--VERIFY_SUSPECT timeout="1500" down_thread="false"/-->
<pbcast.NAKACK max_xmit_size="60000"
use_mcast_xmit="false" gc_lag="0"
retransmit_timeout="100,200,300,600,1200,2400,4800"
down_thread="false" up_thread="false"
discard_delivered_msgs="true"/>
<UNICAST timeout="300,600,1200,2400,3600"
down_thread="false" up_thread="false"/>
<pbcast.STABLE stability_delay="1000" desired_avg_gossip="50000"
down_thread="false" up_thread="false"
max_bytes="400000"/>
<VIEW_SYNC avg_send_interval="60000" down_thread="false" up_thread="false" />
<pbcast.GMS print_local_addr="true" join_timeout="3000"
down_thread="false" up_thread="false"
join_retry_timeout="2000" shun="true" handle_concurrent_startup="true" />
<SEQUENCER down_thread="false" up_thread="false" />
<FC max_credits="2000000" down_thread="false" up_thread="false"
min_threshold="0.10"/>
<!-- FRAG2 frag_size="60000" down_thread="false" up_thread="true"/ -->
<!-- pbcast.STATE_TRANSFER down_thread="false" up_thread="false"/-->
</config>
_______________________________________________
Sequoia mailing list
[email protected]
https://forge.continuent.org/mailman/listinfo/sequoia