Nagios Support Forum

I seem to be getting the bad ticket issue every so often now, more than likely due to the high load on the server and/or an apply config was recently performed. Is there any way this could be corrected by Nagios team so that it would retry the DB connection if it receives a -1 for the user ID?

This is a good "bug report" so I went ahead and filed one:
TASK ID 4658.

You could also try increasing the number of max connections on the db.

Bandit,

Since we can't test this I'm going to have you update your rr.php file on the system in question and see if this fixes your issue. Grab the attachment, unzip, then overwrite the old file here: I have PHP attempt to get the user_ticket, if return user_ticket=-1 then loop(sleep(1), get user_ticket), then after 5 attempts exit out with an error if user_ticket is still -1.

Changes are lines 66 to 77 in rr.php if you want to have a gander. Let me know!

changes applied. I will let you know.

Thanks!

Bandit, let us know when you have tested this. Thanks.

Fix was good in a response answered in a PM. Thanks Bandit. We'll go ahead and close this thread.

Topic unlocked at request of Bandit.

Thanks Andy.

I just wanted to add that we still occasionally get this issue. It seems to always happen when XI happens to send a notification as we are applying changes. I modified the code to do 10 retries and upped the sleep timer from 1 to 5 seconds between tries. I'll update later(few days) if the issues seems to have been resolved by giving it the more time.

BanditBBS wrote:It seems to always happen when XI happens to send a notification as we are applying changes.

This actually makes a lot of sense as load could effect the necessary postgres query for the ticket/XI userid.

Ok, the issue is still happening, albeit very seldom after my recent changes.

Would it be smart for XI to wait after an apply until it is complete before it sends notifications? Surprised that nobody else is using the rr link and running into this. My XI server has an avg load of 2 with 16 cores, so is running great and still getting this error. Or is rr just not used by that many people? Hmmmm