2011/2/17 nap <napar...@gmail.com>
>
> 2011/2/17 Grégory Starck <g.sta...@gmail.com>
>
>> Hi,
>>
>> Hi,
>
>> for now (well for some days unfortunately) I'm on a specific problem ; the
>> one with livestatus that I encountered when I made the commit
>> 8113605b5652e3273ada9287b785c56f1b857bf7 &
>> 0c626cd00a3fcfc18562e7dd66e9ea54464820fa
>>
>> but after long debugging it seems the problem would be because the
>> test_livestatus doesn't fork for the livestatus module ; and as far as I see
>> that brings python object mix problem : the Service object is thus twice
>> instanciated : one normal time by scheduler ; and one time by livestatus
>> (by manage_initial_service_status) but when livestatus relink the downtime
>> it so relinks the downtime with its own Service object which is not the one
>> from scheduler.. then scheduler gets this bad relink of the downtime to a
>> Service object not the same as initially.. and that would makes the problem
>> here..
>>
>> But it's normal that the livestatus got its own objects. Should be the
> same with Downtime too. Both should not share a common objects list. What
> happened from the livestatus point of view wth the downtime? It should
> create a new one and search for the service in its own list, not the
> scheduler one (here the one of the test Class).
>
> From the scheduler point of view, it should not change a thing, the other
> downtime object should not "touch" it after all. So the downtime should
> raide a brok, then the module get it like all modules, and recreate the
> object.
>
> Maybe a solution here for testing is to add the pickle pass for brok : we
> can pickle dump/load the brok before give them to the modules, so we are
> sure it will not be a direct pointer or something like it. After all, the
> Pyro sending is a pickle pass, so with it we are sure to test in real
> conditions.
>
>
> Jean
>
ok then I think I more clearly see the issue with this small explanation :s
thx Jean for this info I'm going to try something..
greg.
------------------------------------------------------------------------------
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.
http://p.sf.net/sfu/intel-dev2devfeb
_______________________________________________
Shinken-devel mailing list
Shinken-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/shinken-devel
