Bug #6191
closed
Implement thread safety in eventstorage service module
Added by Jan Mach over 4 years ago.
Updated over 1 year ago.
Category:
Development - Database
Description
While working on #4384 I have come across several peculiar issues that have led me to conclusion, that something is amiss in the implementation of eventstorage service and generally with implementation of event database access from Flask application directly via psycopg2.
I have found out that it is indeed not implemented in thread-safe manner.
- Related to Bug #4384: Possibility of DoS by repeating long query added
Let's solve by configuration+doc - if using Apache, use process based MPM, if WSGI, configure no threading.
If lack of threading bites us in the future, we'll go for more thorough solution.
- To be discussed changed from Yes to No
- Target version changed from 2.6 to 2.7
- Target version changed from 2.7 to 2.8
- Target version changed from 2.8 to Backlog
- Target version changed from Backlog to Future
- Assignee deleted (
Jan Mach)
- Blocks Bug #7590: /api/events/search sometimes crashes with TypeError: Expected 22 arguments, got 23 added
- Status changed from New to In Progress
- Target version changed from Future to 2.10
So, the configuration was changed on mentat-hub. The only thing to do is to write some information to the documentation, right?
- Blocks Bug #7565: Timeline falls flat on certain query added
Rajmund Hruska wrote in #note-10:
So, the configuration was changed on mentat-hub. The only thing to do is to write some information to the documentation, right?
Right. And maybe explicitly fix this in our ansible roles (sigh).
And cuz I'm dork, I did set up mpm_worker instead of mpm_prefork. Sigh, corrected, let's watch it further.
- Assignee set to Pavel Kácha
- Status changed from In Progress to Resolved
- % Done changed from 0 to 100
- Status changed from Resolved to Closed
Also available in: Atom
PDF