Re: OutOfMemory on test import
See https://wiki.jenkins-ci.org/display/JENKINS/JUnit+Attachments+Plugin On Thu, Mar 8, 2012 at 10:33 PM, Sami Tikka sjti...@gmail.com wrote: I mean, put the test result in the junit xml file and test stdout into another file. Configure Jenkins to publish junit xml files as test results and archive the stdout files as build artifacts. It is a bit painful but if you are short on memory, this trick should help you. -- Sami 2012/3/7 Gaetan gae...@xeberon.net: What do you mean by store the logs as files that you archive ? Do you mean having two destination for logs, one for the data going into junit and the other into raw log files? I only have junit files. If the sum is huge it is because some contains lot of stdout to have data about the current tests. I can drop them (actually I parse my own proprietary test result files before generating the xml files), but that would be a mess to loose important information. Increasing the memory is not really an option, jenkins is running on a virtualized server with only 1024Mb of memory and the java is already swapping to disk ps shows : jenkins 28931 37.4 62.6 1358964 640248 ? Sl Mar05 1052:16 /usr/bin/java -jar /usr/share/jenkins/jenkins.war --webroot=/var/run/jenkins/war --httpPort=8080 --ajp13Port=-1 - Gaetan 2012/3/2 Sami Tikka sjti...@gmail.com If you want to save memory, store the logs as files that you archive as build artifacts. Storing large logs inline in the junit xml files will cost you a lot in memory. But if you have the memory, go for it. Sun JVM option -XmxNNG sets the heap to NN gigabytes. Run java -X to see what you can tune. How exactly you change it, depends on your platform and the way you start Jenkins. -- Sami 2012/3/2 Gaetan gae...@xeberon.net: Hello I'm starting to have a java heap error when parsing the junit tests. I have a bunch of 3000 tests that might have some long logs (the total size of junit files is around 200 Mb), but I hope jenkins is able to handle this). How can I increase the HEAP size of jenkins ? Or is there a way to fix this crash (in the futur, the results size will increase) ? 10:39:52 FATAL: Java heap space 10:39:52 java.lang.OutOfMemoryError: Java heap space 10:39:52 at java.util.Arrays.copyOfRange(Arrays.java:3221) 10:39:52 at java.lang.String.init(String.java:233) 10:39:52 at org.dom4j.io.SAXContentHandler.characters(SAXContentHandler.java:299) 10:39:52 at com.sun.org.apache.xerces.internal.parsers.AbstractSAXParser.characters(AbstractSAXParser.java:541) 10:39:52 at com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl.scanDocument(XMLDocumentFragmentScannerImpl.java:441) 10:39:52 at com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(XML11Configuration.java:819) 10:39:52 at com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(XML11Configuration.java:748) 10:39:52 at com.sun.org.apache.xerces.internal.parsers.XMLParser.parse(XMLParser.java:123) 10:39:52 at com.sun.org.apache.xerces.internal.parsers.AbstractSAXParser.parse(AbstractSAXParser.java:1208) 10:39:52 at com.sun.org.apache.xerces.internal.jaxp.SAXParserImpl$JAXPSAXParser.parse(SAXParserImpl.java:525) 10:39:52 at org.dom4j.io.SAXReader.read(SAXReader.java:465) 10:39:52 at org.dom4j.io.SAXReader.read(SAXReader.java:264) 10:39:52 at hudson.tasks.junit.SuiteResult.parse(SuiteResult.java:112) 10:39:52 at hudson.tasks.junit.TestResult.parse(TestResult.java:208) 10:39:52 at hudson.tasks.junit.TestResult.parse(TestResult.java:163) 10:39:52 at hudson.tasks.junit.TestResult.parse(TestResult.java:140) 10:39:52 at hudson.tasks.junit.TestResult.init(TestResult.java:116) 10:39:52 at hudson.tasks.junit.JUnitParser$ParseResultCallable.invoke(JUnitParser.java:114) 10:39:52 at hudson.tasks.junit.JUnitParser$ParseResultCallable.invoke(JUnitParser.java:87) 10:39:52 at hudson.FilePath.act(FilePath.java:788) 10:39:52 at hudson.FilePath.act(FilePath.java:770) 10:39:52 at hudson.tasks.junit.JUnitParser.parse(JUnitParser.java:83) 10:39:52 at hudson.tasks.junit.JUnitResultArchiver.parse(JUnitResultArchiver.java:122) 10:39:52 at hudson.tasks.junit.JUnitResultArchiver.perform(JUnitResultArchiver.java:134) 10:39:52 at hudson.tasks.BuildStepMonitor$1.perform(BuildStepMonitor.java:19) 10:39:52 at hudson.model.AbstractBuild$AbstractRunner.perform(AbstractBuild.java:703) 10:39:52 at hudson.model.AbstractBuild$AbstractRunner.performAllBuildSteps(AbstractBuild.java:678) 10:39:52 at
Re: Build step failed by build log parsing
Dear Christoph,
We implemented your proposed solution via the Groovy Plugin and it worked
ok to test for success patterns after each build step.
Thank you very much ,
Regards,
Stefano
___
Ing. Stefano Perticoni
Super Computing Solutions s.r.l.
http://www.scsitaly.com
Via Parini 1, 40033 Casalecchio di Reno BO, Italy
mailto: s.pertic...@scsitaly.com
___
On Tue, Nov 29, 2011 at 10:37 PM, Christoph Vogtländer
jenk...@mockies.dewrote:
Hi,
On Tuesday 29 November 2011 12:53:50 stefano perticoni wrote:
Dear jenkins users,
I'm new to jenkins and currently trying to replicate the build workflow
we
are using with another continous integration server.
Here is the trivial question :-) !
Is there any plugin to add, to a single build step, the capability to
parse
its output log and mark the step as failed if the condition is not
matched?
AFAIK there is no plug-in that will do this out of the box. As mentioned by
Didier you can use the Log Parser Plugin [1]. I prefer the Groovy Postbuild
Plugin [2] (using manager.logContains(regexp)). But both plug-ins only
parse
the log at the end of the build, not between build steps.
To test the log output after every build step you can use the Groovy Plugin
[3] which adds the possibility to execute system groovy code as a build
step
(at least in Free Style Projects).
You can use the following code:
--
def pattern = /^build FAILED$/
def build = Thread.currentThread().executable, result = 0
// Parsing 5 most recent lines of the build log
log = build.getLog(5)
for (line in log) {
if (line ==~ pattern) {
result = 1
break
}
}
return result
--
Hope this helps. Btw, it would be much easier (and system conform) if your
build step would return/exit with a non zero exit code directly.
--
Christoph
[1] https://wiki.jenkins-ci.org/display/JENKINS/Log+Parser+Plugin
[2] https://wiki.jenkins-ci.org/display/JENKINS/Groovy+Postbuild+Plugin
[3] https://wiki.jenkins-ci.org/display/JENKINS/Groovy+Plugin
Instable builds related to low memory
Hi everyone, There is a problem I have been struggling with Jenkins. I tried different CI servers but none of them offers the same features Jenkins has, so I want to use it. I have a small Rackspace CloudServer instance with 256MB RAM and running Jenkins with Apache Tomcat 7 in that server. Using Maven 2 and Git plugins of Jenkins. The problem is, either Maven JVM exits with the code 137 (when forking is enabled) or I get mysterious crashes. I know that the 256MB of RAM may not be enough for Jenkins; but the thing is: even when I am running Jenkins, I can build the project via command line in a short period of time. My project involves some heavy servers, and generally the test are failing with Jenkins. If I can build the project via command line just fine when the Jenkins server is running (meaning more than one JVM), isn't that a problem with the Jenkins? I tried different combinations of fork configurations and Maven JVM settings, even when build is OK for once, then it fails in subsequent builds. I even set maximum number of builds to keep to 3, but it didn't help. Any comments are appreciated. Best regards, Deniz
Re: Instable builds related to low memory
Hi, Did you try to try Java heap size via the Java options (advanced section) of the step config parameters using Xnx and Xms ? That should solve your issue. [I dodn't think the size of physical real memory really matters for completion: even if you allocate more heap than physical memory, your server will paginate and extend duration but it should go to end with the right settings of Xmx / Xms. I would also recommend you to install the Jenkins monitoring plugin based on Java Melody: very useful to follow memory comsumption regards didier Le vendredi 9 mars 2012 12:47:25 UTC+1, dacay a écrit : Hi everyone, There is a problem I have been struggling with Jenkins. I tried different CI servers but none of them offers the same features Jenkins has, so I want to use it. I have a small Rackspace CloudServer instance with 256MB RAM and running Jenkins with Apache Tomcat 7 in that server. Using Maven 2 and Git plugins of Jenkins. The problem is, either Maven JVM exits with the code 137 (when forking is enabled) or I get mysterious crashes. I know that the 256MB of RAM may not be enough for Jenkins; but the thing is: even when I am running Jenkins, I can build the project via command line in a short period of time. My project involves some heavy servers, and generally the test are failing with Jenkins. If I can build the project via command line just fine when the Jenkins server is running (meaning more than one JVM), isn't that a problem with the Jenkins? I tried different combinations of fork configurations and Maven JVM settings, even when build is OK for once, then it fails in subsequent builds. I even set maximum number of builds to keep to 3, but it didn't help. Any comments are appreciated. Best regards, Deniz
Re: Bacis steps to write a plugin which depends on another
Thanks. I want to depend on an authorization plugin, so if an user login in, the internal user database from jenkins shall be filled with the data from the external database. Are there any events or anything like that, which I can use?
new version of Jenkins Violations plugin?!
Hi, any news about new version of Jenkins Violations plugin (https:// wiki.jenkins-ci.org/display/JENKINS/Violations). Especially concerning FindBugs 2.0 compatibility. Thanks Darko
Re: Instable builds related to low memory
Exit code 137 = 128 + 9 = The process died because it received a signal and the signal was 9 which is SIGKILL. SIGKILL is the signal Linux out-of-memory killer uses to get rid of memory hogs. It sure sounds like you might not have enough memory. But I cannot answer why it takes more memory when Jenkins runs maven. Maybe Jenkins starts multiple jvms? You could also create a freestyle job and run the mvn build from a shell build step and see how that turns out. -- Sami 2012/3/9 Deniz Acay deniza...@gmail.com: Hi everyone, There is a problem I have been struggling with Jenkins. I tried different CI servers but none of them offers the same features Jenkins has, so I want to use it. I have a small Rackspace CloudServer instance with 256MB RAM and running Jenkins with Apache Tomcat 7 in that server. Using Maven 2 and Git plugins of Jenkins. The problem is, either Maven JVM exits with the code 137 (when forking is enabled) or I get mysterious crashes. I know that the 256MB of RAM may not be enough for Jenkins; but the thing is: even when I am running Jenkins, I can build the project via command line in a short period of time. My project involves some heavy servers, and generally the test are failing with Jenkins. If I can build the project via command line just fine when the Jenkins server is running (meaning more than one JVM), isn't that a problem with the Jenkins? I tried different combinations of fork configurations and Maven JVM settings, even when build is OK for once, then it fails in subsequent builds. I even set maximum number of builds to keep to 3, but it didn't help. Any comments are appreciated. Best regards, Deniz
Re: Instable builds related to low memory
On 03/09/2012 08:20 PM, Sami Tikka wrote: Exit code 137 = 128 + 9 = The process died because it received a signal and the signal was 9 which is SIGKILL. SIGKILL is the signal Linux out-of-memory killer uses to get rid of memory hogs. It sure sounds like you might not have enough memory. But I cannot answer why it takes more memory when Jenkins runs maven. Maybe Jenkins starts multiple jvms? You could also create a freestyle job and run the mvn build from a shell build step and see how that turns out. -- Sami 2012/3/9 Deniz Acaydeniza...@gmail.com: Hi everyone, There is a problem I have been struggling with Jenkins. I tried different CI servers but none of them offers the same features Jenkins has, so I want to use it. I have a small Rackspace CloudServer instance with 256MB RAM and running Jenkins with Apache Tomcat 7 in that server. Using Maven 2 and Git plugins of Jenkins. The problem is, either Maven JVM exits with the code 137 (when forking is enabled) or I get mysterious crashes. I know that the 256MB of RAM may not be enough for Jenkins; but the thing is: even when I am running Jenkins, I can build the project via command line in a short period of time. My project involves some heavy servers, and generally the test are failing with Jenkins. If I can build the project via command line just fine when the Jenkins server is running (meaning more than one JVM), isn't that a problem with the Jenkins? I tried different combinations of fork configurations and Maven JVM settings, even when build is OK for once, then it fails in subsequent builds. I even set maximum number of builds to keep to 3, but it didn't help. Any comments are appreciated. Best regards, Deniz I could increase the memory, but doing so just for Jenkins is not acceptable for me. I am trying others' suggestions too. If none of them works out, I may create a freestyle shell job to do the work as you suggested, as a last resort. Thanks for answer! Best, Deniz
hudson.remoting.ChannelClosedException
Hi All, We're starting to see a few random slave-agent disconnects and I'm wondering if anyone has any info. A search online doesn't reveal anything useful nor do the Jenkins logs or System logs. We're running Jenkins build 1.448 hosted on a Linux machine, the node is OSX 10.6.8. Thanks in advance, Noah FATAL: channel is already closed hudson.remoting.ChannelClosedExceptionhttp://stacktrace.jenkins-ci.org/search?query=hudson.remoting.ChannelClosedException: channel is already closed at hudson.remoting.Channel.send(Channel.java:499)http://stacktrace.jenkins-ci.org/search/?query=hudson.remoting.Channel.sendentity=method at hudson.remoting.Request.call(Request.java:110)http://stacktrace.jenkins-ci.org/search/?query=hudson.remoting.Request.callentity=method at hudson.remoting.Channel.call(Channel.java:681)http://stacktrace.jenkins-ci.org/search/?query=hudson.remoting.Channel.callentity=method at hudson.EnvVars.getRemote(EnvVars.java:202)http://stacktrace.jenkins-ci.org/search/?query=hudson.EnvVars.getRemoteentity=method at hudson.model.Computer.getEnvironment(Computer.java:828)http://stacktrace.jenkins-ci.org/search/?query=hudson.model.Computer.getEnvironmententity=method at hudson.model.Run.getEnvironment(Run.java:1849)http://stacktrace.jenkins-ci.org/search/?query=hudson.model.Run.getEnvironmententity=method at hudson.model.AbstractBuild.getEnvironment(AbstractBuild.java:819)http://stacktrace.jenkins-ci.org/search/?query=hudson.model.AbstractBuild.getEnvironmententity=method at org.jenkinsci.plugins.tokenmacro.impl.EnvironmentVariableMacro.evaluate(EnvironmentVariableMacro.java:23)http://stacktrace.jenkins-ci.org/search/?query=org.jenkinsci.plugins.tokenmacro.impl.EnvironmentVariableMacro.evaluateentity=method at org.jenkinsci.plugins.tokenmacro.DataBoundTokenMacro.evaluate(DataBoundTokenMacro.java:177)http://stacktrace.jenkins-ci.org/search/?query=org.jenkinsci.plugins.tokenmacro.DataBoundTokenMacro.evaluateentity=method at org.jenkinsci.plugins.tokenmacro.TokenMacro.expand(TokenMacro.java:160)http://stacktrace.jenkins-ci.org/search/?query=org.jenkinsci.plugins.tokenmacro.TokenMacro.expandentity=method at org.jenkinsci.plugins.buildnamesetter.BuildNameSetter.setDisplayName(BuildNameSetter.java:47)http://stacktrace.jenkins-ci.org/search/?query=org.jenkinsci.plugins.buildnamesetter.BuildNameSetter.setDisplayNameentity=method at org.jenkinsci.plugins.buildnamesetter.BuildNameSetter.access$000(BuildNameSetter.java:23)http://stacktrace.jenkins-ci.org/search/?query=org.jenkinsci.plugins.buildnamesetter.BuildNameSetter.access$000entity=method at org.jenkinsci.plugins.buildnamesetter.BuildNameSetter$1.tearDown(BuildNameSetter.java:39)http://stacktrace.jenkins-ci.org/search/?query=org.jenkinsci.plugins.buildnamesetter.BuildNameSetter$1.tearDownentity=method at hudson.model.Build$RunnerImpl.doRun(Build.java:150)http://stacktrace.jenkins-ci.org/search/?query=hudson.model.Build$RunnerImpl.doRunentity=method at hudson.model.AbstractBuild$AbstractRunner.run(AbstractBuild.java:470)http://stacktrace.jenkins-ci.org/search/?query=hudson.model.AbstractBuild$AbstractRunner.runentity=method at hudson.model.Run.run(Run.java:1404)http://stacktrace.jenkins-ci.org/search/?query=hudson.model.Run.runentity=method at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:46)http://stacktrace.jenkins-ci.org/search/?query=hudson.model.FreeStyleBuild.runentity=method at hudson.model.ResourceController.execute(ResourceController.java:88)http://stacktrace.jenkins-ci.org/search/?query=hudson.model.ResourceController.executeentity=method at hudson.model.Executor.run(Executor.java:238)http://stacktrace.jenkins-ci.org/search/?query=hudson.model.Executor.runentity=method Caused by: java.io.IOExceptionhttp://stacktrace.jenkins-ci.org/search?query=java.io.IOException: Unexpected termination of the channel at hudson.remoting.Channel$ReaderThread.run(Channel.java:1133)http://stacktrace.jenkins-ci.org/search/?query=hudson.remoting.Channel$ReaderThread.runentity=method Caused by: java.io.EOFException http://stacktrace.jenkins-ci.org/search?query=java.io.EOFExceptionat java.io.ObjectInputStream$BlockDataInputStream.peekByte(ObjectInputStream.java:2553)http://stacktrace.jenkins-ci.org/search/?query=java.io.ObjectInputStream$BlockDataInputStream.peekByteentity=method at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1296)http://stacktrace.jenkins-ci.org/search/?query=java.io.ObjectInputStream.readObject0entity=method at java.io.ObjectInputStream.readObject(ObjectInputStream.java:350)http://stacktrace.jenkins-ci.org/search/?query=java.io.ObjectInputStream.readObjectentity=method at
