search

capensis / canopsis-nagios

Nagios NEB for Canopsis
9 stars 4 forks source link

Impossible to load 2 times the module on same Nagios instance #4

Open william-p opened 11 years ago

william-p commented 11 years ago

Only one instance of Canopsis receive events.

conf:

broker_module=/opt/icinga/lib/neb2amqp.o name=Central kvm09.
broker_module=/opt/icinga/lib/neb2amqp.o name=Central kvm21.

log:

[1360597234] neb2amqp: NEB2amqp 0.3-rc by Capensis. (connector: nagios)
[1360597234] neb2amqp: Please visit us at http://www.canopsis.org/
[1360597234] neb2amqp: CACHE: stat: No such file or directory
[1360597234] neb2amqp: CACHE: /usr/local/nagios/var/canopsis.cache: No such file or directory
[1360597234] neb2amqp: AMQP: Successfully connected
[1360597234] neb2amqp: successfully finished initialization

[1360597234] Event broker module '/opt/icinga/lib/neb2amqp.o' initialized successfully.
[1360597234] neb2amqp: NEB2amqp 0.3-rc by Capensis. (connector: nagios)
[1360597234] neb2amqp: Please visit us at http://www.canopsis.org/
[1360597234] neb2amqp: CACHE: stat: No such file or directory
[1360597234] neb2amqp: CACHE: /usr/local/nagios/var/canopsis.cache: No such file or directory
[1360597234] neb2amqp: successfully finished initialization
ziirish commented 11 years ago

Actually this limitation is due to the way the shared objects work.

In C there is no 'namespace' so every object (function) loaded by a module is "public". This means if you load the same module twice, there might be some conflicts.

As a workaround we could implement a list of AMQP servers handled by the neb.

We could use an ini file to store the differents credentials.

william-p commented 11 years ago

Ok, can't fix it.

linkdd commented 9 years ago

The problem is not the absence of namespace.

In fact, we store many data in the global scope. It would be OK if we were just reading them. But we write to them.

In a multi-threaded context, the code, and the static data will be loaded once, every thread will share the same memory space for the code and the static data.

Since in C, all variables declared in the global space are stored in the static data space, there won't be any copy-on-write algorithm here.

Loading twice the broker will make the two threads write to the same shared data with no locking, or lock-free algorithm.

TL;DR: Variables in global scope are not easily thread-safe.

So this can be fixed with a better design in the source code. Unfortunately, there will be some time before refactoring.