On 6/15/23 00:41, Jerry Malcolm wrote:

On 6/13/2023 3:46 PM, Jerry Malcolm wrote:

On 6/13/2023 12:39 PM, Jerry Malcolm wrote:

On 6/13/2023 11:34 AM, Rob Sargent wrote:
In /etc/rc.local I have:

sleep 120s
systemctl start tomcat9


I put the sleep in back a couple of years ago that for some reason 'fixed' this same random, intermittent crypto file exception.

One observation.... even though the error doesn't show up in the log until my first db call, I think the real error has to be occurring during tomcat boot.  If the failure occurs, I continue to get the same "Can't read cryptographic policy directory: unlimited" even hours later after boot every time I send another request to TC.  If I then reboot TC and this time I don't get the failure, that unlimited folder magically becomes available.  There is something happening in TC boot with some sort of crypto initialization that either succeeds or fails.  And the exception when trying to get connections long after TC boot is just hitting whatever problem occurred during boot.  In other words, delaying my calls, even for hours, has no effect on accessing that folder if the problem is present.  Rebooting TC gives it another chance to succeed or fail. Any ideas what TC could be doing on boot that could lock up that folder?

I never really found a definitive fix for this.  But after all of the research and logging and everything, I pretty much concluded that there's some kind of timing/race condition between Tomcat boot and Java crypto initialization.  Given that, I figured it was highly unlikely that two different Java JVM implementations would have the same precise implementation code to trigger that race condition.  So as a last ditch effort, I replaced my OpenJDK JVM for Tomcat with Amazon's Corretto Java JVM.  It's circumstantial evidence at best, and running a production environment on fixes that just went away goes against my grain. But if the problem goes away, maybe it won't come back. At this time, when using Corretto JVM, I have not encountered the Crypto directory error. It's been running on all server instances now for almost 24 hours with no problems.  So I guess my suggestion to anyone else that might encounter something like this, trying using a different JVM from a different provider.  That appears at this time to have worked for me.

Yeah, that's certainly a very unsatisfying result, but ... you can't argue with results. I'd love to hear if you end up with any further information.


To unsubscribe, e-mail:
For additional commands, e-mail:

Reply via email to