[DRBD-user] multiple pools

Robert Altnoeder robert.altnoeder at linbit.com
Tue Dec 12 14:33:12 CET 2017

Note: "permalinks" may not be as permanent as we would like,
direct links of old sources may well be a few messages off.

On 12/12/2017 12:09 PM, Julien Escario wrote:

> Sounds promising !
> I would just have a reserve about using Java as main language : it's always been
> a nightmare to get a working version of JRE. There's a lot of versions and
> implementations depending upon the running OS.
There should be a precompiled or even a packaged JRE available on most
platforms, and any standards-compliant JRE will work. We are currently
running our tests on different Linux distributions on amd64 running JRE
7 and JRE 8, on Mac OS X running JRE 8 (controller only) and on Ubuntu
ppc64 running JRE 8, and the behavior is identical on all platforms.
> And it's really heavy RAM consuming, even for an 'hello world'.
The Java virtual machine has a base RAM consumption that obviously uses
lots of memory for just 'hello world', but that does not mean that the
application's data structures will necessarily use more RAM than the
same application written in another language.
And we are talking about a software that is running a complete
implementation of an SQL database in its address space, so I don't think
the base RAM consumption of the Java virtual machine will matter much.
> From my point of view, it doesn't really seems to be a wise choice. A modern
> language like Go, Python, Ruby, etc ... could have been far more future-proof.
I disagree, because the main problems of the current implementation of
drbdmanage were reliability and performance.

While most of the reliability problems were caused by the behavior of
the external environment, like LVM utilities, dm kernel driver, udev,
D-Bus, etc., maintaining the Python project had also become a nightmare,
mostly due to the fact that Python is a dynamically typed programming
We had code breakage between different minor versions of Python because
the input or output type of functions in the standard library changed
subtly and without notice, and it only ever failed during runtime - even
though we performed static checking on the source code (using pylint).
Fixing one thing quite commonly broke two other things. Everyone on the
team had become frustrated enough with Python that noone wanted to work
with it anymore.

I suggested the use of Java because it is one of the strictest
programming languages that is in widespread use. It is strongly
statically typed, it forces you to catch most exceptions (except for
runtime exceptions), so you always know what could go wrong, it does not
hide bugs by performing potentially dangerous conversions between data
types automatically (e.g., any condition _must_ be of type boolean, you
can't just use a non-null reference, a non-empty list or a non-zero
integer to represent a value of 'true'), so it prevents lots of classes
of implementation errors (often really just typos or unexpected
behavior) that frequently broke our previous Python implementation of
drbdmanage. The same classes of implementation errors break projects in
other programming languages on a daily basis - especially those written
in dymanically typed languages like Python, Ruby, Perl, etc.
In this regard, Java does exactly what we want - our primary goal for
the project is improved reliability.

Performance-wise, multithreading with Python is more or less useless
(because inefficient), and Python is generally slower than Java and uses
just as much memory.

Also, regarding the modernness of programming languages - although
modernness is hard to measure anyways, Java is, in every respect, a more
modern programming language than Python, both technically and regarding
the date of its invention.

Go was also considered as a possible candidate, but it is more of a
replacement for procedural programming languages like C than it is a
replacement for any fully object-oriented programming language, and the
linstor project turned out to make extensive use of interfaces,
inheritance, polymorphism and structured exception handling, all of
which Go lacks.
Also, Go tends to use large amounts of RAM, possibly even more than the
Java VM, and Java had similar performance as Go in most tests, sometimes
even outperforming Go (both were typically 5 to 10 percent slower than
equivalent C++ code).

Actually, the final decision was between Go and Java.

Now factor in the extensive standard library and excellent documentation
of it that Java comes with, strong IDE support, and the fact that
finding programmers who have experience with the language is quite easy
(which was actually the final reason to decide in favor of Java and
against Go), because Java is in widespread use and has been around for a
while, and you have a winner.

Looking at the state of the project as it is now, I still believe it was
the right choice. I doubt that we could have developed an equivalent
solution in the same amount of time and in the same quality with any of
the other programming languages.

> Best regards,
> Julien Escario

best regards,
Robert Altnoeder
+43 1 817 82 92 0
robert.altnoeder at linbit.com

LINBIT | Keeping The Digital World Running
DRBD - Corosync - Pacemaker
f /  t /  in /  g+

DRBD® and LINBIT® are registered trademarks of LINBIT, Austria.

More information about the drbd-user mailing list