> > On 6/13/2023 3:46 PM, Jerry Malcolm wrote: >> >> On 6/13/2023 12:39 PM, Jerry Malcolm wrote: >>> Rob, >>> >>> 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. >
Maybe you could report this as a bug in the affected JVM? If it's really coming from the JVM then it would be nice to have it fixed. Regards, Simon --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
