2026/09/13
< 2026
|
Sunday, September 13, 2026 (#256)
|
|
References |
Main Work
a careful re-think of how Ferreteria connection-sessions are structured
An improved log-dump (color is preserved; just used straight-up HTML export from Konsole) is here.
- 11:07 The problem is apparently not that the resource was being reused. The resource for the second command is now different from the first -- but they still show the same starter-command.
- This would be appropriate if we were sending some SQL to a still-running process, but we're not. The first process ("main" command) gets opened, SQL is sent to it, response is correctly retrieved, and the resource is being closed (if I'm reading the debug-log properly). We then start a new process for "mariadb-dump", which opens a new resource (rid.403 in the dump here, rid.404 for some reason in my current code) -- but somehow by the time we get to Session->DoInOutLoop(), that resource is set to the "main" command again.
- I guess I need to check right after it is opened, and then (if it is correct there) trace through to see where it gets changed.
- 13:27 When we get to
$oSess->DoCommand($oCmdDump);, it's still showing the old "main" command -- when there shouldn't be any command set, since we're starting a new Session. - 14:02 So, yeah, ok, the Schema object does ask the Engine for a new session (
NewSession()) -- but if memory serves, that re-uses the Runner object, because that is set at config time.- That still shouldn't be a problem if the Runner is being closed between commands (i.e. after the "main" command is done) -- but is it being closed, and does the code which closes it actually clear the resource variable?
- 21:48 The Local Process resource is not ever being closed. This makes less of a difference for ssh2 processes, but may figure into why we get locked into the "main" command for local exports (which is all I've investigated in detail as of yet).
- This suggests I may need to somewhat rethink (again) how the code models executable processes -- because I think we want to be able to "open" and "shut" the process separately from the connection (even though local processes don't really open/shut).