[
https://issues.apache.org/jira/browse/CAMEL-11623?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16112424#comment-16112424
]
Mart Kartašev commented on CAMEL-11623:
---------------------------------------
I agree that in most cases it would be a bad practice and you might be correct
that it is here as well. I would like to discuss a little first, though.
I think that there are multiple types of Errors that might be relevant to catch
here. For example NoClassDefFoundError, might be relevant as the fusesource JNI
implementation is an optional include according to the POM, as is the iq80 java
implementation. So technically we could exclude either of them and expecting to
end up with an IllegalStateException instead.
Say for example that we manually exclude fusesource packages entirely. Would we
want it to fail with NoClassDefFoundError or have it catched and try the iq80
implementation?
So my point is, are we trying to make sure that we try the Java implementation
always, or only during the UnsatisfiedLinkageError?
The point about the OutOfMemoryError is inarguably a sound one however... and
catching throwable might hide some other odd problems, especially without
logging.
> LevelDB Java implementation wont be tried on Errors
> ---------------------------------------------------
>
> Key: CAMEL-11623
> URL: https://issues.apache.org/jira/browse/CAMEL-11623
> Project: Camel
> Issue Type: Bug
> Components: camel-leveldb
> Affects Versions: 2.19.2
> Reporter: Mart Kartašev
> Fix For: 2.18.5, 2.20.0, 2.19.3
>
>
> For a bit of background, we have been running into a problem with the LevelDB
> JNI drivers for AggregationRepositories, which prevents startup when using
> routes for which we require persistent aggregation. This, however, is not the
> main topic of this issue.
> In the latest version (2.19.2) the following issue has implemented a Java
> specific leveldb factory:
> https://issues.apache.org/jira/browse/CAMEL-11427
> The relevant part of the Error on startup is as follows:
> java.lang.UnsatisfiedLinkError: Could not load library. Reasons: [no
> leveldbjni64-1.8 in java.library.path, no leveldbjni-1.8 in
> java.library.path, no leveldbjni in java.library.path,
> C:\Users\atos\AppData\Local\Temp\leveldbjni-64-1-794362262645531032.8: Can't
> find dependent libraries]
> at org.fusesource.hawtjni.runtime.Library.doLoad(Library.java:182)
> at org.fusesource.hawtjni.runtime.Library.load(Library.java:140)
> at org.fusesource.leveldbjni.JniDBFactory.(JniDBFactory.java:48)
> at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
> at
> sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
>
> at
> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
>
> at java.lang.reflect.Constructor.newInstance(Constructor.java:423)
> at java.lang.Class.newInstance(Class.java:442)
> at
> org.apache.camel.component.leveldb.LevelDBFile.getFactory(LevelDBFile.java:189)
>
> at org.apache.camel.component.leveldb.LevelDBFile.start(LevelDBFile.java:174)
> The way that I understand the code added in issue 11427, is that the
> LevelDBFile class getFactory() method (line 181) will first try to initiate
> with the JNI drivers and if that fails, will turn to the pure Java
> implementation. This is done by catching an Exception which is then ignored
> incase the JNI driver fails.
> However, when we look at the code we see that UnstatisfiedLinkError does not
> extend Exception, it extends Error.
> This Error is therefore not caught by the application and thus the Java
> implementation for LevelDB is never even attempted to be initialized as the
> method execution ends exceptionally at that point.
> So the main two questions are:
> 1) Was the code intended to catch this UnsatisfiedLinkageError (I know Errors
> are often considered a bad thing to catch) as a means to substitute the JNI
> driver, incase it fails?
> 2) If it is not supposed to catch this error, how can I use the pure Java
> implementation in this case? I expect that trying to exclude relevant
> packages also wont work as it will directly try to initiate the the JNI
> implementation by its name, which would fail also with an Error.
> So, in summary:
> Is line 194 in class LevelDBFile in the camel-leveldb component supposed to
> catch an Error or more generally a Throwable instead of Exception?
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
