Hi folks,
I’m recently making my way back to GemStone after many years away. As James Foster has suggested, it wasn’t difficult to get GemStone working in docker but I thought I’d provide a resource for people who are interested: So far I find it quite nice to have a “GemStone” appliance. I’d like to put the gemstone docker image on docker hub but I’ll need to confer with GemTalk first. I tried to provide some “help” text in the repository Readme but I’m just getting re-acquainted with GemStone so it is likely to take a while before I can provide more useful advice (back-ups and other important system admin chores are completely missing from my description). I’m running an AWS ECS instance with GemStone now and plan to provide instructions for getting started on that platform as soon as I’m sure my database is stable. Comments, corrections and criticisms are always welcome! Best, David _______________________________________________ GemStone-Smalltalk mailing list [hidden email] https://lists.gemtalksystems.com/mailman/listinfo/gemstone-smalltalk |
Hi David,
Nice to see some work on GemStone in Docker! See below…
While I’m happy to discuss any specific concerns privately, I’ll say that you may redistribute GemStone subject to the following conditions:
Beyond that, we welcome efforts to make GemStone easier to deploy. Does that seem reasonable?
_______________________________________________ GemStone-Smalltalk mailing list [hidden email] https://lists.gemtalksystems.com/mailman/listinfo/gemstone-smalltalk |
Sounds good: Let me know if you would like any changes to the verbiage. The only key files in this image are the ones included in the GemStone zip file. Comments, questions and contributions are welcomed. I’m curious how GemStone handles the “exit by crashing” approach that is typical of docker containers. Will it try to replay transaction logs when it starts back up? BTW, it isn’t clear in the docker documentation what happens to processes in a container when it’s “main process” terminates. In the case of my gemstone container, the “main process” is just a sleep command. Maybe it would be better to run the stone in the foreground (is that possible) so that docker will send it SIGKILL and it can deal with a proper shutdown? David
_______________________________________________ GemStone-Smalltalk mailing list [hidden email] https://lists.gemtalksystems.com/mailman/listinfo/gemstone-smalltalk |
Hi David,
Yes, the process of opening the repository (extents) at startup looks to see if the repository had a clean shutdown. If not, then it looks for transaction logs that follow the most recent checkpoint and applies those logs. Of course, this assumes that the repository and transaction logs are external to the container!
Yes, see page 371 of the System Administration Guide for 3.5 for a description of ’stoned’, the ‘daemon’ process that represents the stone. It has all the same arguments as ’startstone’ but does not return until after a shutdown (startstone returns after the startup is complete). What I don’t remember is whether the stone will shutdown when it gets a SIGKILL. I think that a clean shutdown requires execution of Smalltalk code by a user with appropriate privileges (as is done by the stopstone script), so likely not.
_______________________________________________ GemStone-Smalltalk mailing list [hidden email] https://lists.gemtalksystems.com/mailman/listinfo/gemstone-smalltalk |
Free forum by Nabble | Edit this page |