We are experiencing a problem with our Jenkins CI server.
Our CI implementation relies on several Groovy scripts, which we execute in Jenkins as "System Groovy scripts". This has been this way for years, and the scripts have undergone no recent modifications, and implement build flows, business logic steps such as version checking, etc.
Yesterday we started experiencing an exception in every Jenkins job that we tried to lauch that, one way or another, tried to execute Groovy scripts. The exception is:
java.lang.StackOverflowError
at org.codehaus.groovy.antlr.parser.GroovyRecognizer.additiveExpression(GroovyRecognizer.java:12478)
at org.codehaus.groovy.antlr.parser.GroovyRecognizer.shiftExpression(GroovyRecognizer.java:9695)
at org.codehaus.groovy.antlr.parser.GroovyRecognizer.relationalExpression(GroovyRecognizer.java:12383)
at org.codehaus.groovy.antlr.parser.GroovyRecognizer.equalityExpression(GroovyRecognizer.java:12307)
at org.codehaus.groovy.antlr.parser.GroovyRecognizer.regexExpression(GroovyRecognizer.java:12255)
at org.codehaus.groovy.antlr.parser.GroovyRecognizer.andExpression(GroovyRecognizer.java:12223)
at org.codehaus.groovy.antlr.parser.GroovyRecognizer.exclusiveOrExpression(GroovyRecognizer.java:12191)
hundreds of similar lines
at org.codehaus.groovy.antlr.parser.GroovyRecognizer.compoundStatement(GroovyRecognizer.java:7510)
at org.codehaus.groovy.antlr.parser.GroovyRecognizer.compatibleBodyStatement(GroovyRecognizer.java:8834)
at org.codehaus.groovy.antlr.parser.GroovyRecognizer.statement(GroovyRecognizer.java:899)
at org.codehaus.groovy.antlr.parser.GroovyRecognizer.compilationUnit(GroovyRecognizer.java:757)
at org.codehaus.groovy.antlr.AntlrParserPlugin.transformCSTIntoAST(AntlrParserPlugin.java:131)
at org.codehaus.groovy.antlr.AntlrParserPlugin.parseCST(AntlrParserPlugin.java:108)
at org.codehaus.groovy.control.SourceUnit.parse(SourceUnit.java:236)
at org.codehaus.groovy.control.CompilationUnit$1.call(CompilationUnit.java:161)
at org.codehaus.groovy.control.CompilationUnit.applyToSourceUnits(CompilationUnit.java:846)
at org.codehaus.groovy.control.CompilationUnit.doPhaseOperation(CompilationUnit.java:550)
at org.codehaus.groovy.control.CompilationUnit.processPhaseOperations(CompilationUnit.java:526)
at org.codehaus.groovy.control.CompilationUnit.compile(CompilationUnit.java:503)
at groovy.lang.GroovyClassLoader.doParseClass(GroovyClassLoader.java:302)
at groovy.lang.GroovyClassLoader.parseClass(GroovyClassLoader.java:281)
at groovy.lang.GroovyShell.parseClass(GroovyShell.java:731)
at groovy.lang.GroovyShell.parse(GroovyShell.java:743)
at groovy.lang.GroovyShell.parse(GroovyShell.java:770)
at groovy.lang.GroovyShell.parse(GroovyShell.java:761)
at groovy.lang.GroovyShell$parse.call(Unknown Source)
at com.cloudbees.plugins.flow.FlowDSL.executeFlowScript(FlowDSL.groovy:80)
at com.cloudbees.plugins.flow.FlowRun$FlyweightTaskRunnerImpl.run(FlowRun.java:219)
at hudson.model.Run.execute(Run.java:1759)
at com.cloudbees.plugins.flow.FlowRun.run(FlowRun.java:155)
at hudson.model.ResourceController.execute(ResourceController.java:89)
at hudson.model.Executor.run(Executor.java:240)
at hudson.model.OneOffExecutor.run(OneOffExecutor.java:43)
This looks like that the Groovy parser inside Jenkins is reaching the top of the stack while trying to parse the groovy script (as I have said, this abruptly started to happen with many scripts that worked perfectly before and had undergone no recent modification).
Currently our Jenkins installation (v1.594) runs on a Websphere 8.5.5.2 application server on AIX v7.1 (don't know exactly the fix pack level and / or if it has recently suffered any kind of update, still trying to gather the info).
After a restart, we returned to normal behavior (all the scripts were working as usual again without any modification to them).
Does anyone know about some incompatibility of any underlying library with Jenkins Groovy parsing?
There is a problem with the groovy code; causing the parser to go nuts:
java.lang.StackOverflowError
at org.codehaus.groovy.antlr.parser.GroovyRecognizer.additiveExpression(GroovyRecognizer.java:12478)
Based on a similar ticket:
https://issues.apache.org/jira/browse/GROOVY-1783,
it is possible that your code has circular references; or creating too many functions on the fly. You can take the approach of analyzing your code and trying to put anything that is going to make allocations outside of loops; in particular complex inline functions.
Another approach is to go look at the Build Flow plugin and scroll down the documentation and see how you could write an extension point rather than use groovy. This may not be easy to do and requires effort; but you can write a lot of tests for your code that way. You would still use groovy for the glue; but use java directly for the hot spots.
A third approach would be to file a ticket on the Groovy issue tracker; and see what the experts find out.
Related
We rely heavily on logic in our Junit runner and currently call into it with mvn test
The logic mainly consists of
Instantiating a RuntimeHook and binding it to Runner.Builder().hook if an appropriate JVM switch is specified on the command line.
Calling Runner.Builder().clientFactory() with a mock, again if an appropriate JVM switch is specified on the command line.
Last setting minor things like Runner.Builder().tags and Runner.Builder().path
All of this works perfect today. Our main gripe however is Maven is slow.
Is there a way to accomplish the above logic and run without the expensive build time of Maven?
Since you are mixing a bit of Java code, I think you are going to depend on Maven for build + dependencies. That said, there are ways to ask Maven to dump all JAR dependencies into a text file. For example:
mvn dependency:build-classpath -Dmdep.includeScope=test -Dmdep.outputFile=classpath.txt
And then you may be able to shape a command that uses the java binary directly and you probably already know that com.intuit.karate.Main supports all the extension things. The bad news is I don't think we support things like the custom HTTP Client yet, you can see this PR where someone did this for the RuntimeHook. Perhaps you can contribute. Or maybe you have logic in Java code anyway, so calling the Karate Runner directly may be the way to go.
I think maybe the solution you will land on is mvnd - I haven't used it yet, but I'm hearing very good things on Twitter from some experienced Java folks I follow.
I'm trying to do some crawling with Nutch and I'd like to test out Cassandra as a backend, however using the latest version of nutch and its dependencies Cassandra throws a variety of errors as you move through the inject, generate, fetch, etc. process.
The errors are all related to actual problems in code, not out of memory or configuration. I've fixed some of them by modifying code within gora-cassandra, but it's still not functional.
My question is, does a working version of these 2 projects exist? By working i mean you can run through inject, generate, fech, parse, updatedb on at least a small set of urls, without error.
Here's an example of one of the classes giving an error during fetch:
java.lang.NullPointerException
at org.apache.gora.cassandra.query.CassandraSuperColumn.getUnionIndex
I have used HBase as the backend and that just works, although HBase itself is a monster to manage so that's why i'd like to test out Cassandra. However, i'm about to give up on this as I don't think I should be having to modify gora-cassandra code just to get a basic example to run.
Thanks
According to this link it's just broken, which is about 3 months old http://lucene.472066.n3.nabble.com/Re-user-Digest-3-Jun-2017-19-27-20-0000-Issue-2758-td4339060.html
Its unclear why backends that do not work are even documented.
HBase is most widely used, followed by MongoDB... on the other end of
the spectrum, Cassandra is least used and broken. It has not been
maintained for quite some time... and yes this is reflected by use of
Super Columns. We are currently re-writing the backend as part of a
GSoC project.
I would agree with the guy making the original statement, Its unclear why backends that do not work are even documented.
Really tired of this project and its lack usable documentation.
Are there any tools/libraries like Guard (for Ruby on Rails) for Java which listen to file system changes i.e. changes to the code files in the project and automatically run unit tests associated with that class or the entire project.
Looks like you need something like Jenkins, running locally + FSTrigger plugin.
But if you need to monitor file system changes from your app (Guard is general-purpose tool), there is discussions on Stackoverflow about it:
Is there a sophisticated file system monitor for Java which is freeware or open source?
File changed listener in Java
How to detect filesystem has changed in java
The interesting thing is that yes, Guard.rb does support java thanks to the guard-java gem. Best thing of all is that this does support maven, ant, or what ever your build system is. This allows for setting up jenkins and cucumber then having guard run your tests as you edit the features/source code.
Add the following to your project's Gemfile:
gem 'guard-java'
Then issue bundler install && guard init java
The rest can be read at https://github.com/infospace/guard-java
I don't know if you are still up for an answer but I wrote a small tool, inspired from Guard, that could do what you want:
https://github.com/athieriot/JTaches
It uses the Watcher API available in Java7
Hope it helps
This question came to me when developing using Eclipse.
I use JBoss Application Server and use hot code replacement. But this option requires that the 'build automatically' option to be enabled. This makes Eclipse build the workspace automatically (periodically or when a file is saved?) and for a large code base this takes too much time and processing which makes the machine freeze for a while. Also sometimes an error message is shown saying that hot code replacement failed.
The question that I have is: is there a better way to see the result of a code change?
Currently I have the following two suggestions:
Have unit tests - this will allow to run a single test and see the result of a code change. ( But for a JavaEE application that uses EJBs is it easy to setup unit tests?)
Use OSGi - which allows to add jars to the running system without bringing down the JVM.
Any ideas on above suggestions or any other suggestion or a framework that allows to do this is welcome.
Did you take a look at http://zeroturnaround.com/jrebel/?
I tell you how I work. I hope it is useful. First of all, I disable "Build Automatically". Maybe it is better if you do a simple ANT script to compile and see errors/exceptions. Also, I make jar file with the same script. Afterwards, I use OSGi to check the application. Yo do not need to stop server, only you need to change versions in deployed bundles. Intead of JBoss Server I use Equinox which includes Jetty Web Server.
May you have a nice day!
With JRebel, you wouldn't have to build your project (skip the build totally). Plus, only the changed resources will be reloaded so the update happens instantly. Plus, session is preserved so you do not have re-login to the application after the update was performed.
Even though the question I asked was quite specific to Java, I thought that mentioning using an interpreted programming language that avoids the compilation step is anther way of seeing result of a code change faster.
At work, I use a Java application (I have located compiled/executable jars on the C-drive). I want to be able to grab some information from this application through code. The application itself probably does not store information, so it must communicate with legacy systems some way, I am not sure how, I have seen traces of a Servlet(?) Hence, I suspect the application also has built-in "encryption"(?)
I do not want to get involved in encryption and login procedures etc., so I am thinking I could just build a Java project around the current executable jars, and launch the application as I usually do (through the "main" entry point, "Start.jar", but then after execution call the functions that I want to (i.e. the application just runs as usual in the background)...
Would that be possible? Is there another way? Can one, for example, hook up to an already executed Java application and issue commands?
What I have tried so far
Downloaded Eclipse, and created a new project
Made Eclipse "reference" external jars (there was a wizard in Eclipse)
Created a new class in my new project, in which I launch the "main" entry point of the "main" executable jar (the structure of all the jars pops up with "IntelliSense"). I have also found out which argument I need to supply to the main procedure using JD-GUI (Java Decompiler)...
It seems that from inside the main procedure a call is made to another procedure, which resides in a different jar, in the debug window of Eclipse I just see an error, which made me doubt that my current approach is viable... Maybe the problem arises because the command is issued from a compiled jar? Could there be an issue with the "class path"? Does this at all seem like a solution? But then again, I have no experience with Java (mostly VBA and some C#).
You can start your JVM for the application with options, which enable remote debugging. Then you can connect the eclipse debugger to this JVM.
http://www.eclipsezone.com/eclipse/forums/t53459.html
Based on your question, I am going to guess that your application does not have a Java API you can code against. That would, of course, be the easiest way. So, if you have not checked, do that first.
Assuming you don't have an API to code against, I think your approach is correct. But it could be hard to do, since you are basically flying blind trying to figure out what the application is doing. Remote debugging might solve part of that problem.
There might be a slightly easier solution, if you are sure it is sending requests across the network. You can use a tool like Wireshark to see what it is creating. Then, you can have your application create requests that look like that and send them to that destination. This assumes of course that the requests aren't encrypted. In that case you are probably out of luck.