JP2K with OpenJpegProcessor and AutomaticSelectionStrategy

[vljukap98]

It seems as if my OpenJpeg processor works only when processor.selection_strategy=ManualSelectionStrategy and processor.ManualSelectionStrategy.jp2=OpenJpegProcessor.

When my cantaloupe.properties defines processor.selection_strategy=AutomaticSelectionStrategy and I try to request a jp2 image with OpenJPEG installed on my system (or via docker). The cantaloupe processing fails, actual server log doesn't show anything interesting, but the stack trace is actually included in the failed response:

500 Internal Server Error



java.lang.reflect.InvocationTargetException
	at java.base/jdk.internal.reflect.DirectConstructorHandleAccessor.newInstance(DirectConstructorHandleAccessor.java:74)
	at java.base/java.lang.reflect.Constructor.newInstanceWithCaller(Constructor.java:499)
	at java.base/java.lang.reflect.Constructor.newInstance(Constructor.java:483)
	at edu.illinois.library.cantaloupe.processor.ProcessorFactory.newProcessor(ProcessorFactory.java:100)
	at edu.illinois.library.cantaloupe.resource.ImageRequestHandler.handle(ImageRequestHandler.java:385)
	at edu.illinois.library.cantaloupe.resource.iiif.v2.ImageResource.doGET(ImageResource.java:141)
	at edu.illinois.library.cantaloupe.resource.HandlerServlet.handle(HandlerServlet.java:97)
	at edu.illinois.library.cantaloupe.resource.HandlerServlet.doGet(HandlerServlet.java:35)
	at jakarta.servlet.http.HttpServlet.service(HttpServlet.java:500)
	at jakarta.servlet.http.HttpServlet.service(HttpServlet.java:587)
	at org.eclipse.jetty.servlet.ServletHolder.handle(ServletHolder.java:764)
	at org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:529)
	at org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:221)
	at org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1381)
	at org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:176)
	at org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:484)
	at org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:174)
	at org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1303)
	at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:129)
	at org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:122)
	at org.eclipse.jetty.server.Server.handle(Server.java:563)
	at org.eclipse.jetty.server.HttpChannel$RequestDispatchable.dispatch(HttpChannel.java:1598)
	at org.eclipse.jetty.server.HttpChannel.dispatch(HttpChannel.java:753)
	at org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:501)
	at org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:287)
	at org.eclipse.jetty.io.AbstractConnection$ReadCallback.succeeded(AbstractConnection.java:314)
	at org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:100)
	at org.eclipse.jetty.io.SelectableChannelEndPoint$1.run(SelectableChannelEndPoint.java:53)
	at org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:969)
	at org.eclipse.jetty.util.thread.QueuedThreadPool$Runner.doRunJob(QueuedThreadPool.java:1194)
	at org.eclipse.jetty.util.thread.QueuedThreadPool$Runner.run(QueuedThreadPool.java:1149)
	at java.base/java.lang.Thread.run(Thread.java:1474)
Caused by: java.lang.UnsatisfiedLinkError: no kdu_jni in java.library.path: /usr/java/packages/lib:/usr/lib64:/lib64:/lib:/usr/lib
	at java.base/java.lang.ClassLoader.loadLibrary(ClassLoader.java:2285)
	at java.base/java.lang.Runtime.loadLibrary0(Runtime.java:822)
	at java.base/java.lang.System.loadLibrary(System.java:1685)
	at kdu_jni.Kdu_message.<clinit>(Kdu_message.java:5)
	at edu.illinois.library.cantaloupe.processor.codec.jpeg2000.JPEG2000KakaduImageReader.<clinit>(JPEG2000KakaduImageReader.java:197)
	at edu.illinois.library.cantaloupe.processor.KakaduNativeProcessor.<init>(KakaduNativeProcessor.java:77)
	at java.base/jdk.internal.reflect.DirectConstructorHandleAccessor.newInstance(DirectConstructorHandleAccessor.java:62)
	... 31 more

The line it fails on is

cantaloupe/src/main/java/edu/illinois/library/cantaloupe/processor/ProcessorFactory.java

Line 100 in 4e3f46c

Processor candidate = class_.getDeclaredConstructor().newInstance();

The thing I narrowed it down to is that because the KakaduNativeProcessor is defined FIRST in JP2_CANDIDATES (here:

cantaloupe/src/main/java/edu/illinois/library/cantaloupe/processor/AutomaticSelectionStrategy.java

Lines 13 to 16 in 4e3f46c

	private static final List<Class<? extends Processor>> JP2_CANDIDATES = List.of(
	KakaduNativeProcessor.class,
	OpenJpegProcessor.class,
	GrokProcessor.class);

) the instantiating fails, and the whole request fails.

I tried manually replacing the order by putting OpenJpegProcessor as the first element in JP2_CANDIDATES and the request succeeds.

Am I missing an additional configuration that should try to find anything (instead of failing on the first one) available for image processors, or defining the processor order (instead of editing the source code)?

