What is SstUnixSocketDemultiplexor?

[Louis LaBrunda]

Hi All,

In both of my Raspberry Pi Linux programs I use ObjectDumper to save settings.  One of the programs has somehow gotten an instance of #SstUnixSocketDemultiplexor saved in the object dumper settings file.  It is, I expect, in one of the many instances variables of one of the many objects I save in the settings.

I use #SstHttpClient (and friends) to do Gets and Posts and sometimes I save error replies in the settings as #lastError, but that that doesn't seem to be where it comes from.

Could it be part of a non-error reply?

Does anyone have any idea what it is?

Lou

[Louis LaBrunda]

P.S.  I am also using Seaside, so that could have something to do with it.

Lou

[Marcus Wagner]

Lou, 

I cannot find this class. There is a runtime application under Unix with a similar name, SstUnixSocketCommunication, but...

If you have access to the class send it the message controller to get the name of its defining app.

As the class name implies, it provides communication support, not being part of Seaside (which may make use of this support).

Seaside classes follow a different naming convention, Sstxxx denotes belonging to server Smalltalk (an architecture to support services and mainframes).

Kind regards

M

[Louis LaBrunda]

Hi Marcus,

Thanks for the help.

In my Raspberry Pi Linux install (V15) it lives in SstEnhancedSelectUNIX a sub app of SstEnhancedSelect, which is a sub app of SstTcpCommunications (V11).

I use #SstHttpClient to talk to at least three local API's and a few external API's via the internet.  Some of the data I get from the local API's is combined with values I get from my Seaside "Settings" page and is saved in my settings object via ObjectDumper.  So far I am unable to figure out which of the may objects that make up the settings object has an instance of #SstUnixSocketDemultiplexor.  Based on the size of the object dumped file, the instance of #SstUnixSocketDemultiplexor is well over a megabyte.  I now have saved settings files over five megabytes in size.  I'm about to check to see if that is one or more instances of $SstUnixSocketDemultiplexor and see if I can tell what is in it.

Lou

[Louis LaBrunda]

Apparently an instance of #SstUnixSocketDemultiplexor is not causing my dumped settings to be a large file.  Later dumped files are now five megabytes in size but don't contain an instance of #SstUnixSocketDemultiplexor.

I will keep diging.

Lou

[Marcus Wagner]

Hi Lou,

thanks to the refined information I found the classes and had the opportunity to look into them. 

They care about socket communication particular in absence of asynchronous callout support.

I admit, I have no Raspberry PI at hand, but that might be related (as async callout elsewhere is common) to that.

I have a certain scenario in mind, what the classes provide and how they handle the problem.

Anyway, evident is that these classes have to be installed properly in a fresh image and they do cache, that means they collect instances (during operation) to do their work.

And that they are important to handle your communication infrastructure. the handling of several external APIs.

Being remote, without direct access, I can provide you only with some advice, in hope that it helps.

It seems, that dumping these instances by the ObjectDumper, communication content is included (the cached content).

Would your use be packaging, I would suggest not to run the application before dumping and to add rules (setting the cache content to nil), so not to package any communciation content.

However, you want to save configuration settings in context of Seaside, I assume, while being in operation.

 But that means, the same principles (of packaging) have to be applied here: clean the cache content before dumping. 

Or alternatevly, not to actually run any commincation before saving its cofiguration (for packaging, this works - you can load into a fresh image without executing anything before packaging). 

Handling some configuration settings in a running application however collides with that approach.

So the point is: find out what is cached before saving the setting, clean the cache and then save using the ObjectDumper. 

I do not know if the Seaside scenario provides you with hooks to prepare the save settings.

And perhaps a post operation has also to take place: I can imaging that whole thing collides if you run some communication (which is pending), prepare the settings (clean the cache), save the settings via ObjectDumper and then the communication begins to finalize and interferes (e.g. attempts to return contents). 

If that turns out to become a problem, you have to assure a secure transaction (saving the setting must not take place with pending communication).

Another point to clarify is whether the operational support given by the multiplexors is important for your "save settings" (I guess not). 

If that is the case, you should avoid to dump these instances (in a packing scenario, rules would achieve that). 

Restoring such caches later (including artefacts from previous communication) sounds brittle, anyway.

To avoid saving the cache content is the key point.

Kind regards

M

[Louis LaBrunda]

Hi Marcus,

Thank you very much for all the info.  It turns out the instance of #SstUnixSocketDemultiplexor is not the cause of my settings file getting large.  I made a lot of changes and refactoring awhile ago and in doing so I changed something that allowed a process to be saved with the settings.  I will fix that soon.

I do most of the development for the two Raspberry Pi programs on Windows.  I can test them within limits in the development environment on Windows.  So, when I noticed a large settings file, I copied it from Linux to Windows and loaded it with a script in the Windows  development environment, where it complained about #SstUnixSocketDemultiplexor, which obviously doesn't exist.  That lead me to think the instance of #SstUnixSocketDemultiplexor, was the cause of the large size.

