Hello Nicholas
Le 2024-12-04 à 16 h 31, Nicholas Knize a écrit :
(…snip…) Then the test harness goes to shutdown the derby memory
database and SIS threads and I'm informed of the following leaked threads:
In the list of threads that follow, I can identify the following:
* From Apache SIS:
o id=54, name=ReferenceQueueConsumer
o id=63, name=DelayedExecutor
* Apparently from Derby:
o id=57, name=derby.rawStoreDaemon
* Apparently from Java itself, maybe through the use of java.util.Timer:
o id=56, name=Timer-0
(…snip about Derby shutdown…) Here I get the following exception
thrown: java.sql.SQLNonTransientConnectionException: Database
classpath:SIS_DATA/Databases/spatial-metadata' shutdown.
Yes this is normal. Derby shutdown always throws a SQLException as per
Derby specification. It sound surprising, but it is specified that way
in their method contract.
Which gets me further, but I still have a lingering timer thread that
I can only trace to the *EPSGFactory* class.
Can you try to invoke the following method:
org.apache.sis.system.Shutdown.stop(YourClassOnlyForLoggingPurpose.class);
The above is not in public API, and its intend was to be invoked from
Servlet container or OSGi. There is classes below starting to do that in
an incubator module. They may be used as a source of inspiration:
https://github.com/apache/sis/tree/main/incubator/src/org.apache.sis.webapp/main/org/apache/sis/services
Do I really need this derby shutdown gymnastics? If so, why doesn't
SIS Shutdown class handle all this for me?
Do you mean that you already tried above-cited Shutdown.stop method and
it didn't shutdown the Derby database? If yes, this is a bug.
2. How can I gracefully shutdown the EPSGFactory timer thread? Are
there more code acrobats needed to add a special Shutdown hook to
handle this zombie thread?
Same as above. If the above-cited Shutdown.stop method was tried and
didn't worked, this is a bug that I will investigate.
(…snip…) Is there a more simple approach to using the EPSG database
that I'm missing
The embedded Derby database is currently the easiest approach. We could
provide alternatives if there are easier ones, but I don't know yet
which one it could be. A SQL database is needed (a list of CRS
definitions in a properties file is not sufficient), because the EPSG
registry is not only about CRS definitions. EPSG is also about
coordinate operations, and SIS refers to that database extensively every
times that a transform between a pair of CRS is requested.
so I'm considering just investing the time in creating a jar that
contains a simple Lucene index with the entire EPSG database so I can
query it in a disconnected deployment without having to carry this
Derby in memory SQL DB ball and chain around.
Indeed, the embedded Derby database targets one specific database
engine, and then the `sis-epsg` module provides the script for creating
the database in other environments. The rational was that if an
application already has a database, it would be unfortunate to add
another database on top of it. The `sis-epsg` module is aimed to allow
developers to use their own database engine. It could have been Lucene,
but can Lucene execute SQL scripts?
*Here are some suggestions:*
(…snip…) There are quite a few security permissions needed just to get
SIS working for a "simple" use case of reprojecting a coordinate to WGS84.
In a previous version, we were providing a security policy file, and SIS
also had some `catch (SecurityException e)` statements for execution in
security-constrained environment. Those statements have been removed in
SIS 1.4 (I do not remember if they were present in SIS 1.3). I way try
to check tomorrow. But do you have a list of the permissions that are
causing problems?
Same goes for the *eight dependencies* needed for a "simple" reprojection.
We already plan to avoid the Jakarta dependency (or make it optional),
but it may take a year.
For the OpenGIS GeoAPI dependency, actually it could be used at Lucene's
advantage. That dependency is aimed to provide an implementation-neutral
API for coordinate operations, like JDBC provides an
implementation-neutral API for databases. If the code can use only
org.opengis interfaces as much as possible, it should be possible to not
depend explicitly on SIS, but give the choice to users. Proj4J do not
implement those interfaces yet, but it would be easy to do. Proj4J has
limited capabilities, but it may be sufficient for 2-dimensional
operations when errors up to 3 kilometers does not matter. SIS could be
used when centimetric precision is desired, or for n-dimensional operations.
Another part of the dependency is the metadata package, which is indeed
as large as the referencing part. But it would be worth to put some
parts of it to user's attention. In particular, the following code:
return CRS.findOperation(fromCRS, toCRS, bbox).getMathTransform();
Should not invoke getMathTransform() so fast and paid some attention to
the CoordinateOperation object. In particular, the domain of validity
and the accuracy should, if possible, be reported to the user in some way.
Martin
