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
> (I hope I'm quite clear, if not I'll re-explain)
>
> So I'm not sure if there is really an error with livestatus module or if
> it's not the test_livestatus that should be adapted in some way..
>
> wdyt ??
>
> 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
>
>
------------------------------------------------------------------------------
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
