I've recently been trying to set up a Jenkins server that uses the Jenkins MKS plugin for version control. I had a Windows Jenkins server that was running this same configuration just fine, and now that we're moving it to a linux server (Red Hat Enterprise Linux Client release 5.1 Tikanga), it doesn't seem to be able to download the files. The folder structure is built perfectly fine, which tells me connecting to the server isn't the problem, but the files aren't populated in the folders.
Jenkins System Log:
Sep 02, 2016 11:15:46 AM WARNING org.apache.commons.httpclient.HttpMethodBase readResponseBody
Unsupported transfer encoding:
Sep 02, 2016 11:15:46 AM INFO org.apache.commons.httpclient.HttpMethodBase readResponseBody Response
content is not chunk-encoded
Sep 02, 2016 11:15:46 AM INFO hudson.model.Run execute
Test #67 main build action completed: FAILURE
Any suggestions on what I can do to check if my data/files are chunk encoded, or why this would be unique to a linux server? I realize we’re 3+ years behind on our configuration, but IT here has tight restrictions on what software can be installed and updated. Any troubleshotting suggestions or help is much appreciated!
Config Details:
Jenkins Version 1.596.3
MKS Plugin Version 1.16 MKS Server: MKS Integrity Client 2009, Build
4.10.0.9665, SP 007-01
Jenkins Slave info: Red Hat Enterprise Linux Client release 5.1
(Tikanga)
Java version 1.7.0 Java(TM) SE Runtime Environment (build 1.7.0-b147)
Java HotSpot(TM) Server_VM (build 21.0-b17, mixed mode)
Similar issues / Research:
This issue report perfectly describes my problem, but the comment section suggests that the Java 7u40 update causes the issue, whereas I'm on an earlier version of Java.
https://issues.jenkins-ci.org/browse/JENKINS-21638
This issue describes the log error I'm seeing, but comment section suggests it was solved by Jenkins version 1.577. We're using a newer version of Jenkins. https://issues.jenkins-ci.org/browse/JENKINS-16985
You're using Integrity 10.9: As per the Version 2.0 (Jan 27, 2016) entry on the Plug-in's page:
IMPORTANT – PTC Integrity Plugin 2.0 is not backward compatible.
Please create new Jobs.
Productized version of PTC Integrity Plugin
compatible with PTC Integrity 10.9. Versions older than Integrity
10.9 are no longer supported.
I think what Cletus is trying to explain in that post is that both the version of Java used to build the plug-in and the version of Java running Integrity should be the same, and in the case linked for JENKINS-21638, changes in the 'File' object after Java 7u40 are preventing the plug-in from fetching files from the server.
If you were on a version of Java earlier than 7u40 (e.g. 7u25) it should work. Integrity 2009 SP6 (and hence the mksapi.jar file) were compiled with Java 6, so it's likely you're running into a similar issue there. Having said that, I'm working on an educated guess here, so you'd actually need to test that to see if it works.
Related
I installed java 13 prior and now need to install java 8 on my mac. As a newbie can I have 2 java versions on my machine and if yes then how can I make Jenkins installed for which java 8 is must OR is there a way to install Jenkins with java 13.
You can have multiple JRE or JDK installed in your machine (standard BE practice) but you can refer only one with your environment variable (usually the latest).
That means that **when you want to run something with java8 you will have to call it using the full path instead of just 'java' **.
I strongly recommend you to use docker and the container to run jenkins , mapping the home folder to a folder in your machine. This will give you full portability and easier upgrades / rollbacks. link
PS: welcome to SO !
How to install the jenkins on a solaris server? i found articles that this cannot be done as jenkins has discontinued support for solaris.
Even though official IPS repositories for Solaris are discontinued, you can still run Jenkins in Solaris via the jenkins webapp (jenkins.war). To quote from Jenkins installation doc:
Solaris, OmniOS, SmartOS, and other siblings
Generally it should
suffice to install Java 8 and download the jenkins.war and run it as a
standalone process or under an application server such as Apache
Tomcat.
Some caveats apply:
Headless JVM and fonts: For OpenJDK builds on minimalized-footprint
systems, there may be issues running the headless JVM, because Jenkins
needs some fonts to render certain pages.
ZFS-related JVM crashes: When Jenkins runs on a system detected as a
SunOS, it tries to load integration for advanced ZFS features using
the bundled libzfs.jar which maps calls from Java to native libzfs.so
routines provided by the host OS. Unfortunately, that library was made
for binary utilities built and bundled by the OS along with it at the
same time, and was never intended as a stable interface exposed to
consumers. As the forks of Solaris legacy, including ZFS and later the
OpenZFS initiative evolved, many different binary function signatures
were provided by different host operating systems - and when Jenkins
libzfs.jar invoked the wrong signature, the whole JVM process crashed.
A solution was proposed and integrated in jenkins.war since weekly
release 2.55 (and not yet in any LTS to date) which enables the
administrator to configure which function signatures should be used
for each function known to have different variants, apply it to their
application server initialization options and then run and update the
generic jenkins.war without further workarounds. See the libzfs4j Git
repository for more details, including a script to try and "lock-pick"
the configuration needed for your particular distribution (in
particular if your kernel updates bring a new incompatible libzfs.so).
Also note that forks of the OpenZFS initiative may provide ZFS on
various BSD, Linux, and macOS distributions. Once Jenkins supports
detecting ZFS capabilities, rather than relying on the SunOS check,
the above caveats for ZFS integration with Jenkins should be
considered.
I am trying to pick up Grails using Groovy Grails tool suite. I tried to set up the tools to play around with Grails, unfortunately this issue which will need some advise. Please help me to resolve this problem.
These are the tools I had installed, using window 7:
1. Java JDK (jdk1.8.0_101)
2. Grails 2.3.4
3. Groovy Grails Tool Suite 3.5.1
Both Java and Grails are running fine. #cmd:
C:\Users\00Who00>java -version
java version "1.8.0_101"
Java(TM) SE Runtime Environment (build 1.8.0_101-b13)
Java HotSpot(TM) 64-Bit Server VM (build 25.101-b13, mixed mode)
C:\Users\00Who00>grails -version
Java HotSpot(TM) 64-Bit Server VM warning: ignoring option PermSize=32m; support
was removed in 8.0
Java HotSpot(TM) 64-Bit Server VM warning: ignoring option MaxPermSize=256m; sup
port was removed in 8.0
Grails version: 2.3.4
Grails 2.3 doesn't work with Java 8 because of the version of Groovy it uses; you need to use a newer version that uses a version of Groovy that's compatible. Either user Grails 2.4+ (or embrace 2016 and use an even more recent version) or switch to Java 7.
If you're getting started with Grails and attempting to use GGTS and Grails 2.3, I suspect you might be reading Grails in Action 2nd Ed. A fantastic book! Regardless, a couple of things to note:
Groovy-Grails Tool Suite has been discontinued for over a year, so is quite likely to have more issues
Grails 3.x is the latest and much improved (Gradle and Spock are defaults, among many other things)
For an IDE, I suggest switching to IntelliJ IDEA. If you are using Grails 3, both Ultimate and Community editions work fine since Grails 3 uses Gradle as a build tool. I'd definitely recommend the Grails 3/IntelliJ combo for getting up to speed, even if you need to switch back to 2.3 for work purposes. Nearly all the knowledge will transfer.
Available Grails 3 resources
There are no books yet on Grails 3 specifically. Here are some of the best resources I've found.
Grails 3 talks at SpringOne: infoq.com/conferences/springone2gx2015
Grails 3 User Guide: docs.grails.org/latest/guide/single.html
MrHaki's "Grails Goodness" series (which he offers compiled as a book also): mrhaki.blogspot.com/search/label/Grails%3AGoodness.
Beyond those, the Grails in Action 2nd Ed book is still very relevant and one of the best ways to get a comprehensive understanding of Grails.
We have Jenkins installed and running on a WebSphere Application Server. We recently upgraded the server to version 8.5.5 and switched the profile to use JDK version 1.7. Doing this Jenkins Crashes the WebSphere Application Server and we cannot tell why. Any hints or suggestions on things to look at? Switching the server back to JDK 1.6 seems to work just fine, can Jenkins not run on JDK 1.7 or is it something else?
I'll assume that by crash the websphere application server you mean either a fatal error at startup or a java process crash. Those can have many causes.
Just to give some ideas, it may be related to the fact that you had somewhat customized your JDK install and forgot to re-apply those customization to your new JDK. Or that switching SDK requires you to switch command line options, or that you indeed hit an incompatible class in the stack, or that your process crash because of bad luck, etc.
So please find more information in the logs, either the corresponding stack traces in your WAS server logs or the javacores crash files.
Please also report your jenkins version.
As for JDK 7 compatibility, latest jenkins itself should be compatible, yet some plugins are not
You may also want to read this: https://stackoverflow.com/questions/17411717/jenkins-on-websphere-reports-java-lang-noclassdeffounderror-jenkins-model-jenki. Maybe you have the same issue.
If you indeed find out an incompatibility, please report an issue in jenkins issue tracker and consider updating the Jenkins Websphere wiki.
We have recently installed Orbeon Forms stable 3.8.0 CE's orbeon.war and that works out of box.
Because some features do not work in the stable version we installed the CE nightly build orbeon-CE.war, but this one does not work out of the box.
Form builder has some exceptions. Not only the builder fails but the examples too, so Form runner too.
Java exception
java.lang.NullPointerException
class: java.util.zip.Deflater
method: ensureOpen
line: 421
We are using Linux Debian Lenny 2.6.26-smp, Tomcat 5.5.
Probably we are running into some undocumented requirement for this nightly build...?
Problem identified and workaround:
We use IBM java 1.5 and this is what we found.
Orbeon stable works OK with IBM java 1.5, Orbeon nightly does not work with IBM java 1.5, see previously mentioned zip error.
We then installed SUN java 1.5 and Orbeon nightly works OK with SUN java 1.5., but first there was a problem:
*Exception in thread "exist_QuartzScheduler_QuartzSchedulerThread" java.lang.OutOfMemoryError: PermGen space*
And we googled up this thread:
http://orbeon-forms-ops-users.24843.n4.nabble.com/Data-lost-on-quot-Save-Document-quot-td40450.html
The permgen space is a separate VM
setting. It can be increased with a
VM option, e.g.:
-XX:MaxPermSize=128m
Which solved the problem.
This is not a known issue, and this is something I am unable to reproduce here. Maybe the download you got was corrupted. Try to unzip the war file by hand (e.g. with unzip), and if this gives you an error, re-download a new war. If this doesn't solve your problem, could you update your question with more information, in particular the full stack trace for that NPE?