Details
-
Type:
Bug
-
Status: Done
-
Resolution: Done
-
Fix Version/s: None
-
Component/s: Qserv
-
Labels:None
-
Story Points:5
-
Epic Link:
-
Sprint:DB_S15_06, DB_S15_07, DB_S15_08
-
Team:Data Access and Database
Description
I noticed some strange (reproducible!) behavior: if I run:
qserv-check-integration.py --case=01
|
then restart mysqld
<runDir>/etc/init.d/mysqld restart
|
then the query:
mysql --host=127.0.0.1 --port=4040 --user=qsmaster
|
qservTest_case01_qserv -e
|
"SELECT COUNT(*) as OBJ_COUNT
|
FROM Object
|
WHERE qserv_areaspec_box(0.1, -6, 4, 6)"
|
consistently fails every single time.
To fix it, it is enough to restart xrootd.
Attachments
Issue Links
Activity
John Gates, I do not see any branches in github. Is there code to review or is it design-level ticket?
To say truth I'm not very comfortable with the idea that we can start second worker which will cause first worker's suicide, it feels like it could potentially misbehave. Another question - do we really want to destroy all in-memory tables on every worker restart (without restarting mysql)?
I left few code comments in PR, removing myself from reviewers.
I have the same concern with new workers causing old ones to commit suicide.
Regarding the destruction of all in-memory tables on every worker restart - I think it's the safe thing to do. I'm also not sure it's a big deal - doesn't the worker effectively have to do exactly that every time it switches to the next chunk in a scan?
Serge Monkewitz
added a comment - I have the same concern with new workers causing old ones to commit suicide.
Regarding the destruction of all in-memory tables on every worker restart - I think it's the safe thing to do. I'm also not sure it's a big deal - doesn't the worker effectively have to do exactly that every time it switches to the next chunk in a scan? The problem with the memory tables is that the contents of the tables are destroyed when mysql restarts, but the databases and tables remain. The worker only populates the tables if they don't exist. The logic for populating the tables could be changed but there is an advantage to starting from a know state.
John Gates
added a comment - The problem with the memory tables is that the contents of the tables are destroyed when mysql restarts, but the databases and tables remain. The worker only populates the tables if they don't exist. The logic for populating the tables could be changed but there is an advantage to starting from a know state. 
Let's open a new story that captures this future refactoring, it can be attached to
DM-3171