-
30. Re: Startup Goes Very Slow with Scanning Entity Classes from Different Jars
hardy.ferentschik Apr 10, 2012 4:30 PM (in response to hardy.ferentschik)As an additional factor to tweak you can create a validation.xml and add it to the META-INF directory of your deployment. The content should be something along these lines:
<validation-config xmlns="http://jboss.org/xml/ns/javax/validation/configuration"
xsi:schemaLocation="http://jboss.org/xml/ns/javax/validation/configuration validation-configuration-1.0.xsd"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
...
<property name="hibernate.validator.metadata_cache.hard_ref_limit">10</property>
<property name="hibernate.validator.metadata_cache.soft_ref_limit">100</property>
</validation-config>
The two Hibernate Validator specific properties are new in HV 4.3.0.Beta1 and allow to explcitly set the cache size for constraint meta data. See also SoftLimitMRUCache.
-
31. Re: Startup Goes Very Slow with Scanning Entity Classes from Different Jars
fabdouglas Apr 10, 2012 6:15 PM (in response to hardy.ferentschik)@Scott
The version numbers I was talking about are relating to HibernateValidator.
The outof memory for me :
Caused by: java.lang.OutOfMemoryError: PermGen space
at java.lang.ClassLoader.defineClass1(Native Method)
at java.lang.ClassLoader.defineClassCond(ClassLoader.java:631)
at java.lang.ClassLoader.defineClass(ClassLoader.java:615)
at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:141)
at java.net.URLClassLoader.defineClass(URLClassLoader.java:283)
at java.net.URLClassLoader.access$000(URLClassLoader.java:58)
at java.net.URLClassLoader$1.run(URLClassLoader.java:197)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.findClass(URLClassLoader.java:190)
at java.lang.ClassLoader.loadClass(ClassLoader.java:306)
at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:301)
at java.lang.ClassLoader.loadClass(ClassLoader.java:247)
at org.hibernate.validator.HibernateValidator.buildValidatorFactory(HibernateValidator.java:45)
at org.hibernate.validator.engine.ConfigurationImpl.buildValidatorFactory(ConfigurationImpl.java:170)
at javax.validation.Validation.buildDefaultValidatorFactory(Validation.java:111)
-
32. Re: Startup Goes Very Slow with Scanning Entity Classes from Different Jars
smarlow Apr 10, 2012 10:44 PM (in response to fabdouglas)Fabrice,
I know that your still trying to catch up to all of our questions (e.g. whether the above *ref_limit" properties help) but I would like to add one more question. How many persistence units are in your application? How many entities are in the application (an estimate is fine)? How many validation constraints are in the application (an estimate is fine)?
Do you always get the permgen out of memory? The java option "-XX:MaxPermSize=NNN" could increase the permgen region to allow more classes to be defined but we should look for a better solution.
Scott
-
33. Re: Startup Goes Very Slow with Scanning Entity Classes from Different Jars
ablet Apr 11, 2012 4:12 AM (in response to hardy.ferentschik)Hardy, There are more than 500 entities with constraints there, and the issue is seen when the application is deploying with fresh restarting of AS (without hot deployment).
-
34. Re: Startup Goes Very Slow with Scanning Entity Classes from Different Jars
fabdouglas Apr 11, 2012 5:35 AM (in response to ablet)I did a very basic test case to reproduce this issue :
- One PU
- One contrained entity with few basic constraints : NotEmpty, NotNull, Min, Max, and one custom constraint @UpperCase :
@Target({ ElementType.METHOD, ElementType.FIELD, ElementType.ANNOTATION_TYPE })
@Retention(RetentionPolicy.RUNTIME)
@Constraint(validatedBy = UpperCaseValidator.class)
public @interface UpperCase {
String message() default "{com.toyota.a2d.validation.UpperCase.message}";
Class<?>[] groups() default { };
Class<? extends Payload>[] payload() default { };
}
package com.toyota.a2d.validation;
import javax.validation.ConstraintValidator;
import javax.validation.ConstraintValidatorContext;
import org.apache.commons.lang3.StringUtils;
/**
* Simple validator checking the text is fully capitalized.
*/
public class UpperCaseValidator implements ConstraintValidator<UpperCase, String> {
@Override
public void initialize(final UpperCase upperCase) {
// Nothing to initialize
}
@Override
public boolean isValid(final String value, final ConstraintValidatorContext context) {
return value == null || StringUtils.isAllUpperCase(value);
}
}
-
35. Re: Startup Goes Very Slow with Scanning Entity Classes from Different Jars
hardy.ferentschik Apr 11, 2012 8:48 AM (in response to ablet)Hi Mostafa,
I guess it is just a big system (you mentioned once 80 modules, 500 entities, validation, etc, etc). Personally looking back at your JVM memor options:
set "JAVA_OPTS=-Xms512M -Xmx1384M -XX:PermSize=128M -XX:MaxPermSize=128M
I just feel they are ways low. Have you tried going over 2GB in heap size and also increase perm size? I know you said you experimented with the settings, but how far did you go?
-
36. Re: Startup Goes Very Slow with Scanning Entity Classes from Different Jars
hardy.ferentschik Apr 11, 2012 8:54 AM (in response to fabdouglas)Hi Fabrice,
regarding your testcase, is that it? One entity with a couple of constraints? I think there must be more to it. We have many test cases which execute much more complicated setups, including integration tests. What are you actually building a web application or a era file? Since you are saying that it works in jetty I am assuming you are building a war file. If deployed to Jetty it works, right? Where exactly do things blow up then?
-
37. Re: Startup Goes Very Slow with Scanning Entity Classes from Different Jars
smarlow Apr 11, 2012 9:06 AM (in response to hardy.ferentschik)Hardy,
Regarding Mostafa's use case. I'm wondering, for the multiple PUs, multiple entities with multiple validation rules, how much it would help if we had one HV instance per deployment instead of a HV instance per persistence unit.
Regarding Fabrice's use case. I'd like to see the simple test case attached, so we can deploy it and experience the permgen oom also.
Fabrice,
Please attach your test archive if you can, so we can deploy it.
Scott
-
38. Re: Startup Goes Very Slow with Scanning Entity Classes from Different Jars
fabdouglas Apr 11, 2012 9:12 AM (in response to hardy.ferentschik)Yes, I was a bit surprised too.
Everythings work on Server (Tomcat and Jetty), in Eclipse, from a Main too.
The issue occurs only during Maven test. I've also been able to produce the issue on my computer (outside my Continuous Integration server) with a simple "maven test"
The important fact, is that some JARS are including with test scope, and in my case, there are many : jdbc driver, mock, junit,...
I guess one / several / all of them are parsed by the classloader there :
DefaultValidationProviderResolver#getValidationProviders() {
....
Enumeration<URL> providerDefinitions = classloader.getResources( SERVICES_FILE );
...
}
I think my problem is not the same as Mostafa since the metadata cache (in my case) would be limited to one bean.
I will do some additional tests.
-
39. Re: Startup Goes Very Slow with Scanning Entity Classes from Different Jars
smarlow Apr 11, 2012 9:15 AM (in response to fabdouglas)Fabrice,
You probably are just drifting over the "max number of classes allowed" for your current MaxPermSize setting. You probably need to increase the MaxPermSize setting for whichever jvm is getting the permgen oom error.
-
40. Re: Startup Goes Very Slow with Scanning Entity Classes from Different Jars
fabdouglas Apr 11, 2012 10:14 AM (in response to smarlow)Indeed I've increased the MaxPermSize to fix this. But this project is very small regarding the others managed by my shared CI configuration (surefire, etc.).
So I'm wondering if this issue will not be "un-workaroundable" by increasing perggen limits when I'll get a biggest collection of constraints. I seems that the metadata cache would set a limit... i hope.
-
41. Re: Startup Goes Very Slow with Scanning Entity Classes from Different Jars
smarlow Apr 11, 2012 12:08 PM (in response to ablet)AS7-4470 might help with this issue when its addressed (the idea being that you could share a hibernate validator factory between the different persistence units once its addressed). A workaround might be to use just one persistence unit for the application.
Scott