> 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.


To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Reply via email to