Absolutey stumped on this.
I have two controller integration tests that pass successfully. However, when running in Intellij or via gradle check, the JVM never exits. If I comment out the entire integration tests, the JVM exits cleanly.
When debugging any of the integration tests, I can hit pause and see that there are several threads in different states: WAITING, RUNNING, SLEEPING.
The database used in application.yml is purely an in-memory one:
url: jdbc:h2:mem:testDb;MVCC=TRUE;LOCK_TIMEOUT=10000;DB_CLOSE_ON_EXIT=FALSE
Changing this to file based does not fix the problem. Changing DB_CLOSE_ON_EXIT=TRUE does not help either.
I've tried removing #Rollback and even using #Transactional with a timeout, but that doesn't fix it.
Creating an integration test on a fresh project works with no deadlock/hanging/waiting.
I have moved back through revisions to find the changeset where this behaviour started, but the changes were purely in GSPs, Controllers and an additional assertion & test method in one of the integration tests.
The last lines in the logs are:
INFO org.springframework.boot.context.embedded.AnnotationConfigEmbeddedWebApplicationContext - Closing org.springframework.boot.context.embedded.AnnotationConfigEmbeddedWebApplicationContext#73386d72: startup date [Mon May 30 18:48:25 BST 2016]; root of context hierarchy
INFO org.springframework.context.support.DefaultLifecycleProcessor - Stopping beans in phase -2147483648
INFO org.grails.plugins.datasource.TomcatJDBCPoolMBeanExporter - Unregistering JMX-exposed beans on shutdown
INFO org.grails.plugins.datasource.TomcatJDBCPoolMBeanExporter - Unregistering JMX-exposed beans
INFO org.hibernate.tool.hbm2ddl.SchemaExport - HHH000227: Running hbm2ddl schema export
INFO org.hibernate.tool.hbm2ddl.SchemaExport - HHH000230: Schema export complete
I've tried cutting the integration test methods down to one method and the issue still occurs.
The versions I'm using are:
$ ~/apps/grails-3.1.5/bin/grails --version
|Grails Version: 3.1.5
|Groovy Version: 2.4.6
|JVM Version: 1.8.0_92
Windows 10 64bit.
Here's a thread dump.
I have no idea how to debug this further. Any ideas?
I would turn on debug level logging. Also, if you can, I would upgrade grails to something post 3.1.9. (3.1.11 is current as I write this.)
Right around grails v3.1.5 there were configuration inconsistencies between Grails and Hibernate. The grails team was quickly upgrading several interfaces, and they got through it quickly.
The result was that you didn't end up running the configuration that you thought you were. It also affected cache and transaction management.
At the time, I had to create redundant configs to make sure Grails was getting configs at one level, hibernate at another. You don't have to do this anymore, but at the time, I had to use a config like the one listed here.
To find the problem, I turned on debug logging for grails and hibernate and all of my database drivers and waded all of the way through it.
This plugin also helps with the detailed monitoring info:
Related
I have Jest tests that are running against the dockerized Neo4j Database, and sometimes they fail on CircleCI. The error message for all 25+ of them is :
thrown: "Exceeded timeout of 5000 ms for a hook.
#*******api: Use jest.setTimeout(newTimeout) to increase the timeout value, if this is a long-running test."
Since they fail sometimes, like once in 25 runs, I am wondering if jest.setTimeout will solve the issue. I was able to fail them locally by setting jest.setTimeout(10), but I am not sure how to debug this even more, or whether something else could be an issue here aside from a small timeout (default 5000). I would understand if 1/25 or a few fails, or if all other suits fail, but only a single file with all tests within that file is failing. And it is always the same file, never some other file for this reason ever.
Additional information, locally, that single file runs in less than a 1000ms connected to the staging database which is huge compared to the dockerized that has only a few files at the time of running
For anyone who sees this, I was able to solve this by adding the --maxWorkers=2 flag to the test command in my CircleCI config. See here for details: https://support.circleci.com/hc/en-us/articles/360005442714-Your-test-tools-are-smart-and-that-s-a-problem-Learn-about-when-optimization-goes-wrong-
Naman's answer is perfect! I couldn't believe it but it really solved my problem. Just to be extra clear on how to do it:
I change the test script from my package.json from jest to jest --maxWorkers=2. Then I pushed and it did solve my error.
I am running Jenkins from source using mvn jenkins-dev:run. It seems to be logging at the DEBUG level making page load very slow. How do I change the log level of Jenkins. I have tried the usual util.logging properties file, but I can't get it working.
mvn jenkins-dev:run -Dorg.slf4j.simpleLogger.defaultLogLevel=error
Default log level for all instances of SimpleLogger. Must be one of ("trace", "debug", "info", "warn", or "error"). If not specified, defaults to "info".
You can also edit ${MAVEN_HOME}/conf/logging/simplelogger.properties to make it consistent.
More info here: http://maven.apache.org/maven-logging.html
EDIT:
To also control the log level of the Jenkins war itself as the OP wanted i was able to do so using:
mvn jenkins-dev:run -Djava.util.logging.config.file=my-logging.properties
The contents of my-logging.properties are:
handlers = java.util.logging.FileHandler, java.util.logging.ConsoleHandler
.level= SEVERE
Now i only see two INFO messages comming from jetty . One could also configure the jetty logger via the same file if needed, i will not go into more detail about how to do this because i have little experience with it, but if i could take a guess, you would have to manipulate the correct class (eg: org.eclipse.jetty.LEVEL=WARN) used by Jenkins when embedding jetty.
Newbie Question:
I've been required to deploy a grails app to jboss 5. I'm having a hell of a time figuring out how to take advantage of the grails jbossas plugin. I've followed the documentation as best as I know how, but I get the same exceptions just as if the plugin was never there.
Here's the documentation i've been following:
http://grails-plugins.github.com/grails-jbossas/docs/manual/guide/2%20Usage.html
I've added the plugin to the BuildConfig.groovy plugin{} closure. I then called grails war. Nothing happens and my war deploy bombs out.
Could somebody give a newbie a little hand holding to get this plugin to work? Unfortunately, I'm finding the documentation to be wanting in the regard of actually telling you how to use it, or when the plugin will do its magic.
UPDATE:
My environment:
Mac OS X Lion Dev machine
Grails 2.0.3
JBoss 5.1.0 -- running a Liferay instance.
Burt, I've done the following:
grails generate-jboss-deploy 5
grails war.
scp the generated war file to the deploy-jboss directory on my remote server.
Dutifully, jboss picked up the new war and attempted to deploy it. I'm getting the following (now dreaded) exception:
Caused by: java.lang.NoSuchMethodException: org.hibernate.validator.ClassValidator
Per the usage instructions, I've modified Datasource.groovy's hibernate configuration:
hibernate {
cache.use_second_level_cache = true
cache.use_query_cache = true
cache.region.factory_class = 'net.sf.ehcache.hibernate.EhCacheRegionFactory'
validator.apply_to_ddl = false
validator.autoregister_listeners = false
}
The only file that seems to have been modified or created by running the generate-jboss-delpoy 5 script is WEB-INF/jboss-web.xml. It's contents are:
<jboss-web>
<class-loading java2ClassLoadingCompliance="false">
<loader-repository>
sappi-label:loader=sappi-label.war
<loader-repository-config>java2ParentDelegation=false</loader-repository-config>
</loader-repository>
</class-loading>
</jboss-web>
I confirmed that the jboss-web.xml file is present in the generated war file (exploded, then checked the directory).
Burt: what files other than jboss-web.xml should have been altered?
UPDATE (Again):
I don't think there's anything wrong with the jbossas plugin. I've done more testing and see that the plugin is doing what it is supposed to do: remove jars, put in jboss-web.xml. I haven't been able to confirm that it modifies the hibernate config, but I assume it is. I think the problem lies within the server I'm attempting to deploy to, a Liferay instance.
regardless of what I'm doing I get an exception saying that slf4j was unable to load successfully. Nothing more, nothing less. I'll keep whacking away at the problem, but it is out of scope of my original question. Burt, thanks for your help. If you have any ideas about why slf4j vomits in a Liferay/jboss environment, please let me know.
Regards.
Thanks!
I guess I didn't make it clear that you need to run the generate-jboss-deploy script, passing in the major version of JBoss that you're using, so in your case generate-jboss-deploy 5. I've updated the docs to describe this.
If this doesn't help please update your question with some indication of what the errors that you're seeing are.
I have been using IntelliJ for almost a year ad I have always been really happy with it. However, yesterday I set it up on my new laptop (Ubuntu 11.04), and haven't seen the plugins module since.. :-(
Ran grails clean, tried to change the project structure/settings to include $HOME/.grails/1.3.x/projects/projectName/plugins, but still nothing. My understanding is that it should pick up the plugins automatically, am I right?
For the record, I am using Grails 1.3.4, IntelliJ IDEA Ultimate 9.0.4.
I'd strongly recommend switching to the latest Intellij version (10.5.1 as of now). Support for Grails has been improved a lot since 9.x. If you don't want to upgrade, check the following areas:
are all used classpath variables set correctly?
are you referencing the correct Grails version?
I'm using IntelliJ 11.1.3 with Grails 2.1.1.
General Issue:
The IDE Build/Make Project/Run Unit-tests sometimes fails to resolve classes referenced as dependencies within Plugins and produces 'no class...' errors. Normal grails targets (compile, run-app, test-app) work without issue!
Workaround:
Restarting IntelliJ 'magically' corrected my Plugin related 'no class...' errors.
What didn't work:
grails resolve-dependencies (makes sense because grails run-app worked fine!)
grails clean (again makes sense this is just purging the output)
Seems like the IDE Build/Make Project/Run Unit-tests uses a stale classpath in some circumstances. Unfortunately I don't have a repeatable test case but noticed that modifying BuildConfig and doing grails refresh-dependencies or compile or run-app doesn't make the IDE update it's list of grailsPlugins!
I've had IDEA do this once in a while to me as well. Even in the latest version (though I do agree you should upgrade, but 9->10 isn't free). For me, I just had to kill IDEA and restarted it.
IMPORTANT UPDATE! It will be fixed in 11.1.2! YEEAAAH!
In my case plugins not resolving because of custom system property 'grails.work.dir'. If your project using default 'grails.work.dir' than OK otherwise plugins won't be resolved. Tested on Idea 10.5.4, 11.1.1 and windows 7.
Because of memory constraint i am trying to build a grails app with smaller memory footprint. I build the war with this argument "--nojars". I created a war file without all the jar and when i deploy within the glassfish i encounter this error
Exception while loading the app : java.lang.Exception: java.lang.IllegalStateException: ContainerBase.addChild: start: org.apache.catalina.LifecycleException: java.lang.IllegalArgumentException: java.lang.ClassNotFoundException: org.codehaus.groovy.grails.web.util.Log4jConfigListener
It seems like the application fail to find where is the jar file.
I had already indicates the path to the library before deploying the application in glassfish.
did i miss out somethinng?
It is commonly recommended to use GlassFish's Common Classloader. That means putting the shared JARS into the $domain-dir/lib folder (but not into a subfolder of that).
You're probably trying to use the Application Classloader with the asadmin deploy --libraries command. This is more complicated and error-prone. If you don't need different versions of the same JARs with different web applications, you should definitely go for the Common Classloader as specified above.
Also see The Classloader Hierarchy for a reference.
EDIT Updated as per the questioner's comment:
The domain/domain1/lib folder definitely works (I've tested that). To validate that, put log4j.jar into that folder and add a test.jsp to domain1/applications/$applicationName, that just contains:
<% out.println(
org.apache.log4j.Logger.getLogger(this.getClass())); %>
If that works but your other code does not, there may be another point to consider: Are you using Log4J's Logger.getLogger(..) or Apache Commons' LogFactory.getInstance(..) in your code?
See the article Taxonomy of class loader problems encountered when using Jakarta Commons Logging for related issues. - I'd also like to advise you to post your complete stacktrace.