STDIO over SSH, cell output may contains extra HTML text about sas_kernel HOT 8 CLOSED

That is strange, It appears that reading the listing has gotten out of sequence. Thus the partial html string and valid output some other times. I'm trying the same thing here, in both a SAS notebook, and a python notebook. I haven't come across this so far. Can you try the same code using saspy, in a python notebook and see if it gets out of whack too?
Also, I'm curious of what the whole output was when you created the connection; I can't see it in the picture attached. There might be something about the ssh connection in that message helpful. I get a clean connection here, so I'm not sure what that might say. may see this better from a python notebook.
Also, after running some in the python notebook, can you submit
print(sas.saslog())
and send it to me, there may be something in the SAS log that would be helpful too. Can email it to me [email protected] instead of posting it here and having to 'clean it' in any way.

Trying to attach my 2 notebook outputs; SAS/Python (can't attach anything that renders. download and remove .txt)
Untitled23.html.txt
Untitled22.html.txt

The python one shows how to run the code, in case you're not familiar w/ using saspy itself.

from sas_kernel.

Tom, thank you, email sent. I have better luck with Python saspy (correct more often) but I can still get out-of-sync cell output from repeatedly executing a cell (Ctrl+Enter multiple times)

from sas_kernel.

Thanks! and I got the email too. I'll look over it. I was looking to see if there were any changes in newer versions of python, mine is older that yours, with popen. But I didn't see anything I thought would account for this. There are some other things to check with that too though. Seeing it happen w/ saspy eliminates jupyter, pretty much, so that does make it more straight forward, for me. Trying to get this (ssh) working from windows was a bit strange; it doesn't behave right w/ sockets or subprocesses ... like on linux. So, let me try to see what I see in this and dig back in the code (been long enough since I wrote this that I need a refresher). and I'll come up with the next thing to look at.
Thanks!
Tom

from sas_kernel.

from sas_kernel.

@DaymondLing I've added some diagnostics to the code to see how the I/O is behaving for me. I have a general idea of what would have to be happening for what you are seeing (which I can't reproduce so far), and I was trying to observe how this was working on my end. I do see what I expect, given it's working for me. So, having you run the same diagnostic code on your end and letting me see what it looks like will, at least, give me some insight into what it happening.

I'll email you the code with the diagnostics in it, and instructions .... Running it till you observe the failure will then give me a starting point for what's actually happening on your system.

Thanks,
Tom

from sas_kernel.

Oh, and for IOM to a workspace server, you need java on the python side, and you do need a workspace server (and object server) running on the SAs side. Do you have a production deployment over there? Metadata server, Workspace servers, ...?
The config doc for this is here, and it's the Remote, not Local version: https://sassoftware.github.io/saspy/install.html#iom-using-java
It's not that hard to set up. You need the host (ip) of the machine where the object spawner is running, and the port for the workspace server, and your metadata credentials. If you currently use EG, then you would have what you need, as it uses IOM to connect to workspace servers too.
Again, I can help you get that working in parallel while figuring out this other issue.
Tom

from sas_kernel.

I've pushed this fix to main, along with the fix for the pid, in that initial connection message. I'll probably build this into the next release next week. Give you a little more time to bang on it with your collogues :)

To sum up what's been happening offline, it did turn out to be an issue of STDOUT (LST) not being read by the time STDERR (LOG) had finished and been identified as complete. This is an issue with there being no ability to do ashych I/O from Windows Python with Popen and pipes. To make STDIO over SSH work on Windows, required python threads and queues and that orchestration, especially in the environment being run in, and with slow I/O and no way to prioritize threads, things got out of synch. With a minor tweak to the code I was able to address this and it's working solidly now for Daymond.

from sas_kernel.

So, this is all fixed and built into the new production version; V3.6.7. Closing this out, and if you need anything else, just let me know!
Thanks,
Tom

from sas_kernel.