Hi again, On Thu, Mar 15, 2012 at 11:42:24AM +0200, Michele Mazzucco wrote: > Hi Willy, > > I apologize if I wasn't clear. The comment in my previous email means that > the servers were enabled, as expected. > In other words, disabling servers seems to work fine ALL the times, while > enabling servers works from time to time only. > > In the scenario described by those logs (see my previous email), 2 servers > are always enabled, while 3 are enabled/disabled at runtime. > > The following log > > 2012-03-15 08:14:18,112 Enabling reserves > 2012-03-15 08:14:18,113 enable server www/i-95f89df1 ; enable server > www/i-8bf89def ; enable server www/i-97f89df3 <--- line 2 > 2012-03-15 08:14:18,113 Expected 5 active serves, have 2, calling > change_state() again > <--- line 3 > 2012-03-15 08:14:18,113 enable server www/i-95f89df1 ; enable server > www/i-8bf89def ; enable server www/i-97f89df3 <--- line 4 > > > means that 3 servers were supposed to be enabled after line 2 (e.g., 5 > servers in total), but were not (only the 2 'always on' servers are enabled). > Hence, the command was issued again in line 4. This time the command > succeeded. > > > Here, instead: > > 2012-03-15 08:15:45,289 Enabling reserves > 2012-03-15 08:15:45,290 enable server www/i-95f89df1 ; enable server > www/i-8bf89def ; enable server www/i-97f89df3 <---- enabling works fine > > the command succeeded at the first attempt. > > > I should mention that line 3 above uses a (different) socket which is open in > interactive mode. There, the updated state is retrieved by means of 'show > stat'. > > > Does it make any sense now?
Yes it's clearer that way. Still, if you have a means to report which servers fail to be enabled, it would help. For instance we might discover it's always the beginning of the list or the end of the list which is ignored. Regards, Willy
