4 ms·

Typical issues surrounding Java projects: - High startup time. Anything bigger than a hello world takes seconds, more typically tens of seconds, to start. My J

Typical issues surrounding Java projects: - High startup time. Anything bigger than a hello world takes seconds, more typically tens of seconds, to start. My Jenkins setup takes 3 or 4 minutes before it is fully initialized. Even starting the JVM in client mode doesn't help much. I know, it's a server, and startup time doesn't matter once it's running, but it feels annoying. - High memory usage. Heaps in the 1-2 GB range are not uncommon. This can probably be tweaked but as a user who is not a Java expert, figuring out how to do this (and figuring out what value is safe) is frustrating. - XML configuration files. XML was hip in 2004 but these days it is frowned upon and users generally don't like it. This is technically not Java's fault (and I'm sure newer projects use something else) but it is something traditionally heavily associated with Java projects. - Non-Unixy feel. Lots of things just behave like they're not really native.

jacques_chester 11y ago
Jenkins is not my cup of tea, but in its defence: 1. High startup time is amortised over long run times. Jenkins is a general CI server, not an interactive build tool. 2. High memory usage is true, though again tolerable given the role and importance Jenkins will assume in any sane project.
Alupis 11y ago
> - High startup time. This is really not a problem. If you're starting and stopping your Jenkins often, you're really doing it wrong. Jenkins is a server, and really should only get restarted when there's been an update. Not to mention, other large servers that are not Java still take time to startup... there's a lot going on during initialization. > - High memory usage. Perhaps more of an issue for some, but again, Jenkins is a build server, and should be on it's own hardware/vm, with it's own dedicated resources. If you're trying to squeeze by with 1GB of ram, you can, but you should expect the obvious results. The more complicated your builds, the more resources they're consume. Compiling GCC usually takes 1-2GB ram by itself. I don't consider this a problem. > - XML configuration files. If you're using Jenkins properly, you should not have to interact with any config files. Sure, if you're running it behind Tomcat or something, you'll need to dip into the configs, but not liking Jenkins because it has XML config files is shallow and superficial, in my opinion. > - Non-Unixy feel. Lots of things just behave like they're not really native. I'm not sure what to expect from a deliberately cross-platform system. Of course it's not "native Unix-like". But neither is any software written to support OS's that are not Unix-like. And again, you manage and use Jenkins from a web interface, so if you're on the command line, you're doing it wrong. (as an aside, Jenkins has native support for running shell scripts, which I make heavy use of... can't get any more unix-like than that).
- pswenson 11y ago
  the config is a huge problem, not just because of XML files. Jenkins (pre 2.0 at least) job configs have huge problems with config drift and doesn't play well with configuration management tools. Trying to automate jenkins job configurations requires using the terrible job config xml format and a poorly designed rest API which breaks all the time when you add in a plugin or plugins get upgraded.
  - oblio 11y ago
    Then this should be a life saver for this scenario: https://wiki.jenkins-ci.org/display/JENKINS/Job+DSL+Plugin https://wiki.jenkins-ci.org/display/JENKINS/Job+DSL+Plugin Jenkins has a ton of issues but with a bit of careful plugin selection it provides a ton of bang for your buck.
    - ecnahc515 11y ago
      The new integrated DSL to replace that plugin is going to be great. Unfortunately, managing jenkins plugins themselves via config management/orchestration is still surprisingly difficult.
      - abayer 11y ago
        fwiw, this is very much on the roadmap - https://issues.jenkins-ci.org/browse/JENKINS-31094 https://issues.jenkins-ci.org/browse/JENKINS-31094 - don't know when it'll land, but it will be done. =)
mark242 11y ago
"Heaps in the 1-2 GB range are not uncommon." Is this really still a complaint in 2016? Your phone has that much RAM. Honestly if you're worried about Java heap size, spin up a t2.medium instead of a t2.small for your build pipeline. Running Jenkins on a Raspberry Pi is probably not a great idea if you're writing any serious application.
- ascotan 11y ago
  Actually it's becoming more of a complaint in 2016 with rise AWS instances that pay by the container size and with the rise of languages like go, etc. which have smaller runtime sizes and are more compatible with cloud computing environments like docker. The JVM adds something like 400MB to every layer of a docker container resulting in multi gigabyte containers. Additionally the memory requirements for running a JVM put you immediately into the t2.medium range which will cost you 4X cost over a t2.nano for simply choosing to run Java instead of something with a smaller runtime footprint.
  - mark242 11y ago
    Don't run production code on a nano. Don't run production code on a nano. Don't run production code on a nano. I don't care what language you're using, if you find yourself saying "well, I could run on a nano" just stop.
  - Alupis 11y ago
    > The JVM adds something like 400MB to every layer of a docker container Perhaps this is the "writing on the wall" that containers aren't what you should be using to deploy your app. Just because it's the "latest craze" doesn't mean it's the best solution for the task at hand.
- t0mk 11y ago
  In the simplest case, Jenkins is just polling and cloning git repos, and then spawning some tests. This plus config parsing and web frontend is not a 1GB RAM job.
  - deleted 11y ago
dmytroi 11y ago
I would agree on some of your points : few minutes initialization times and 1-2 GB heaps may sound not that bad, and when we are talking about product that just provides a fancy, over engineered way to run bunch of shell scripts (considering jenkins doesn't integrate sandboxing from the box) ... honestly there is no excuse to spend 2 gigs of ram just to run shell scripts with web UI. It would be much better in a long term to improve energy/resource efficiency of software like this, just to make it more sustainable and reliable. Edit: configuration-as-code feature is available in jenkins 1.x with job dsl plugin [1], I'm using it at work, because managing 50+ jobs by hand was just insane. Nowadays we just have few dsl files :) [1] https://wiki.jenkins-ci.org/display/JENKINS/Job+DSL+Plugin https://wiki.jenkins-ci.org/display/JENKINS/Job+DSL+Plugin
incepted 11y ago
> High startup time. Anything bigger than a hello world takes seconds Oh, no! Seconds? Like five? Seven? For a process that you start less than once a day? Unacceptable. > High memory usage. Heaps in the 1-2 GB range are not uncommon. So... what? Spend an additional $30 on your build server and add 8Gb to it. Problem solved. > - XML configuration files. XML is fine. As opposed to Groovy, IDE's do a great job at offering auto-completion on it. But if Groovy is your bag, you can use that too. > - Non-Unixy feel. I have no idea what that means and I've been using UNIX for about thirty years now.

jacques_chester 11y ago

Jenkins is not my cup of tea, but in its defence: 1. High startup time is amortised over long run times. Jenkins is a general CI server, not an interactive build tool. 2. High memory usage is true, though again tolerable given the role and importance Jenkins will assume in any sane project.

Alupis 11y ago

> - High startup time. This is really not a problem. If you're starting and stopping your Jenkins often, you're really doing it wrong. Jenkins is a server, and really should only get restarted when there's been an update. Not to mention, other large servers that are not Java still take time to startup... there's a lot going on during initialization. > - High memory usage. Perhaps more of an issue for some, but again, Jenkins is a build server, and should be on it's own hardware/vm, with it's own dedicated resources. If you're trying to squeeze by with 1GB of ram, you can, but you should expect the obvious results. The more complicated your builds, the more resources they're consume. Compiling GCC usually takes 1-2GB ram by itself. I don't consider this a problem. > - XML configuration files. If you're using Jenkins properly, you should not have to interact with any config files. Sure, if you're running it behind Tomcat or something, you'll need to dip into the configs, but not liking Jenkins because it has XML config files is shallow and superficial, in my opinion. > - Non-Unixy feel. Lots of things just behave like they're not really native. I'm not sure what to expect from a deliberately cross-platform system. Of course it's not "native Unix-like". But neither is any software written to support OS's that are not Unix-like. And again, you manage and use Jenkins from a web interface, so if you're on the command line, you're doing it wrong. (as an aside, Jenkins has native support for running shell scripts, which I make heavy use of... can't get any more unix-like than that).

pswenson 11y ago
the config is a huge problem, not just because of XML files. Jenkins (pre 2.0 at least) job configs have huge problems with config drift and doesn't play well with configuration management tools. Trying to automate jenkins job configurations requires using the terrible job config xml format and a poorly designed rest API which breaks all the time when you add in a plugin or plugins get upgraded.
- oblio 11y ago
  Then this should be a life saver for this scenario: https://wiki.jenkins-ci.org/display/JENKINS/Job+DSL+Plugin https://wiki.jenkins-ci.org/display/JENKINS/Job+DSL+Plugin Jenkins has a ton of issues but with a bit of careful plugin selection it provides a ton of bang for your buck.
  - ecnahc515 11y ago
    The new integrated DSL to replace that plugin is going to be great. Unfortunately, managing jenkins plugins themselves via config management/orchestration is still surprisingly difficult.
    - abayer 11y ago
      fwiw, this is very much on the roadmap - https://issues.jenkins-ci.org/browse/JENKINS-31094 https://issues.jenkins-ci.org/browse/JENKINS-31094 - don't know when it'll land, but it will be done. =)

mark242 11y ago

"Heaps in the 1-2 GB range are not uncommon." Is this really still a complaint in 2016? Your phone has that much RAM. Honestly if you're worried about Java heap size, spin up a t2.medium instead of a t2.small for your build pipeline. Running Jenkins on a Raspberry Pi is probably not a great idea if you're writing any serious application.

ascotan 11y ago
Actually it's becoming more of a complaint in 2016 with rise AWS instances that pay by the container size and with the rise of languages like go, etc. which have smaller runtime sizes and are more compatible with cloud computing environments like docker. The JVM adds something like 400MB to every layer of a docker container resulting in multi gigabyte containers. Additionally the memory requirements for running a JVM put you immediately into the t2.medium range which will cost you 4X cost over a t2.nano for simply choosing to run Java instead of something with a smaller runtime footprint.
- mark242 11y ago
  Don't run production code on a nano. Don't run production code on a nano. Don't run production code on a nano. I don't care what language you're using, if you find yourself saying "well, I could run on a nano" just stop.
- Alupis 11y ago
  > The JVM adds something like 400MB to every layer of a docker container Perhaps this is the "writing on the wall" that containers aren't what you should be using to deploy your app. Just because it's the "latest craze" doesn't mean it's the best solution for the task at hand.
t0mk 11y ago
In the simplest case, Jenkins is just polling and cloning git repos, and then spawning some tests. This plus config parsing and web frontend is not a 1GB RAM job.
- deleted 11y ago

dmytroi 11y ago

I would agree on some of your points : few minutes initialization times and 1-2 GB heaps may sound not that bad, and when we are talking about product that just provides a fancy, over engineered way to run bunch of shell scripts (considering jenkins doesn't integrate sandboxing from the box) ... honestly there is no excuse to spend 2 gigs of ram just to run shell scripts with web UI. It would be much better in a long term to improve energy/resource efficiency of software like this, just to make it more sustainable and reliable. Edit: configuration-as-code feature is available in jenkins 1.x with job dsl plugin [1], I'm using it at work, because managing 50+ jobs by hand was just insane. Nowadays we just have few dsl files :) [1] https://wiki.jenkins-ci.org/display/JENKINS/Job+DSL+Plugin https://wiki.jenkins-ci.org/display/JENKINS/Job+DSL+Plugin

incepted 11y ago

> High startup time. Anything bigger than a hello world takes seconds Oh, no! Seconds? Like five? Seven? For a process that you start less than once a day? Unacceptable. > High memory usage. Heaps in the 1-2 GB range are not uncommon. So... what? Spend an additional $30 on your build server and add 8Gb to it. Problem solved. > - XML configuration files. XML is fine. As opposed to Groovy, IDE's do a great job at offering auto-completion on it. But if Groovy is your bag, you can use that too. > - Non-Unixy feel. I have no idea what that means and I've been using UNIX for about thirty years now.