Opened 7 years ago
Closed 7 years ago
#1601 closed defect (fixed)
Petascope_Error with loading GDAL native library when redeploying web application to Tomcat
Reported by: | Bang Pham Huu | Owned by: | bpham |
---|---|---|---|
Priority: | major | Milestone: | 9.5 |
Component: | petascope | Version: | development |
Keywords: | gdal native, jni, shared library | Cc: | Dimitar Misev, Vlad Merticariu |
Complexity: | Medium |
Description (last modified by )
From version 9.5, Petascope uses GDAL native library (gdal_java package, path in Centos 7: /usr/lib/java/gdal) and this must be loaded to JVM (Tomcat) by Classloader manually. However, when registering the GDAL native library once time when installing new Petascope, it does not allow to add this native library when rasdaman.war is redeployed, then, new Petascope cannot start without restarting Tomcat.
Caused by: java.lang.UnsatisfiedLinkError: Native Library /usr/lib/java/gdal/libgdaljni.so already loaded in another classloader
It cannot be solved easily by checking if gdal native library is loaded as it will have another error which is it cannot link the shared library (libgdaljni.so).
Caused by: java.lang.UnsatisfiedLinkError: org.gdal.osr.osrJNI.new_SpatialReference__SWIG_1()J
This is a problem with Java JNI Classloader and no fix for it. I found a workaround on the Internet which will resolve the problem by doing a trick.
As Classloader will need the full path to gdal native library (/usr/lib/java/gdal) so when starting Petascope, it will not use this path to register to Tomcat. Instead, it will copy this folder to /tml/rasdaman/gdal_java/timestamp (size is 440 kb) and register to JVM.
When the application restarts, it will remove the old folder and override the registered path in JVM with the new path, Hence, JVM will not throw an exception when it checks this path is already loaded.
Change History (2)
comment:1 by , 7 years ago
Description: | modified (diff) |
---|
comment:2 by , 7 years ago
Resolution: | → fixed |
---|---|
Status: | new → closed |