I've used Post Patch Actions in the past, would need to check if they have a valid PrgCtx, or I do it on first call of the function by the user.
I've certainly updated my code base to immediately exit if no prgCtx is found. However, I still want to establish where I can safely call it. I've sent back inquiries as to where the db start up is in the Kubernetes cluster.
-Hugh
If you have your own module, rather than a patch, you could try adding a __DelayedInit( object prgCtx ) method instead of __Init(). It should register and run with a valid prgCtx after __Init() as it needs to wait for a valid DB connection.
Where does the __DelayedInit get called? We have our own __InitLater subsystem used for applying overrides but it is called after $LLPatch.Patch has done its thing.
Everything that goes into __DelayedInit() is registered in $KERNEL.fDelayedInitObjects and is called by RunDelayedInit(), in KERNEL, which is in turn called in llweb_startup.lxe.
A quick peek at the file tells me it runs after init, but before any patching. :-)
Interesting.....so it would seem our __InitLater is called even after DelayedInit. The DelayedInit does at least check that it was successful at getting a prgCtx, and exits if it cannot.
Given that the errors we saw were that a prgCtx could not be retrieved even after the DelayedInit and the patching was done indicates that in this system, Content Server may be starting without being able to connect to the database right away.
Chatting with DT, it seems that the best solution is to use LLIAPI.StartupInitialization - i.e. orphan at least one object from that into the module and do whatever thread startup we need to do there. From what I've seen, those get called definitely after the patching and before the system is ready for users, so this is probably the right place. Plus the whole subsystem doesn't get called if you don't have a db connection. The only thing is that I seem to be unable to set a breakpoint on it - I've tried in both my Windows and Linux sandboxes.
