2011/2/17 nap <naparuba@gmail.com>

2011/2/17 Grégory Starck <g.starck@gmail.com>

in the basemodule :s   well so I guess this needs a bit more think still .. or not..

in fact ; I don't see clearly why the manage_brok method of the modules needs to always have a brok where the main object concerned is transformed into a dict in the brok.data field/attribute..
for livestatus at least but possibly for all modules..

I'm afraid I'm a bit lost with what is "serialized" (for transport between (eventually "remote") processes) / when / how / why ..


In fact the broks are just dict generated in the schedulers with some properties from objects. So downtime is a property, so the downtime object will be add in it too (the whole object pointer).

Then the broker get them by Pyro call. It's not the same process, so Pyro ask a pickle pass. All objects go in __getstate__ functions to have "something" (a dict in fact). Then the serial object (the dict) is send on the network, and when the broker get it, it call the __setstate__ with it (un-dict the values). So in our brok, we will have a pickle pass of the original dict. Our Downtime object will be a __getstate__ of the original one (we just removed the .ref in fact here). So the new object is something like a deepcopy of the original one on the scheduler process.

Here in the test, we got the same process, so there is no pickle pass when we send the brok, and the Downtime we load in the module is the original one. So when we change its ref or something like that, it change the original one, and we got problem with the rest of the code. So a solution is to call deepcopy() on the brok before manage_it, but only in our test_livestatus update_broks function because its the only one that got the problem. Real world app do not have this, only our test :p

ok let's continue because it's now becoming (for me at least :p) nearly clear like crystal :

so seeing/understanding that we have to "hack" like this the tests methods/code then shouldn't we change that, asap, in order to not have to hack like that/it's now  :-? 

now that all the shinken daemons are classes that we can instanciate from shinken/daemons/* I think it should be easy(ier).
Now we can really create any shinken daemon with any config file and this on the fly.. (somehow like in the test_bad_start) and then still control the daemon exactly as required/necessary by the test case (more or less easily depending on if the different daemon methods are correctly separated).   The only problem is that I don't know very well (..)  all the test cases/files currently used and I guess it'd be quite a good job to switch all them.. but I do think it'd be a good thing.

wdyt ?  

but now so I understand that I've passed some too much hours on this false-negative test result , damn, you can laugh but I now have a clearer view at least (in fact clearer up to a certain point) :p



The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE:
Pinpoint memory and threading errors before they happen.
Find and fix more than 250 security defects in the development cycle.
Locate bottlenecks in serial and parallel code that limit performance.
Shinken-devel mailing list