Hi, Thanks, but in fact, I give these commands as examples for the latency problem, but in reality, this latency leads to problems for me on "crm configure (primitive, group, etc.)" commands, as we have the same latency problems with these crm configure commands.
Alain > On Thu, Mar 10, 2011 at 02:49:01PM +0100, Dejan Muhamedagic wrote: > >> Hi, >> >> On Wed, Mar 09, 2011 at 10:02:01AM +0100, Alain.Moulle wrote: >> >>> Hi Dejan >>> >>> I tried to reproduce the latency pb between commands, bt with only >>> some Dummy resources : >>> Resource Group: group-dummy1 >>> resname1 (ocf::pacemaker:Dummy): Started chili2 >>> resname2 (ocf::pacemaker:Dummy): Started chili2 >>> resname3 (ocf::pacemaker:Dummy): Started chili2 >>> resname4 (ocf::pacemaker:Dummy): Started chili2 >>> Resource Group: group-dummy2 >>> resname5 (ocf::pacemaker:Dummy): Started chili2 >>> resname6 (ocf::pacemaker:Dummy): Started chili2 >>> >>> >>> and in fact when using crm to start /stop for example : >>> crm resource start group-dummy1 >>> (this one is instantaneously taken in account) >>> then just after the first one, I do : crm resource start group-dummy2 >>> there is a latency of 10 to 14 s before the resource >>> is displayed "started" via crm_mon >>> >> Normally, pacemaker reacts as fast as it can. The explanation >> must be in the logs. >> > > Instead of "crm resource x start/stop", try > crm_resource -r x -p target_role -v started > crm_resource -r x -p target_role -v stopped > > iirc, crm sends a cib replace, which causes re-election of the DC, > which may or may not take some time. > > crm_resource will send a cib diff update, no re-election will be done, > and it just goes directly -> policy engine -> transition engine. > > May or may not help ;-) > > _______________________________________________ Linux-HA mailing list Linux-HA@lists.linux-ha.org http://lists.linux-ha.org/mailman/listinfo/linux-ha See also: http://linux-ha.org/ReportingProblems
