For a very small team, why shouldn't I use built in H2 with JIRA?

I work with JIRA here at Draper and love it.  I would like to install JIRA on a Raspberry PI 3 at home running headlessly (with the $10 minimum license).  I think my overall system footprint would be reduced by running H2 and the traffic would be light.  What is the main risk of using H2?

Part 2: I am assuming that if I get convinced not to run H2, that the data base should be installed on another PI for best performance.  Is that a correct assumption?

3 answers

1 accepted

2 votes
Accepted answer

Catastrophic failure is the short answer.  It's rare (and even more rare than the failures we've seen with the old HSQL option for JIRA 6 and below), but can still happen, and, like HSQL, if it does go, it's very unlikely you'll be able to recover it without resorting to backups.

It's hard to say it would change performance.  The load is spread across two machines, so in theory, yes, more cpu time for both server and application = better performance.  But then you have to allow for networking drag as packets have to go to other machines.

Okay, so the short answer is H2 is not ready for prime time?

On the performance question, I was not really concerned with the CPU consumed by both JIRA and an SQL db running on the same computer.  I was more concerned with RAM: while 1 GB is a lot for a $35.00 computer, it goes pretty fast and swapping kills faster than lack of MIPS does.

Anyway, it sounds like the reliability is questionable enough that I will "byte" the bullet on an extra install and network node.


Yes.  H2 is a better in-memory solution than hsql, but it's still got the same flaws because of the very nature of what it's doing.

For what it's worth, I've got a test rig here that works fine for small usage:

Pi 2: running PostGres

Pi 3: running JIRA 7.2

Both with external usb drives.  Both built with DietPi and not running anything else.

Original response to the above comment deleted: I misunderstood "built withDietPi" to refer to building an OS from make scripts, etc.  DietPi looks pretty simple so if you already got the original comment, please ignore it

Heh, yes, I saw it, didn't think it was worth deleting to be honest, it looked fine, albeit not quite Atlassian any more.  My thought was "that's just what I chose to do because DietPi keeps it simple and single-purpose which is what I wanted for some boxes.  I go to Raspian for any general-purpose ones.  I'd recommend using the OS you're happiest with"

I use Raspian for my PI development environment (Eclipse on a PI 2/3 for native debug of device drivers like motor controllers and such) and also my SVN server at home for release control. For that situation, and something like JIRA, I would stick to Raspian (Jessie Lite since it will be headless) as long as memory isn't an issue. Where I was thinking of using something like DietPI is my current project: A PI zero based controller for my old Celestron Super C8 where just 1 core makes my main drive controller more sensitive to other stuff taking over behind my back.

Anyway, thanks again.

H2 is a memory based database which means that if the server were to die you might lose quite a lot of data, just like HSQL did. For all i know a in-memory will always be faster while consuming more ram and lacking writes to disk, in very short.

P2: a small mysql deployment on another PI3 could be a solution.

Part 1: I thought H2 was wrote to disk with in memory being an option.

Part 2: That was exactly what I was thinking if H2 is risky.


Also, I had accepted your answer but I thought Nic's was more to the point on the H2 question which I gave precedence to.  And apparently, I can't accept more than one.


NOTE: I have received a satisfactory answer.  However, stay tuned.  I have seen enough hits on Google WRT interest in JIRA on the Raspberry PI that I will put out some notes on my success or failure when I actually try to set it up: question(s) on why if failure, blog post(s) if success.

Suggest an answer

Log in or Sign up to answer
Community showcase
Published Nov 27, 2018 in Portfolio for Jira

Introducing a new planning experience in Portfolio for Jira (Server/DC)

In the past, Portfolio for Jira required a high degree of detail–foresight that was unrealistic for many businesses to   have–in   order to produce a reliable long-term roadmap. We're tur...

2,808 views 18 22
Read article

Atlassian User Groups

Connect with like-minded Atlassian users at free events near you!

Find a group

Connect with like-minded Atlassian users at free events near you!

Find my local user group

Unfortunately there are no AUG chapters near you at the moment.

Start an AUG

You're one step closer to meeting fellow Atlassian users at your local meet up. Learn more about AUGs

Groups near you