> Jerry, > > 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: >>>> 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. > > 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. > > -chris
I was asking this before and ask again, how do we know it's not a missing RNG entropy while the crypto stuff of the Java VM is initialised? Simon --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
