Threads sperren sich in java.security.SecureRandom.nextBytes, wodurch die AEM-Anwendung hängen bleibt:
java.lang.Thread.State: BLOCKED (on object monitor) at java.security.SecureRandom.nextBytes(SecureRandom.java:468) - waiting to lock <0x0000000744cb6070> (a java.security.SecureRandom) at org.bouncycastle.crypto.CipherKeyGenerator.generateKey(Unknown Source) at org.bouncycastle.jcajce.provider.symmetric.util.BaseKeyGenerator.engineGenerateKey(Unknown Source) at javax.crypto.KeyGenerator.generateKey(KeyGenerator.java:540)
Dies ist ein bekanntes Problem [1] in Linux-Systemen, bei dem /dev/random keine „Entropie“ mehr hat und das System Threads blockiert.
[1] https://bugs.java.com/view_bug.do?bug_id=6708214
Die einfachste Lösung ist die Installation von haveged auf dem Linux-Betriebssystem. Dieser Prozess stellt sicher, dass die /dev/random-Device mit genügend Randomness versorgt wird, um Leistungsprobleme zu vermeiden.
Auf Debian basierende Plattformen (Debian, Ubuntu):
sudo apt-get install rng-tools sudo update-rc.d haveged defaults
Auf Redhat Plattformen (RHEL, Fedora, CentOS):
sudo yum install rng-tools sudo chkconfig haveged on
Eine andere Lösung besteht darin, /dev/urandom anstelle von /dev/random zu verwenden. Allerdings hat dies den Nachteil, dass die Sicherheit aufgrund der geringeren Zufälligkeit eingeschränkt ist.
securerandom.source=file:/dev/random
auf
securerandom.source=file:/dev/urandom
Alternative Lösungen finden Sie hier.
Bei Ihrem Konto anmelden