When I'm ready to package, I copy my mgr1500.dat file from Windows to my development Raspberry Pi.  I don't trust the Raspberry Pi Linux install to share the manager on Windows via EMSRV.  Coping, works well and doesn't take too long.  I start with a clean image and load all the features and maps with an abt.cnf file.  I then package without doing anything that could pollute the image.  One program is a GUI by nature.  I added a window to the other because packaging everything, including the Seaside stuff works much better with the "Make Executable" button on the organizer window than using "XD" packaging.

Fortunately, the presence of an instance of #SstUnixSocketDemultiplexor isn't a problem.  It comes and goes and doesn't seem to hurt anything.  Also, one of the things I talk to uses a SstHttpClient call with streaming = true, while ObjectDumper could be called.  I don't know for sure if that is where the instance of #SstUnixSocketDemultiplexor comes from but if it is, I don't see an easy way around it.

Anyway, thanks again and back to not dumping a process, which I know better than to do but somehow let slip in.

Lou

[Marcus Wagner]

Hi Lou,

first, fine, that you found s.th. to solve your issue.

About the trust EMSRV and the manager.dats it handles. The point is: emsrv is the manager. It does NOT care where it runs or who is calling the socket. 

All socket operations EMSRV is offering are transactions, are to be committed or rolled back. That keeps the manager.dat save.

To make it short, as Spock would say: its not logical, either you trust emsrv or not. It is irrelevant who is on the other side of the communication, Windows or Linux or Raspberrys. 

If you dont trust, then you have to run your dev image against a singleton file manager.dat, exclusively locked by you.

My experience is: invest in the machine holding the manager.dats and running one or more emsrv services, concerning its robustness. 

Potential problems come from network (WLAN, Wimax), firewall settings or, concerning Linux, from SELINUX configurations, if you turned that on. But not from the image accessing this point.

And I understand that your (and my) primary preferred work area is Windows. 

I had several troubles in using the development surface under Linux, but that is a private, separate story, not an issue here.

If problems come up in the target (not necessarily in your environment, using Raspberry Pis) think about XD.

I had several situations in the past, where it was uncomfortable, unpractical or even impossible to develop anything on the target machine, except of, to run the produced image there.

In your area that would mean, you would produce the runtime image entirely under Windows, transfer an image into a installed runtime engine on the target and test it there. No development happening there, ever.

My row of such machines is long: ZOS Mainframes, AS400, OS/2, Novell Netware and sometimes certain Windows NT (3.5, 4, 4.5) servers, where the only possible manipulation was to stop and run a service (aka abtntsrv.exe)

And my EMSRVs had to withstand many developers (up to 50), running their dev. image concurrently against a (single) central repository. Uff. The problem was the throughput of the net and the server disk performance. Sometimes a transaction to be rolled back.

The stability and integrity comes from the core - originating from Envy in the early 90ies.

That never was an issue. Even at the ancient days, when the user security was also managed there (users and roles sometimes pop up, if you adminstrate these in your projects).

Good luck and success.

I hope you will make the desired progress in fixing this.

Kind regards

M

[Louis LaBrunda]

Hey Marcus,

I have made the change to fix the settings file size problem.  I had an instance variable that held a Delay (which also held a process) that was getting saved with the object dump.  I had a mechanism to deal with this kind of thing but had neglected to include the delay in it.  The fix looks good so far but I won't know for sure until tomorrow when the system waters my lawn and goes through the code that causes the problem.

As for EMSRV, I will take a look at using it from the Raspberry Pi.  If I can set it up without too much trouble, it will probably make life a little easier.

I have made many XD images before.  I have even made them for this program that doesn't need to be a GUI program.  I would XD package it on Windows and run it on Raspberry Pi Linux.  That was cool.  The trouble is Seaside.  It seemed that with every little change to the program, that often involved Seaside code or with every new version of VA Smalltalk, packaging an XD image would fail.  It would drive me nuts and take, what felt like, forever to fix.  I then realized that my other Raspberry Pi program, which is a GUI (clock) program that shares a lot of code (both Smalltalk and Seaside) would package with the "Make Executable" button.  It seldom fails to package.  So, I added a little window and package that way.  It turns out it is even easier to start the windowed GUI programs at Linux boot time than to start headless programs.  The non GUI program that now has a window, runs without a monitor, so I don't care that it has a window and it actually gives me an easy way to exit it if I want.

Thanks again for the help and suggestions.

Lou

[Marcus Wagner]

Hi Lou,

I understand, XD requires the utmost discipline concerning cleanness of the source - and Seaside coming from other platforms is not bound to follow these restrictions. 

Platform independence has a high price - but usually that pays off, mostly in the longterm and in particular in VAST.

Good luck tomorrow...

M

[Louis LaBrunda]

Hi Marcus,

To wrap this up, my lawn got watered on time and the settings file stayed its proper size.

Thanks for the help and interest.

Lou