Support for different JDK package

[Juraj Bocinec]

Greetings,

i was trying to install schedulix-server packages on Amazon Linux 2023, however the rpm installation fails due to dependency on openjdk package:

- nothing provides java-1.8.0-openjdk needed by schedulix-base-2.10-10.el7.x86_64

Problem is that on Amazon Linux 2023 the openjdk package is called java-1.8.0-amazon-corretto and not java-1.8.0-openjdk. Would it be possible to add some dependency condition into the RPM installer that would include package name for Amazon Linux to satisfy the requirements?

Thank you for info.

Juraj Bocinec

[Ronald Jeninga]

Hi Juraj,

I'll have a look at it tomorrow.

I can't promise I'll be able to find a solution immediately. Sometimes the RPM system has limitations at unexpected places.

In fact regarding Java it'll be possible to use any version starting from 1.8. We have customers that run Java 11 and some that run Java 17 without issues.

If everything fails, I'll create a separate RPM that doesn't require Java. That will install and leave you the choice which Java you'd like to use.

(It also leaves you the responsibility to install Java though. Java is still required).

I'll keep you updated.

Best regards,

Ronald

[Ronald Jeninga]

Hi Juraj,

just to give you a feedback on what's going on.

First of all, it is as I've expected and the RPM system isn't very strong in defining dependencies.

It was very easy to find the following page: https://web.archive.org/web/20160513021804/http://rpm.org/wiki/DynamicDependencies
But it is hard to find examples of complex dependencies (to be more precise: I failed to find them).

Hence, what I'm going to do is create a package schedulix-base-nojava which is intended for users that want to have more control over which Java they want to use.

The package won't have a dependency of any Java, but it should be obvious that some Java must be installed.

This leaves you the choice between installing Java 8, Java 11, Java 13 or Java 17 either as  OpenJDK release or directly purchased from Oracle, just anything.

All of the mentioned Java releases work with schedulix (In case of Java 17 you'll have to adjust the server flags somewhat).

Also newer releases or in-between releases might work. I didn't test that (yet).

Currently I'm merging a number of bugfixes from our private (and leading) git into the github repository.

If I'm going to create new RPM files, they should be up-to-date. Everything else is a waste of energy, time and effort.

You can expect them early next week, either Monday or Tuesday, a bit depending on the number of people that try to distract me ;-)

Enjoy your weekend!

Ronald

[Ronald Jeninga]

Hi Juraj,

just a moment ago I've uploaded a whole bunch of rpm files to our repository.

Since the gpg-key to check the validity of the rpms was expired, I've created a new one and recreated the rpms for schedulix 2.8 (el7 only), schedulix 2.9 and schedulix 2.10.

In release 2.10 I've created an extra rpm schedulix-base-nojava as announced.

We now have (also for el7):

schedulix-base.x86_64             2.10-16.el8  schedulix           # Base package, required by server and client
schedulix-base-nojava.x86_64      2.10-16.el8  schedulix           # same, but without Java requirement
schedulix-client.x86_64           2.10-16.el8  schedulix           # Additional files to setup a Jobserver (Agent)
schedulix-doc.noarch              2.10-16.el8  schedulix-noarch    # Documentation
schedulix-examples.noarch         2.10-16.el8  schedulix-noarch    # Some examples
schedulix-repo.noarch             2.10-16.el8  schedulix-noarch    # This makes the repository accessible for rpm/yum/dns
schedulix-server-mariadb.x86_64   2.10-16.el8  schedulix           # Additional files to setup the scheduling server with a local MariaDB (or MySQL)
schedulix-server-pg.x86_64        2.10-16.el8  schedulix           # Additional files to setup the scheduling server with a local Postgresql
schedulix-server-rmt.x86_64       2.10-16.el8  schedulix           # Additional files to setup the scheduling server with a remote DBMS
schedulix-zope.x86_64             2.10-16.el8  schedulix           # Web GUI that runs with Python2 (deprecated)
schedulix-zope4.x86_64            2.10-16.el8  schedulix                         # Web GUI that runs with Python3

If you encounter issues, please report.

Best regards,

[Juraj Bocinec]

Greetings,

seems Google doesn't allow to reply to groups via email so resending here. Thank you for quick fix! I will try it out and report back on the process.

Dátum: pondelok 23. októbra 2023, čas: 15:07:01 UTC+2, odosielateľ: Ronald Jeninga

[Ronald Jeninga]

Hi Juraj,

we had that option (reply by e-mail) switched off.

I've switched it on now. If we don't get spam posts, I'll leave it on.

Naturally, if spam comes in (and by its nature it will then be a lot of it), I'll switch it off again.

