In Docker, can't run a harvesting job, com.sun.aas.instanceRoot

[pdurbin]

If you try to run the API test suite against Dataverse when running in Docker you will notice that HarvestingClientsIT#testHarvestingClientRun will fail.

The expected error in server.log (again, only when Dataverse is running in Docker) is something like this:

dev_dataverse> Caught exception running an asynchronous harvest (dataverse "h85b8d3b"): java.nio.file.NoSuchFileException|#]

(If you edit the code to print out the exception you see something like this: : ../logs/harvest_h85b8d3b_2023-08-01T18-33-45.log.lck)

This is because HarvesterServiceBean.java uses ../log to find domain1/logs which doesn't work in Docker. Using System.getProperty("com.sun.aas.instanceRoot") seems to fix it.

This has been discussed in Slack at https://iqss.slack.com/archives/C010LA04BCG/p1690912135247139 where @landreev and I decided to put the fix in the Paraya 6 PR: 8efb964

I'm going to mark that Payara 6 PR as closing this issue.

It's still a problem in develop/5.13/5.14 but since this only affects Dataverse running in Docker we can live with it.

Note that there are many places in the code where we use this ../log trick or similar. We can open issue for these as we find them.

[poikilotherm]

I'm voting to make this a configurable location, defaulting to the variable you mentioned.

The reason for this: it is a very very bad idea to write log files into the overlay filesystem of the image. The path inside the image for the logs dir is not very readable or convenient, so it would be better to make it point to some place else.

We could use MPCONFIG for this. By default profile, let it be the instance root.
Plus, add a ct profiled setting, point to a place sub /dv.

[pdurbin]

@poikilotherm sounds fine but we'll need a new issue for that.

[DominikWA]

I know this issue is closed. We use the docker version 5.13 and run in to the same problem. Since V6 is not dockerized now and we rely on using docker for dataverse I would like to temporary fix the problem without recompiling the code. From my point of view a hacky way would be so create a
symlink for the correct log folder, where the relative path call is started to give to code the right folder. I would just need to know in which path the script is stared to create the symlink . Do you know this?

Nervermind this is the fix for my scenario:
Bash in the container:
cd /opt/payara && ln -s /opt/payara/appserver/glassfish/domains/domain1/logs logs

[poikilotherm]

I just created #10042 to track a non-hacky solution for this @DominikWA

[Nikos-Askitas]

I know this issue is closed. We use the docker version 5.13 and run in to the same problem. Since V6 is not dockerized now and we rely on using docker for dataverse I would like to temporary fix the problem without recompiling the code. From my point of view a hacky way would be so create a symlink for the correct log folder, where the relative path call is started to give to code the right folder. I would just need to know in which path the script is stared to create the symlink . Do you know this?

Nervermind this is the fix for my scenario: Bash in the container: cd /opt/payara && ln -s /opt/payara/appserver/glassfish/domains/domain1/logs logs

This might be useful for other folk who are on docker, like we are, until a comprehensive solution is in place for generic and "dockerized" dataverse instances.

[pdurbin]

@Nikos-Askitas hmm, should we document this somewhere? Maybe @4tikhonov could add it to the README at https://github.com/IQSS/dataverse-docker ? In that case, an issue in that repo would be appropriate.

To both @Nikos-Askitas and @DominikWA (and anyone reading this) you are very welcome to join the Containerization Working Group meetings. We have another one tomorrow: https://ct.gdcc.io . Dataverse 6 is containerized, but only for development for now. That said, we'd love to hear what your needs are! ❤️