2026/03/06
|
Friday, March 6, 2026 (#65)
|
|
Apparently the Updater object is setting $oPanel->Message() itself, right before calling $oPanel->OnChange(), thus overriding anything that might have been set elsewhere.
I think some relatively minor restructuring is called for here.
11:18
We're at the point of "readouts are good enough for now", and back to "exports working, but remote exports get hung after the first schema". The problem is still end-of-stream detection -- which apparently is working for the schema-list-fetch, just not for the data-fetch.
- Q1: With regard to how the streams are used, what is the difference between
endpt/Client/MyMar::NewSchemaList()andaux/Schema/MyMar::ExportToStream()? (...which both call the sameDoCommand()to start execution.)
Let me try pulling out what seem to be the key pieces of code for a side-by-side comparison.
endpt/Client/MyMar::NewSchemaList() (works) |
aux/Schema/MyMar::ExportToStream() (hangs)
|
|---|---|
#
// OPEN THINGS:
$oServer = $this->OServer(); // get next-hop connection object
$oServer->Open(); // make sure it's open
$oCmd = CmdLineClass::FromString('SHOW SCHEMAS;');
$oCSListen = new BufferClass;
$oCmd->QOListener()->SetIt($oCSListen);
$oCSErrors = new ScrnErrsClass; // stream for receiving error messages
$oCmd->QOErrorBin()->SetIt($oCSErrors);
$oActCmd = $oServer->DoCommand($oCmd);
|
#
$oCmd = CmdLineClass::FromVoid();
$oCmd->QOListener()->SetIt($oDest); // set output file-stream as listener for export command
// create a stream for receiving error messages
$oErrs = new BufferClass;
$oCmd->QOErrorBin()->SetIt($oErrs);
// TODO: some way to display errors if they come in (maybe a screen-display stream-type?)
$oEng = $this->OEngine();
#$oEngSvr = $oEng->OServer(); // DB Engine server object
$oEngCli = $oEng->OClient(); // DB ENgine client object
$oCmd->WithArray([$sSchema]);
$oCmd->Hints()->SetIt('engine','dump'); // TODO: make these into class constants
$oLocSvr = $oEngCli->OServer(); // next-link server object
$oAct = $oLocSvr->DoCommand($oCmd);
|
The only obvious differences I could see:
- The Server object is retrieved differently -- necessary because Client has a method to retrieve it but Schema doesn't. I've verified that they're both the same object, however (same object ID).
- The Client doesn't explicitly open the Server. I didn't think that should matter, since it's clearly receiving data, but I tried explicitly opening it before calling
DoCommand(), but it didn't seem to make any difference.
Maybe the difference is that the data (in the case where things work properly) is much shorter? I can't see how this would be it, since the very first schema which fails is also much shorter than the buffer-length, but it seemed worth mentioning.
16:02
Q2: InAdded the code for that to the beginning of the excerpt. It actually accepts a Stream as input (not a file-node), via theExportToStream(), is the output Stream being set properly? This function accepts the file-node object as input, but where is the Stream assigned?$oDestargument. (The caller,DoExport(), accepts a file-node and converts it to a Stream, then callsExportToStream()with that Stream.)
17:11
I found some logic-messiness in the EoS() detection, tidied it up. After that, at first I thought I was seeing that the two Server objects were no longer the same object ID, but then I realized I was looking at the IDs of the caller objects (endpt/Client/MyMar and aux/Schema/MyMar), and the Server objects upon which DoCommand() is being invoked are still, in fact, the same ID (382).
20:07
Found some more messiness, tidied it up too; no apparent change. At least the code is getting less cluttered... but I'm at a bit of a loss for how to troubleshoot this issue. Maybe the first attempt (retrieving the schema-list, which works) changes a state somewhere, which then causes the second attempt to fail? How to look for that?
20:53
Copilot suggests[1] that it may be due to how the remote executable is exiting. "Some commands finish running but don’t close their stdout", which can happen for a number of reasons. One thing to check is: if there's an error-stream, see if that has closed.
22:00
I tried fetching and checking first the stderr stream and then also the stdio stream, but they didn't signal EoS either.
I'm wondering if maybe we just have to know which commands exit properly and which don't, with the assumption that the mariadb/mysql command does not, while mysqldump does. If I'm understanding Copilot correctly (and Copilot is also correct), the problem is that it's harder to detect process-exit via ssh2_exec() than via proc_open(), so the former may need some hints as to what to look for.
Maybe I'll try coding that in as a Hint which Proc can ignore...
22:35
I've implemented it, and the code runs, but we still get stuck in the loop. I need to check the logic and make sure (a) the Hint is getting through, and (b) the flag is being set when the input is empty.
Footnote
- ↑ I asked this question -- "Why might feof() correctly signal the end of one ssh_exec() stream and then get stuck at "false" on another?" -- way down in this discussion (private), after a lot of other discussion on EoS-detection. (Yes, I use LLMs; no, I don't give them money or set up workflows which depend on them.)