Hence in this special case it was us to blame, not Google.

 

Best regards,

Ronald

[Juraj Bocinec]

Greetings Ronald,

seems other packages have requirements to be satisfied as well, when trying to install the schedulix-server-mariadb package i get following:

  - nothing provides mariadb-server needed by schedulix-server-mariadb-2.10-10.el7.x86_64
  - nothing provides mariadb needed by schedulix-server-mariadb-2.10-10.el7.x86_64
  - nothing provides mariadb-libs needed by schedulix-server-mariadb-2.10-10.el7.x86_64
  - nothing provides mysql-connector-java needed by schedulix-server-mariadb-2.10-10.el7.x86_64

It's again because AL2023 has different naming of packages, it's called mariadb105-server.x86_64 here and the connector is probably called mariadb-connector-c.x86_64. It seems Amazon pushed its Linux flavor further away from Centos/RHEL compatibility.

As next option i will try to compile Schedulix from source. I will send update once i achieve some progress, thank you for your effort.

Dátum: streda 25. októbra 2023, čas: 10:31:31 UTC+2, odosielateľ: Ronald Jeninga

[Ronald Jeninga]

Hi Juraj,

your next option is far simpler. Instead of installing schedulix-server-mariadb, you install schedulix-server-rmt.

The schedulix-server-rmt is created for user that want to run a DBMS system remotely.

The host where you install the scheduling server itself can be regarded a remote system as well.

A few more manual steps are required now:

1. Install a database system (e.g. MariaDB) together with a JDBC driver

2. Create a schema and populate it (see Installation Guide)

3. Modify the server.conf file and set the database related properties (DbUser, DbPasswd, DbUrl, JdbcDriver)

And that should be all. You're now ready to run.

Best regards,

Ronald

[Juraj Bocinec]

Greetings Roland,

thanks for this tip, this has saved me a lot of time! I managed to get it running with Amazon Linux 2023, the only tweak i had to do was to set the java 8 version via

alternatives --set java /usr/lib/jvm/java-1.8.0-amazon-corretto.x86_64/jre/bin/java

as i noticed by default Amazon uses java 21 and with that version schedulix server was unable to launch and crashed with error:

Unrecognized VM option 'UseConcMarkSweepGC'
Error: Could not create the Java Virtual Machine.
Error: A fatal exception has occurred. Program will exit.

Dátum: utorok 31. októbra 2023, čas: 11:20:52 UTC+1, odosielateľ: Ronald Jeninga

[Ronald Jeninga]

Hi Juraj,

great! And I have another tip for you.

If you modify the java.conf file (/opt/schedulix/etc/java.conf) and set

MEMFLAGS="-XX:+UseG1GC"

or

MEMFLAGS="-XX:+UseZGC"

instead of

MEMFLAGS="-XX:+UseConcMarkSweepGC -XX:+CMSParallelRemarkEnabled -XX:CMSInitiatingOccupancyFraction=80 -XX:+DisableExplicitGC -XX:ParallelGCThreads=4"

the server is known to run with Java 17 and will most likely run with Java 21 too.

What happened is that Oracle replaced the old garbage collector(s) with a few others.

The MEMFLAGS that are valid for Java up to (I think) 13, don't work with Java 17 and higher.

See also: https://docs.oracle.com/en/java/javase/17/gctuning/available-collectors.html#GUID-C7B19628-27BA-4945-9004-EC0F08C76003

Best regards,

Ronald

[Juraj Bocinec]

Hello Ronald, tested and working, thank you for support. You can mark this thread as solved, hopefully it will help others who might want to try Schedulix with AL2023.

Dátum: streda 1. novembra 2023, čas: 13:42:58 UTC+1, odosielateľ: Ronald Jeninga

[Ronald Jeninga]

Hi Juraj,

perfect! I'm curious to know if the system runs stable with Java 21.

But of course, that's hard to say after a single day. So maybe you can drop me a message (you can send that by e-mail or post it here) after a few months of uptime?

And for the rest: spread the word! We'd love to serve more users of our system.

Best regards,

Ronald

[Juraj Bocinec]

Greetings Ronald, i know it's more than a few months but rather late then never - i'm just popping in to let you know that we didn't observe any problems with the newer JDK. Thank you for your support.

Dátum: štvrtok 2. novembra 2023, čas: 10:56:32 UTC+1, odosielateľ: Ronald Jeninga

[Ronald Jeninga]

Hello Juraj,

sorry for the late reply.

Great to hear (well, read) that the system runs without issues with Java 21!

It means, we're ready for the future!

Thank you for the feedback.

Best regards,

Ronald