[DiegoPino]

@vljukap98 I think this could be a documentation issue (lack of explanation of the order of evaluation + the fact that so far Kakadu is hardcoded?) *Update: I missed that you removed Kakadu already, that should have effectively removed Kakadu as a candidate and that is a BUG

Automatic implies Cantaloupe decides internally based on what is available and there is no way (so far, but also not needed) one has a configuration option to define the automatic hierarchy.

If code was handling lack of libs, and you removed Kakadu libs from your deployment (the lib completely) then OpenJpeg should have be the next best candidate. I can't find sadly any mention in the code/pulls/commits or documentation that states that Kakadu can be disabled. Which is bad. Thus the failure

This is what the docs say at https://cantaloupe-project.github.io/manual/5.0/processors.html

AutomaticSelectionStrategy
A processor is chosen automatically based on the source format, installed dependencies, and potentially other criteria, with priority given to those that are expected to be most efficient.

processor.ManualSelectionStrategy.*, as the config key states, only kicks in when Manual Selection is defined as the strategy (there is an exception though, turbojpeg... which is too deep coded into the "decoding" mechanism but that is a different story)

[jcoyne]

@DiegoPino it sounds like @vljukap98 doesn't have kakadu installed, but it's still trying to use it:

Caused by: java.lang.UnsatisfiedLinkError: no kdu_jni in java.library.path: /usr/java/packages/lib:/usr/lib64:/lib64:/lib:/usr/lib

[DiegoPino]

@jcoyne interesting mmm... true. My bad @vljukap98 . Will tag as bug and edit my comment. It is still a documentation issue because as code goes, we have no way of disabling Kakadu which is bad (and it is not documented that removing the lib will work at all)

My feels are here

This here should remove Kakadu initially if it can't construct
https://github.com/ksclarke/cantaloupe/blob/78028a21b1058655c35039339ea6bbec32eba8a8/src/main/java/edu/illinois/library/cantaloupe/processor/ProcessorFactory.java#L40

But kakadu has a try/catches if it could not initialize?

https://github.com/ksclarke/cantaloupe/blob/78028a21b1058655c35039339ea6bbec32eba8a8/src/main/java/edu/illinois/library/cantaloupe/processor/KakaduNativeProcessor.java#L123-L132

So, without too much analyzing.. are we correctly removing candidates if something fails on processor construction?

[DiegoPino]

@jcoyne this is how Turbojpeg initialization failed error was fixed 8508e93

Maybe that is the way to go with Kakadu too?

[DiegoPino]

@jcoyne @vljukap98 👀 does this help? #872

[vljukap98]

@DiegoPino #872 now works as I thought it should've worked. Initializing KakaduProcessor fails (as expected), but OpenJpeg instantiates and the image is processed.

[dfdan]

I've experienced this also. I tried a fresh build which included the above fix. However, for me at least, only the first request for a JP2K image avoids the exception, then all further JP2K requests fail in a similar way.

I am using Ubuntu 24.04 + OpenJDK 21 and am on the current develop branch.

log/traces:

The first request is serviced correctly, detecting (but not failing) when neither Kakadu or OpenJPEG are available, but finding grok2k -

20:22:44.210 [qtp1088104996-31] DEBUG e.i.l.c.s.FilesystemSource - Resolved test1.jp2 to /home/dan/cantaloupe/img/test1.jp2
20:22:44.219 [qtp1088104996-31] DEBUG e.i.l.c.p.ProcessorFactory - Failed to initialize KakaduNativeProcessor (error: no kdu_jni in java.library.path: /usr/java/packages/lib:/usr/lib/aarch64-linux-gnu/jni:/lib/aarch64-linux-gnu:/usr/lib/aarch64-linux-gnu:/usr/lib/jni:/lib:/usr/lib)
20:22:44.220 [qtp1088104996-31] INFO  e.i.l.c.p.OpenJpegProcessor - invoke(): opj_decompress
20:22:44.221 [qtp1088104996-31] DEBUG e.i.l.c.p.ProcessorFactory - Failed to initialize OpenJpegProcessor (error: Cannot run program "opj_decompress": error=2, No such file or directory)
20:22:44.221 [qtp1088104996-31] INFO  e.i.l.c.p.GrokProcessor - invoke(): grk_decompress
20:22:44.227 [qtp1088104996-31] DEBUG e.i.l.c.p.ProcessorFactory - GrokProcessor selected for format JPEG2000 (AutomaticSelectionStrategy offered KakaduNativeProcessor, OpenJpegProcessor, GrokProcessor)
20:22:44.227 [qtp1088104996-31] DEBUG e.i.l.c.p.ProcessorConnector - File -> FileProcessor connection between FilesystemSource and GrokProcessor

However all subsequent requests on JP2K images fail as below:

