Posting on users list as well as advised for better visibility (and
moving the thread there).
On 10/10/2022 11:59 AM, Daniil Kirilyuk wrote:
Sorry for the late reply, the dev list is used primarily for issue
update notifications and I've missed the mail with the original
question. It would probably be safer to write to the
"users@qpid.apache.org" to get the answer more quickly.
As mentioned previously we're currently working on the next Broker-J
build. It will require Java 11 as a minimal JRE version, but should
support Java 17 as well (see some discussion here:
https://lists.apache.org/thread/vn3s976v4zxbv83zc1mwpcvvzh25nst2).
Among other things we're already working on: migration of JUnit tests
to JUnit 5, migration of Jetty to the newer version, some REST API
improvements and modernization of the code base to the Java 11
standards.
Migration of unit tests would be great. Currently I am having issues
testing Qpid for native image compatibility because getting unit tests
working with a native image build has not been working well for me. I
know some things like Mokito were not supported with earlier GraalVM
releases, but I'm not sure if it is supported now. TBH, I am still
somewhat new to native image builds (more below) so that is probably
part of the issue.
Containerization as well as the native image build were also in our
(pretty far to be honest) plans. If you'd like to share your knowledge
or some parts of your work we'd appreciate it.
I'd be more than happy to share. I have my project on my GitHub here:
https://github.com/Rohan427/Qpid4Graal. It's been a learning process,
(both Qpid and GraalVM native images). It initially began with Java 11,
but the plan for the system this is being used with is to update from
Java 8 to Java 17 before the next major release. This includes many
containers (Note: We run Qpid in a container now). Prior to my update
from Java 11 to Java 17, I was able to run millions of messages (basic
topic exchange using BDB storage type) though a native image Qpid build
with no issues with the broker. It was about 80% smaller (using the
Amazon Corretto Linux container as a base) with good performance. I have
made a few modifications to Qpid to get around some build issues and I
have yet to get it to work with Derby (There may be some reflection
issues with Derby that may prohibit it from being used, but I have not
yet tackled that).
Since I am the only person on my team working with any of this or with
any experience with GraalVM and Qpid, or upgrading from Java 8 to Java
17, I will be writing a "howto" on the process once I have a fully
working native image. This all started when a performance related bug
was written and I said "Maybe GraalVm will help us with all of our micro
services and containers." So after a performance comparison (also on
Github) with a simple Spring Boot Java app built for the HotSpot Java 11
compiler and a GraalVM Java 11 native image we decided to move forward
with native images. Since Qpid is one of the major pieces of the system
as well as having dependencies that would give be greater insight into
the native image uild process, I started with that.
The two issues slowing me down is a lack of a working full regression
test suite for all the features of Qpid, including making sure every
option in the web manager works, and fighting with Maven without
breaking the regular build process. (I'm not a Maven expert, not even
close, and the company I work for is now using Gradle.) Getting an
application that uses a lot of reflection to work as a native image can
be an extended process without a good automated test suite that can
exercise every possibly code path. I have created a build script (which
still needs work) for building Qpid to support a native image in a
Docker container. (We use Linux for everything so everything in my
project is Linux based - no Windows/Mac build scripts, testing on
Windows/Mac, etc.)
Kind regards,
Daniil Kirilyuk
On Mon, 10 Oct 2022 at 20:37, Paul <pgallen...@randomlogic.com> wrote:
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org
For additional commands, e-mail: users-h...@qpid.apache.org
