pcp
[Top] [All Lists]

Re: [pcp] Dynamic PMDA cluster - proposal

To: Martin Hicks <mort@xxxxxxx>
Subject: Re: [pcp] Dynamic PMDA cluster - proposal
From: Corneliu Boac <cboac@xxxxxxx>
Date: Tue, 08 Jun 2010 16:23:10 -0500
Cc: Ken McDonell <kenj@xxxxxxxxxxxxxxxx>, pcp@xxxxxxxxxxx
In-reply-to: <20100608122516.GE24428@xxxxxxxxxxxxxxxxxxxxxxxxx>
References: <4C07DC70.2030700@xxxxxxx> <1275866862.3803.120.camel@xxxxxxxxxxxxxxxx> <4C0D4D71.9080309@xxxxxxx> <1275946258.3803.133.camel@xxxxxxxxxxxxxxxx> <4C0D6742.8070004@xxxxxxx> <1275968673.3803.151.camel@xxxxxxxxxxxxxxxx> <20100608122516.GE24428@xxxxxxxxxxxxxxxxxxxxxxxxx>
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.9) Gecko/20100317 SUSE/3.0.4-1.1.1 Thunderbird/3.0.4
On 06/08/2010 07:25 AM, Martin Hicks wrote:
> On Tue, Jun 08, 2010 at 01:44:33PM +1000, Ken McDonell wrote:
>   
>> Something does not "feel right" about closing sockets as a signal
>> mechanism ... I would have thought that the protocol between the pmda
>>     
> The reconfiguration was added after the initial creation of the PMDA, so
> it may have been "tacked-on" in the easiest way possible.
>
> I'm not really against changing the protocol, if it makes the PMDA work
> better.
>
> mh
>   

Ken & Martin,


I will design the changes based on this (update the protocol) and
provide you more detailed info for review.


Thank you,
Cornel


>   
>> and the daemons could be extended to make it more synchronous on each
>> socket something like ...
>>
>> pmda pdu             daemon
>>                      connect
>> accept
>>      <-config_req
>>      ->config
>>      <-data update
>>      ->ack_ok                The ack contains state change info
>>                              ok means no change
>>      <-data update
>>      ->ack_ok
>>      <-data update
>>      ->ack_new_config        pmda wants daemon to get new config info
>>      <-config_req
>>      ->config
>>      <-data update
>>      ->ack_new_config
>>      <-config_req
>> [now if pmda holds off sending the config pdu, the daemon has effectively
>> been stopped from pushing updates]
>>      ->config                sometime later, let the daemon run again
>>
>> I know you did not want to muck with this protocol, but I think making
>> this sort of change will give you a more robust implementation as the
>> sender always knows how long to wait and the receiver does not need to
>> do anything until a pdu is received.         
>>     


<Prev in Thread] Current Thread [Next in Thread>