java.lang.reflect.InvocationTargetException
	at java.base/jdk.internal.reflect.DirectConstructorHandleAccessor.newInstance(DirectConstructorHandleAccessor.java:74)
	at java.base/java.lang.reflect.Constructor.newInstanceWithCaller(Constructor.java:502)
	at java.base/java.lang.reflect.Constructor.newInstance(Constructor.java:486)
	at edu.illinois.library.cantaloupe.processor.ProcessorFactory.newProcessor(ProcessorFactory.java:100)
	at edu.illinois.library.cantaloupe.resource.ImageRequestHandler.handle(ImageRequestHandler.java:385)
	at edu.illinois.library.cantaloupe.resource.iiif.v2.ImageResource.doGET(ImageResource.java:141)
	at edu.illinois.library.cantaloupe.resource.HandlerServlet.handle(HandlerServlet.java:97)
	at edu.illinois.library.cantaloupe.resource.HandlerServlet.doGet(HandlerServlet.java:35)
	at jakarta.servlet.http.HttpServlet.service(HttpServlet.java:527)
	at jakarta.servlet.http.HttpServlet.service(HttpServlet.java:614)
	at org.eclipse.jetty.ee10.servlet.ServletHolder.handle(ServletHolder.java:752)
	at org.eclipse.jetty.ee10.servlet.ServletHandler$ChainEnd.doFilter(ServletHandler.java:1620)
	at org.eclipse.jetty.ee10.servlet.ServletHandler$MappedServlet.handle(ServletHandler.java:1554)
	at org.eclipse.jetty.ee10.servlet.ServletChannel.dispatch(ServletChannel.java:807)
	at org.eclipse.jetty.ee10.servlet.ServletChannel.handle(ServletChannel.java:442)
	at org.eclipse.jetty.ee10.servlet.ServletHandler.handle(ServletHandler.java:469)
	at org.eclipse.jetty.server.handler.ContextHandler.handle(ContextHandler.java:1187)
	at org.eclipse.jetty.server.Server.handle(Server.java:195)
	at org.eclipse.jetty.server.internal.HttpChannelState$HandlerInvoker.run(HttpChannelState.java:680)
	at org.eclipse.jetty.server.internal.HttpConnection.onFillable(HttpConnection.java:411)
	at org.eclipse.jetty.server.internal.HttpConnection$FillableCallback.succeeded(HttpConnection.java:1809)
	at org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:105)
	at org.eclipse.jetty.io.SelectableChannelEndPoint$1.run(SelectableChannelEndPoint.java:54)
	at org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:1009)
	at org.eclipse.jetty.util.thread.QueuedThreadPool$Runner.doRunJob(QueuedThreadPool.java:1239)
	at org.eclipse.jetty.util.thread.QueuedThreadPool$Runner.run(QueuedThreadPool.java:1194)
	at java.base/java.lang.Thread.run(Thread.java:1583)
Caused by: java.lang.NoClassDefFoundError: Could not initialize class edu.illinois.library.cantaloupe.processor.codec.jpeg2000.JPEG2000KakaduImageReader
	at edu.illinois.library.cantaloupe.processor.KakaduNativeProcessor.<init>(KakaduNativeProcessor.java:105)
	at java.base/jdk.internal.reflect.DirectConstructorHandleAccessor.newInstance(DirectConstructorHandleAccessor.java:62)
	... 26 more
Caused by: java.lang.ExceptionInInitializerError: Exception java.lang.UnsatisfiedLinkError: no kdu_jni in java.library.path: /usr/java/packages/lib:/usr/lib/aarch64-linux-gnu/jni:/lib/aarch64-linux-gnu:/usr/lib/aarch64-linux-gnu:/usr/lib/jni:/lib:/usr/lib [in thread "qtp1088104996-31"]
	at java.base/java.lang.ClassLoader.loadLibrary(ClassLoader.java:2458)
	at java.base/java.lang.Runtime.loadLibrary0(Runtime.java:916)
	at java.base/java.lang.System.loadLibrary(System.java:2063)
	at kdu_jni.Kdu_message.<clinit>(Kdu_message.java:5)
	at edu.illinois.library.cantaloupe.processor.codec.jpeg2000.JPEG2000KakaduImageReader.<clinit>(JPEG2000KakaduImageReader.java:197)
	... 28 more

[vljukap98]

@dfdan The fix has been merged, but I don't think there was a release yet.

[dfdan]

I made a fresh build today from the develop branch head, which includes the merge of #872 at bb0af72 (the above errors are from that build, and its failing in a subtly different way).

[dfdan]

Sorry, my unedited comment above may have given the impression all was well. However, I believe the bug originally described above is not fully fixed with #872.

[DiegoPino]

@dfdan could you please share some trace/debug logs? I tested replicating the original configurations locally but develop has other committed (recently) changes, so can't confirm all works/not works or what you are seeing in a fresh built jar. Also #872 (comment) confirmed the change did fix his issues. Happy to dig deeper if you can provide more info/how you triggered the issue and what you are seeing. Thanks!