BugLogHQ is a tool to centralize the handling of automated bug reports from multiple applications. BugLogHQ provides a unified view of error messages sent from any number of applications, allowing the developer to search, graph, forward, and explore the bug reports submitted by the applications.
Dave Ferguson dave@dkferguson.com via googlegroups.com
Jan 9
to bugloghq
Hey,
All of a sudden I am seeing the following error processing the queue. Nothing in the queue is processing. Anyone have any ideas on this?
Error Executing Database Query.Cannot add or update a child row: a foreign key constraint fails (buglog.bl_entry, CONSTRAINT FK_Entry_ApplicationID FOREIGN KEY (ApplicationID) REFERENCES bl_Application (ApplicationID))
Thanks,
--Dave
Don Quist don.sigmaprojects@gmail.com
Jan 9
to bugloghq
Shot in the dark:
It seems BugLogHQ is trying to log an error reported to with a Application entry ref it doesn't know about yet. Since there is no entry in bl_Application for it, the FK restraint errors.
Possible cause could be...
your blhq client is reporting null or empty string for 'applicationCode', and on reporting the server doesn't insert the null record.
You should really examine the report that is logged and see what application code is referenced, find out why it doesn't exist in bl_Application. Double check any/all of your reporting clients.
As a possible really lazy fix: You can remove the FK constraint in your database schema, though I do not know if this may cause issues
Dave Ferguson dave@dkferguson.com via googlegroups.com
Jan 9
to bugloghq
I have been able to duplicate the issue. I have figured out a sequence that duplicates the issue every time.
Here is what I did...
To get everything back to normal...
Dropped the bloglog db and recreated. (using mysql 5.5.9)
Reran the build script to create tables.
Stopped then started the buglog listener service.
Went to buglog settings --> bloglog listeners
Clicked on test for the REST test.
Went to processing queue and processed the queue.
New issue was created.
Went back to the rest test and created a couple more issues to verify. All issues were created.
Went to buglog settings --> Applications
Selected delete on only application shown.
This could also be done with either the host or the severities.
Next screen I chose to delete all issues for application.
Tried test REST again.
Tried to process queue and received FK error.
Stopped then started listener service.
Created new issue via the test rest process.
Went to processing queue and processed queue.
No error.. queue process.
My guess is that the application is being queued and the delete of the application doesn't clear the cache.
Thanks,
--Dave
Oscar Arevalo oarevalo@gmail.com
Jan 10
to bugloghq
Dave,
That's exactly what is happening. Whenever the listener receives a bug report, it looks up on the appropriate tables the given application name, host and severity, and then caches the returned IDs so that it doesn't have to look them up again. That cache remains valid until it either runs out of space or you re-start the buglog service (which is what you did). So the listener is trying to insert a row with an FK to a non-existing row and hence the error you saw.
FYI, the cache timeout is 300 minutes and the max size is 50.
The deletion of records is a relatively new addition, so I guess that's why this particular bug hasn't popped out before.
Thanks for finding and documenting this issue. I'll make sure to fix it on the next release (whenever it may be!)
Dave Ferguson dave@dkferguson.com via googlegroups.com Jan 9
to bugloghq Hey,
All of a sudden I am seeing the following error processing the queue. Nothing in the queue is processing. Anyone have any ideas on this?
Error Executing Database Query.Cannot add or update a child row: a foreign key constraint fails (
buglog.bl_entry, CONSTRAINTFK_Entry_ApplicationIDFOREIGN KEY (ApplicationID) REFERENCESbl_Application(ApplicationID))Thanks,
--Dave
Don Quist don.sigmaprojects@gmail.com Jan 9
to bugloghq Shot in the dark: It seems BugLogHQ is trying to log an error reported to with a Application entry ref it doesn't know about yet. Since there is no entry in bl_Application for it, the FK restraint errors. Possible cause could be... your blhq client is reporting null or empty string for 'applicationCode', and on reporting the server doesn't insert the null record.
You should really examine the report that is logged and see what application code is referenced, find out why it doesn't exist in bl_Application. Double check any/all of your reporting clients.
As a possible really lazy fix: You can remove the FK constraint in your database schema, though I do not know if this may cause issues
Dave Ferguson dave@dkferguson.com via googlegroups.com Jan 9
to bugloghq I have been able to duplicate the issue. I have figured out a sequence that duplicates the issue every time.
Here is what I did...
To get everything back to normal... Dropped the bloglog db and recreated. (using mysql 5.5.9) Reran the build script to create tables. Stopped then started the buglog listener service. Went to buglog settings --> bloglog listeners Clicked on test for the REST test. Went to processing queue and processed the queue. New issue was created. Went back to the rest test and created a couple more issues to verify. All issues were created. Went to buglog settings --> Applications Selected delete on only application shown. This could also be done with either the host or the severities. Next screen I chose to delete all issues for application. Tried test REST again. Tried to process queue and received FK error. Stopped then started listener service. Created new issue via the test rest process. Went to processing queue and processed queue. No error.. queue process. My guess is that the application is being queued and the delete of the application doesn't clear the cache.
Thanks,
--Dave
Oscar Arevalo oarevalo@gmail.com Jan 10
to bugloghq Dave, That's exactly what is happening. Whenever the listener receives a bug report, it looks up on the appropriate tables the given application name, host and severity, and then caches the returned IDs so that it doesn't have to look them up again. That cache remains valid until it either runs out of space or you re-start the buglog service (which is what you did). So the listener is trying to insert a row with an FK to a non-existing row and hence the error you saw.
FYI, the cache timeout is 300 minutes and the max size is 50.
The deletion of records is a relatively new addition, so I guess that's why this particular bug hasn't popped out before.
Thanks for finding and documenting this issue. I'll make sure to fix it on the next release (whenever it may be!)
Oscar