[GemStone-Smalltalk] GemStone-Smalltalk Digest, Vol 129, Issue 4

Thu May 29 15:28:02 PDT 2025

Ian,

I would prefer a more explicit wait of not exiting than running netldi in the foreground. I’ve seen two recommendations:
	CMD ["tail", "-f", "/dev/null”]
	CMD ["sleep", "infinity"]

> … the remote page cache becomes stale on system reboot ...
> Note that the container lives in all the above cases ...

Could you say more about your architecture? You have the stone in one Docker container and a gem in another Docker container? Which container lives and which one reboots?

The idea of scaling gems with Docker sounds plausible, but I’ve not heard of anyone doing it.

James

> On May 27, 2025, at 7:34 PM, Ian via GemStone-Smalltalk <gemstone-smalltalk at lists.gemtalksystems.com> wrote:
> 
> Hi Norm, James,
> 
> I think this is worth exploring. Please bear with me.
> 
> To answer your question Norm, container entry points, however you run them (docker run, compose entrypoint:, entry point in the dockerfile, whatever) runs as PID 1.
> 
> I want to run a script, call it startup.sh, like this in my dockerfile:
> 
> ENTRYPOINT: ["/some/container/path/startup.sh"]
> 
> The scripts job is to:
> 
> 1. startnetldi -s
> 2. topaz -I topazini -S instructions.topaz (simplified)
> 
> Once these two requirements are met, startup.sh exits. Meaning PID 1 also exits and the container shuts down (depending on you compose settings, an endless restart likely ensues).
> 
> Now, when I run step one as 'netldid -s,' netldid runs on the foreground. PID 1 lives on and the container persists. Connections to the stone live, my application runs in the gem running in the container and all is good.
> 
> The issue I am now trying to resolve is the fact that the remote page cache becomes stale on system reboot, system crashes or connection interruptions. 
> 
> Note that the container lives in all the above cases, netldid process persists and is happy but a stale page cache is terminal. 
> 
> I must bring down the containers by some manual method: docker compose down, or in terms of kubernetes, restart the deployment, to have the cache regenerated from scratch. 
> 
> This is fine as everything persists in the stone. However, provisions must be made to handle containers whose connection to the stone is terminated/interrupted for whatever the reason.
> 
> From here: 
> 
> My goal is to run all connections to the stone using x509 enabled gems for all connecting entities of whatever type. The above is the beginnings of a POC to test what hurdles had to be overcome; Whether or not it would even be possible. It is doable, I think.
> 
> Having started the full read of the x509 guide, I come to realize that the cache is created at the prompting from the server-side x509 enabled netldi through the host agent. In this case, it seem that it may be possible to build container resilience into what I a trying to do as the remote netldi must be alive, requesting a login from the server by saying "here I am, here is my port." What I don't know is that if the remote netldi sees a local cache will it still fail or will it say, you silly cache, you're busted, let's clean up and make a new one.
> 
> If this can be made to work Gemstone/S remote gems could sit behind some kind of load balancer and run HA in docker, docker swarm or any kubernetes variety fully and robustly containerized and talk to a stone that sits as they do now, on a dedicated server managing connections, transactions and persisting data to extents until the cows come home.
> 
> I feel like this has probably already been done but can't find a trailblazer on the web to guide me.
> 
> I do know that I can run netldi on many nodes, bare metal or VM fronted by some form of load balancer for HA, scalability is simply much easier using containers and a container management system of some kind. 
> 
> Seems to me that remote gems are the perfect, secure and safe and scalable way to run Smalltalk based microservices in remote containerize gems with persistent object storage to boot!
> 
> Long store short, to my question: Am I approaching this in the correct way? Is what I am trying to do even possible?
> 
> Ian
> 
> Sent with Proton Mail secure email.
> 
> On Tuesday, May 27th, 2025 at 4:00 PM, gemstone-smalltalk-request at lists.gemtalksystems.com <gemstone-smalltalk-request at lists.gemtalksystems.com> wrote:
> 
>> Send GemStone-Smalltalk mailing list submissions to
>> gemstone-smalltalk at lists.gemtalksystems.com
>> 
>> To subscribe or unsubscribe via the World Wide Web, visit
>> https://lists.gemtalksystems.com/mailman/listinfo/gemstone-smalltalk
>> or, via email, send a message with subject or body 'help' to
>> gemstone-smalltalk-request at lists.gemtalksystems.com
>> 
>> You can reach the person managing the list at
>> gemstone-smalltalk-owner at lists.gemtalksystems.com
>> 
>> When replying, please edit your Subject line so it is more specific
>> than "Re: Contents of GemStone-Smalltalk digest..."
>> 
>> 
>> Today's Topics:
>> 
>> 1. netldid (Ian)
>> 2. Re: netldid (James Foster)
>> 3. Re: netldid (Norm Green)
>> 4. Re: netldid (Ian)
>> 
>> 
>> ----------------------------------------------------------------------
>> 
>> Message: 1
>> Date: Mon, 26 May 2025 19:33:08 +0000
>> From: Ian icjohnson at proton.me
>> 
>> To: "gemstone-smalltalk at lists.gemtalksystems.com"
>> gemstone-smalltalk at lists.gemtalksystems.com
>> 
>> Subject: [GemStone-Smalltalk] netldid
>> Message-ID:
>> PejD_sVleK6zxKRUkWsS3REI1mSSbkKihZU8MKvy-t-r1_b4wyM-WvvRxoRr8gIYVe5uQ4TXtf5G0BxUZ2zFNo-YwKfY6v2do6NGknySb7U=@proton.me
>> 
>> 
>> Content-Type: text/plain; charset="utf-8"
>> 
>> Hi GemStoners,
>> 
>> Are there plans in the works to allow netldid to run in the foreground?
>> 
>> This would allow the running of startnetldi -s in a container without an infinite loop and a long running sleep statement (Better way?)
>> 
>> On that note, I am able to containerize a running client application, linked and RPC; Am I running down a road that will eventually bonk me in the head?
>> 
>> Thanks in advance,
>> Ian
>> 
>> Sent with Proton Mail secure email.
>> -------------- next part --------------
>> An HTML attachment was scrubbed...
>> URL: http://lists.gemtalksystems.com/mailman/archives/gemstone-smalltalk/attachments/20250526/67818374/attachment-0001.htm
>> 
>> 
>> ------------------------------
>> 
>> Message: 2
>> Date: Mon, 26 May 2025 13:25:35 -0700
>> From: James Foster Smalltalk at JGFoster.net
>> 
>> To: Ian icjohnson at proton.me
>> 
>> Cc: "gemstone-smalltalk at lists.gemtalksystems.com"
>> gemstone-smalltalk at lists.gemtalksystems.com
>> 
>> Subject: Re: [GemStone-Smalltalk] netldid
>> Message-ID: 24CFB521-8477-4700-94F5-3E15CA35E192 at JGFoster.net
>> 
>> Content-Type: text/plain; charset="utf-8"
>> 
>> Ian,
>> 
>> A number of people have created Docker images for GemStone/S. This is fine as long as you map the database to something outside the container (else it will be lost when the container stops).
>> 
>> See https://downloads.gemtalksystems.com/docs/GemStone64/3.7.x/GS64-SysAdminGuide-3.7/B-CommandReference.htm#pgfId-857966 to let netldid run in the foreground.
>> 
>> James
>> 
>>> On May 26, 2025, at 12:33?PM, Ian via GemStone-Smalltalk gemstone-smalltalk at lists.gemtalksystems.com wrote:
>>> 
>>> Hi GemStoners,
>>> 
>>> Are there plans in the works to allow netldid to run in the foreground?
>>> 
>>> This would allow the running of startnetldi -s in a container without an infinite loop and a long running sleep statement (Better way?)
>>> 
>>> On that note, I am able to containerize a running client application, linked and RPC; Am I running down a road that will eventually bonk me in the head?
>>> 
>>> Thanks in advance,
>>> 
>>> Ian
>>> 
>>> Sent with Proton Mail https://proton.me/mail/home secure email.
>>> _______________________________________________
>>> GemStone-Smalltalk mailing list
>>> GemStone-Smalltalk at lists.gemtalksystems.com
>>> https://lists.gemtalksystems.com/mailman/listinfo/gemstone-smalltalk
>> 
>> 
>> -------------- next part --------------
>> An HTML attachment was scrubbed...
>> URL: http://lists.gemtalksystems.com/mailman/archives/gemstone-smalltalk/attachments/20250526/eebd20d9/attachment-0001.htm
>> 
>> 
>> ------------------------------
>> 
>> Message: 3
>> Date: Mon, 26 May 2025 13:43:48 -0700
>> From: Norm Green norm.green at gemtalksystems.com
>> 
>> To: gemstone-smalltalk at lists.gemtalksystems.com
>> Subject: Re: [GemStone-Smalltalk] netldid
>> Message-ID: 7f994942-644d-4801-806e-a3c3f419962e at gemtalksystems.com
>> 
>> Content-Type: text/plain; charset="utf-8"; Format="flowed"
>> 
>> Hi Ian,
>> 
>> I don't fully understand why you want to run netldi in the foreground.
>> That said, startnetldi forks $GEMSTONE/sys/netldid with appropriate
>> arguments, so you could run that in the foreground.
>> 
>> Norm Green
>> 
>> 
>> On 5/26/2025 12:33 PM, Ian via GemStone-Smalltalk wrote:
>> 
>>> Hi GemStoners,
>>> 
>>> Are there plans in the works to allow netldid to run in the foreground?
>>> 
>>> This would allow the running of startnetldi -s in a container without
>>> an infinite loop and a long running sleep statement (Better way?)
>>> 
>>> On that note, I am able to containerize a running client application,
>>> linked and RPC; Am I running down a road that will eventually bonk me
>>> in the head?
>>> 
>>> Thanks in advance,
>>> 
>>> Ian
>>> 
>>> Sent with Proton Mail https://proton.me/mail/home secure email.
>>> 
>>> _______________________________________________
>>> GemStone-Smalltalk mailing list
>>> GemStone-Smalltalk at lists.gemtalksystems.com
>>> https://lists.gemtalksystems.com/mailman/listinfo/gemstone-smalltalk
>> 
>> -------------- next part --------------
>> An HTML attachment was scrubbed...
>> URL: http://lists.gemtalksystems.com/mailman/archives/gemstone-smalltalk/attachments/20250526/8b7b14ed/attachment-0001.htm
>> 
>> 
>> ------------------------------
>> 
>> Message: 4
>> Date: Mon, 26 May 2025 21:05:20 +0000
>> From: Ian icjohnson at proton.me
>> 
>> To: James Foster Smalltalk at JGFoster.net
>> 
>> Cc: "gemstone-smalltalk at lists.gemtalksystems.com"
>> gemstone-smalltalk at lists.gemtalksystems.com
>> 
>> Subject: Re: [GemStone-Smalltalk] netldid
>> Message-ID:
>> 2OoOBEiO6J-fYbKZwRSH68GLdy_pWxVzfCcdsPW6lpox5PVN-6Qp6m9ZUJHG8YC_xCOnX1pi-PJ2zrOgLQRC86SgPeSX2PT5hpACzicoPGM=@proton.me
>> 
>> 
>> Content-Type: text/plain; charset="utf-8"
>> 
>> netldid -s
>> 
>> The wording got me.
>> 
>> Thanks!
>> 
>> Ian
>> 
>> Sent with Proton Mail secure email.
>> 
>> On Monday, May 26th, 2025 at 5:25 PM, James Foster Smalltalk at JGFoster.net wrote:
>> 
>>> Ian,
>>> 
>>> A number of people have created Docker images for GemStone/S. This is fine as long as you map the database to something outside the container (else it will be lost when the container stops).
>>> 
>>> See https://downloads.gemtalksystems.com/docs/GemStone64/3.7.x/GS64-SysAdminGuide-3.7/B-CommandReference.htm#pgfId-857966 to let netldid run in the foreground.
>>> 
>>> James
>>> 
>>>> On May 26, 2025, at 12:33?PM, Ian via GemStone-Smalltalk gemstone-smalltalk at lists.gemtalksystems.com wrote:
>>>> 
>>>> Hi GemStoners,
>>>> 
>>>> Are there plans in the works to allow netldid to run in the foreground?
>>>> 
>>>> This would allow the running of startnetldi -s in a container without an infinite loop and a long running sleep statement (Better way?)
>>>> 
>>>> On that note, I am able to containerize a running client application, linked and RPC; Am I running down a road that will eventually bonk me in the head?
>>>> 
>>>> Thanks in advance,
>>>> Ian
>>>> 
>>>> Sent with Proton Mail secure email.
>>>> _______________________________________________
>>>> GemStone-Smalltalk mailing list
>>>> GemStone-Smalltalk at lists.gemtalksystems.com
>>>> https://lists.gemtalksystems.com/mailman/listinfo/gemstone-smalltalk
>> 
>> -------------- next part --------------
>> An HTML attachment was scrubbed...
>> URL: http://lists.gemtalksystems.com/mailman/archives/gemstone-smalltalk/attachments/20250526/b228663a/attachment-0001.htm
>> 
>> 
>> ------------------------------
>> 
>> Subject: Digest Footer
>> 
>> _______________________________________________
>> GemStone-Smalltalk mailing list
>> GemStone-Smalltalk at lists.gemtalksystems.com
>> https://lists.gemtalksystems.com/mailman/listinfo/gemstone-smalltalk
>> 
>> 
>> ------------------------------
>> 
>> End of GemStone-Smalltalk Digest, Vol 129, Issue 4
>> **************************************************
> _______________________________________________
> GemStone-Smalltalk mailing list
> GemStone-Smalltalk at lists.gemtalksystems.com
> https://lists.gemtalksystems.com/mailman/listinfo/gemstone-smalltalk

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gemtalksystems.com/mailman/archives/gemstone-smalltalk/attachments/20250529/3899c7cf/attachment-0001.htm>