Zitat von Martijn Brinkers <[email protected]>:
On 12/05/2012 06:03 PM, [email protected] wrote:Zitat von Martijn Brinkers <[email protected]>:On 12/05/2012 05:44 PM, [email protected] wrote:Is it possible that it is related to the CRL downloading. Most of the time we have something like this nearby: 05 Dez 2012 17:34:23 | WARN IO Exception downloading CRL. URI: ldap://ldap.sbca.telesec.de/CN=Deutsche%20Telekom%20Root%20CA%202,OU=T-TeleSec%20Trust%20Center,O=Deutsche%20Telekom%20AG,C=DE?AuthorityRevocationList. Message: javax.naming.NamingException: LDAP response read timed out, timeout used:120000ms. (mitm.common.security.crl.CRLStoreUpdaterImpl) [CRL Updater thread]Downloading of CRLs are done on a separate thread. The only think I can think of is that downloading the CRL somehow uses all the CPU for some time although that should not happen since all threads have the same priority. Do you have the certificate that contains that CRL distribution point so I can test whether I can download the CRL? Kind regards, MartijnThere is more than one with crappy CRL download URL. I will try to pick them and send you in private mail. There is obviously something wrong with the CRLs anyway: /var/log/old/james.wrapper.log.1:Exception in thread "CRL Updater thread" java.lang.OutOfMemoryError: GC overhead limit exceeded /var/log/old/james.wrapper.log.1:Exception in thread "CRL Updater thread" java.lang.OutOfMemoryError: Java heap space /var/log/old/james.wrapper.log.1:Exception in thread "CRL Updater thread" java.lang.OutOfMemoryError: Java heap space /var/log/old/james.wrapper.log.1:Exception in thread "CRL Updater thread" java.lang.OutOfMemoryError: Java heap space /var/log/old/james.wrapper.log.1:Exception in thread "CRL Updater thread" java.lang.OutOfMemoryError: Java heap space /var/log/old/james.wrapper.log.1:Exception in thread "CRL Updater thread" java.lang.OutOfMemoryError: Java heap space /var/log/old/james.wrapper.log.1:Exception in thread "CRL Updater thread" java.lang.OutOfMemoryError: Java heap space /var/log/old/james.wrapper.log.2.gz:Exception in thread "CRL Updater thread" java.lang.OutOfMemoryError: GC overhead limit exceeded /var/log/old/james.wrapper.log.2.gz:Exception in thread "CRL Updater thread" java.lang.OutOfMemoryError: Java heap space /var/log/old/james.wrapper.log.2.gz:Exception in thread "CRL Updater thread" java.lang.OutOfMemoryError: GC overhead limit exceeded /var/log/old/james.wrapper.log.3.gz:Exception in thread "CRL Updater thread" java.lang.OutOfMemoryError: Java heap space /var/log/old/james.wrapper.log.3.gz:Exception in thread "CRL Updater thread" java.lang.OutOfMemoryError: Java heap space /var/log/old/james.wrapper.log.3.gz:Exception in thread "CRL Updater thread" java.lang.OutOfMemoryError: Java heap space /var/log/old/james.wrapper.log.4.gz:Exception in thread "CRL Updater thread" java.lang.OutOfMemoryError: Java heap space /var/log/old/james.wrapper.log.4.gz:Exception in thread "CRL Updater thread" java.lang.OutOfMemoryError: Java heap space I have now raised the Memory Limit in wrapper.conf from 512MB to 700MB to see if this fixes at least the OutOfMemory :-( And yes, one CPU is at 100% load for the time of CRL updates but at least we have two of them :-)That might explain it. Unfortunately CRLs can be large and memory consuming. I think 512 MB is too low for some large CRLs. For the Virtual Appliance I have enabled "dynamic memory allocation" which uses more memory if the system is configured with more memory. It's really simple but effective (see /etc/default/djigzo). This is not enabled by default since djigzo might be installed on systems that run other things as well. >java.lang.OutOfMemoryError: GC overhead limit exceeded This is a warning from the JVM that the system spends more time on garbage collection then some max value. I think that the system is then restarted. Somehow you have a CA with a very large CRL. The system sets a max size of a downloaded CRL (see djigzo.properties parameter: system.cRLDownloadParameters.maxBytes). You can lower this value, but then it might be that a CRL is no longer downloaded since it's too big. I'll need to spend time refactoring the CRL part. The problem is that Java tries to load the CRL in memory which can take a lot of memory. The thing I have been thinking of for some time is to make a database backed CRL. But this is not trivial to do. Can you see which CRL is giving you grieve? Kind regards, Martijn
I don't know how to quickly find out the size of the CRLs. I can provide you a sample list with all CAs for which CRL trouble is listed. What about CRLs from non-root CAs??
Regards Andreas
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ Users mailing list [email protected] http://lists.djigzo.com/lists/listinfo/users
