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

Ian icjohnson at protonmail.com
Tue May 27 19:34:40 PDT 2025


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
> **************************************************


More information about the GemStone-Smalltalk mailing list