<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body style="overflow-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;">Ian,<div> </div><div>I would prefer a more explicit wait of not exiting than running netldi in the foreground. I’ve seen two recommendations:</div><div> CMD ["tail", "-f", "/dev/null”]</div><div> CMD ["sleep", "infinity"] <div> </div><div>> … the remote page cache becomes stale on system reboot ...</div><div>> Note that the container lives in all the above cases ...</div><div> </div><div>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?</div><div> </div><div>The idea of scaling gems with Docker sounds plausible, but I’ve not heard of anyone doing it.</div><div> </div><div>James</div><div> <blockquote type="cite"><div>On May 27, 2025, at 7:34 PM, Ian via GemStone-Smalltalk <gemstone-smalltalk@lists.gemtalksystems.com> wrote:</div> <div><div>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@lists.gemtalksystems.com <gemstone-smalltalk-request@lists.gemtalksystems.com> wrote: <blockquote type="cite">Send GemStone-Smalltalk mailing list submissions to gemstone-smalltalk@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@lists.gemtalksystems.com You can reach the person managing the list at gemstone-smalltalk-owner@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@proton.me To: "gemstone-smalltalk@lists.gemtalksystems.com" gemstone-smalltalk@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@JGFoster.net To: Ian icjohnson@proton.me Cc: "gemstone-smalltalk@lists.gemtalksystems.com" gemstone-smalltalk@lists.gemtalksystems.com Subject: Re: [GemStone-Smalltalk] netldid Message-ID: 24CFB521-8477-4700-94F5-3E15CA35E192@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 <blockquote type="cite">On May 26, 2025, at 12:33?PM, Ian via GemStone-Smalltalk gemstone-smalltalk@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@lists.gemtalksystems.com https://lists.gemtalksystems.com/mailman/listinfo/gemstone-smalltalk </blockquote> -------------- 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@gemtalksystems.com To: gemstone-smalltalk@lists.gemtalksystems.com Subject: Re: [GemStone-Smalltalk] netldid Message-ID: 7f994942-644d-4801-806e-a3c3f419962e@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: <blockquote type="cite">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@lists.gemtalksystems.com https://lists.gemtalksystems.com/mailman/listinfo/gemstone-smalltalk </blockquote> -------------- 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@proton.me To: James Foster Smalltalk@JGFoster.net Cc: "gemstone-smalltalk@lists.gemtalksystems.com" gemstone-smalltalk@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@JGFoster.net wrote: <blockquote type="cite">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 <blockquote type="cite">On May 26, 2025, at 12:33?PM, Ian via GemStone-Smalltalk gemstone-smalltalk@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@lists.gemtalksystems.com https://lists.gemtalksystems.com/mailman/listinfo/gemstone-smalltalk </blockquote></blockquote> -------------- 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@lists.gemtalksystems.com https://lists.gemtalksystems.com/mailman/listinfo/gemstone-smalltalk ------------------------------ End of GemStone-Smalltalk Digest, Vol 129, Issue 4 ************************************************** </blockquote>_______________________________________________ GemStone-Smalltalk mailing list GemStone-Smalltalk@lists.gemtalksystems.com https://lists.gemtalksystems.com/mailman/listinfo/gemstone-smalltalk </div></div></blockquote></div> </div></body></html>