Join GitHub today
GitHub is home to over 36 million developers working together to host and review code, manage projects, and build software together.Sign up
[dev.icinga.com #5103] The way notification_id is implemented is broken #952
This issue has been migrated from Redmine: https://dev.icinga.com/issues/5103
Created by gbeutner on 2013-11-19 15:39:55 +00:00
a) Multiple notifications can run in parallel.
b) The NotificationSentToAllUsers event is sent before all notifications for a service are sent (which is a bug in itself). However, the real problem is that it's possible that the event is send after some of the notifications are sent - in which case the INSERT for icinga_notifications hasn't been pushed to the DbConnection objects yet.
2014-01-27 16:22:48 +00:00 by (unknown) d883926
2014-01-28 14:53:12 +00:00 by (unknown) f30eca5
2014-01-28 16:53:40 +00:00 by (unknown) a3097ff
2014-01-29 12:34:43 +00:00 by (unknown) 5c5d94b
2014-01-29 16:38:02 +00:00 by (unknown) d31ca31
Updated by mfriedrich on 2014-01-28 15:02:11 +00:00
The wrong id and therefore unique constraint violation is handled in #5265 changing the notification signal order.
The most obvious problem is still that db_ido doesn't have any notification db object (not config, nor status) for historical insert ids. By changing the signal handler to pass the current notification object ptr it would be reasonable to create an additional HistoryInsertID cache based on the current notification object. That id could then be used for the notification_id referenced by the contactnotifications table.
Problem: If a new notification is triggered, it will overwrite the last notification id, even if there are pending contact notification entries.
That would require making the notification component's process blocking (rather: send notifications to users in sequentional order) which is not intended.
Updated by mfriedrich on 2014-01-28 16:52:29 +00:00
Workaround for sequential inserts
Updated by mfriedrich on 2014-01-29 16:46:21 +00:00
The cache itself is working for both MySQL and PostgreSQL. Though, it's ugly and introduced another object ptr inside the query object which should be refactored in #5579 - closing this issue as the main functionality is restored.