TASK-6565 Ensure the CellBase DB adaptors are updated to reflect the latest data releases

[jtarraga]

TASK-6565

[j-coll]

Improper exception reporting. The whole exception should be the last element of the logger.

LOGGER.warn("Exception from handle document change function", e);

Also, might want to add more details on the collection watcher that failed.

[j-coll]

And what if the whole collection.watch()... fails? The whole code of the thread should be within a pseudo infinite loop, catching any Exception, and check for thread interruptions within the loop

while (!Thread.currentThread().isInterrupted()) {
  try {
     MongoCursor iterator = collection.watch().fullDocument(FullDocument.UPDATE_LOOKUP).iterator();
     while (!Thread.currentThread().isInterrupted() && iterator.hasNext()) {
        // ...
     }
  } catch (Exception e) {
    LOGGER.warn("...", e);
  }
}

[jtarraga]

Improper exception reporting. The whole exception should be the last element of the logger.

LOGGER.warn("Exception from handle document change function", e);

Also, might want to add more details on the collection watcher that failed.

maybe it's better to display the strack trace, e.g.:
LOGGER.warn("Exception from handle document change function: {}", Arrays.toString(e.getStackTrace()));

[j-coll]

Having the exception as the last argument in a logger will print the whole stacktrace

        try {
            throw new RuntimeException("myException");
        } catch (Exception e) {
            logger.warn("This is an exception", e);
        }

2024-08-08 12:03:27 [main] WARN  VariantQueryExecutorTest:59 - This is an exception
java.lang.RuntimeException: myException
	at org.opencb.opencga.storage.core.variant.query.executors.VariantQueryExecutorTest.setUp(VariantQueryExecutorTest.java:57) ~[test-classes/:?]
	at org.opencb.opencga.storage.hadoop.variant.query.executors.HadoopVariantQueryExecutorTest.setUp(HadoopVariantQueryExecutorTest.java:25) ~[test-classes/:?]
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) ~[?:1.8.0_161]
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) ~[?:1.8.0_161]
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) ~[?:1.8.0_161]
	at java.lang.reflect.Method.invoke(Method.java:498) ~[?:1.8.0_161]
	at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:59) ~[junit-4.13.2.jar:4.13.2]
	at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12) ~[junit-4.13.2.jar:4.13.2]
	at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:56) ~[junit-4.13.2.jar:4.13.2]
	at org.junit.internal.runners.statements.RunBefores.invokeMethod(RunBefores.java:33) ~[junit-4.13.2.jar:4.13.2]
.....

[j-coll]

All these threads should be within a single "ExecutionService". Then, as this is a singleton class, and can't be closed easily, a ShutdownHook should terminate the ExecutionService

    Runtime.getRuntime().addShutdownHook(new Thread(() -> {
        threadPool.shutdownNow();
    });

[j-coll]

This would be an unneeded lock if dbInfo.getCacheData().containsKey(release) and dbInfo.getCacheData().get(release).containsKey(data). Given that this method will be called a lot of times, might be worth improving the logic?

[j-coll]

Do you actually need a ReentrantReadWriteLock? Why not using a ReentrantLock?

[j-coll]

I'd still have here a !Thread.currentThread().isInterrupted()