search

ec-jrc / re3gistry

Re3gistry is a reusable open source solution for managing and sharing ‘reference codes’, ensuring semantic interoperability across organisations.
European Union Public License 1.2
29 stars 21 forks source link

Error in migration assistant: "invalidate: Session already invalidated" #68

Closed kauk closed 1 year ago

kauk commented 2 years ago
  1. Install and configure Re³gistry2 according to manual.
  2. Choose migration option.
  3. Configure access to Re³gistry 1.3.1 DB.
  4. Start migration process.
  5. After at least one hour, an email "installation success" is sent.
  6. Directly afterwards, an email "installation error" is sent with the following content:

    Re3gistry - installation error
    An error has occurred during the Re3gistry installation, please review your settings. invalidate: Session already invalidated

jane-heller-bkg commented 2 years ago

I did a second retry for importing the database @kauk tried to import before.

I used:

After going through the installation wizard and providing it with the old database originating out of a re3gistry 1.3.1 deployment, at least a meaningful summary of registers to be imported is shown (details blanked out):

22_07_06_screenshot_re3gistry2_import1

When trying to import the data, the wizard just restarts after a short amount of time. No Email is sent - even though a functioning MTA is provided -, no information in /var/log/tomcat9/catalina.*.log (if logging is done in another place an advice would be great).

emanuelaepure10 commented 2 years ago

Dear @jane-heller-bkg & @kauk

Could you please check if the user you have set at the second step of the workflow has been stored in the database? If yes, clean the database, so please run the script https://github.com/ec-jrc/re3gistry/blob/master/dist/db-scripts/registry2_drop-and-create-and-init.sql.orig From the screenshot that @jane-heller-bkg have added seems that the old database was read correctly, but you let us know if the registers found are the ones you have in the old database v.1.3.1.

could you check the configuration https://github.com/ec-jrc/re3gistry/blob/master/documentation/administrator-manual.md from init.properties are correct.

Check as well again the mail configurations you have set up in the system. From what @kauk said seems that the mailing system is working, but than something change that stopped it working.

The log should be stored in the tomcat folder as you point out.

Feel free to contact us for a pair start up of the registry on your side Emanuela

jane-heller-bkg commented 2 years ago

Hi @emanuelaepure10,

thanks for your help in general and for your quick reply.

Could you please check if the user you have set at the second step of the workflow has been stored in the database?

Yes, I just double checked the database settings in dist/init.properties and ${tomcat}/webapps/re3gistry2/WEB-INF/classes/META-INF/persistence.xml to be valid and working from tomcat service perspective and also that the user I provided in step 2 is present in table reg_user.

If yes, clean the database, so please run the script https://github.com/ec-jrc/re3gistry/blob/master/dist/db-scripts/registry2_drop-and-create-and-init.sql.orig

After running the script, the aforementioned table is empty again as it is probably supposed to be.

From the screenshot that @jane-heller-bkg have added seems that the old database was read correctly, but you let us know if the registers found are the ones you have in the old database v.1.3.1.

Running the migration wizard again it shows all of the registers that are in the database from re3gistry 1.3 I am providing it with.

could you check the configuration https://github.com/ec-jrc/re3gistry/blob/master/documentation/administrator-manual.md from init.properties are correct.

Yes they are, except for the mail server which was not set there in the first place.

Check as well again the mail configurations you have set up in the system. From what @kauk said seems that the mailing system is working, but than something change that stopped it working.

I provided the tomcat webapp with new correct mail server settings in ${tomcat}/webapps/re3gistry2/WEB-INF/classes/configurations_files/configuration.properties. Also I double checked the mail server settings are valid by sending out test emails with the very same settings from the test server using netcat. Nevertheless no email is sent out w.r.t. to the import process. (Still it would also be very convenient if administrative messages are also provided in the main central tomcat logging at any time, because we do not have MTAs present in all our testing environments.)

The log should be stored in the tomcat folder as you point out.

I checked both /var/log/tomcat9/{catalina*,localhost.*} logs for my current try and they both remain empty. Is there another place where I should have a look?

Feel free to contact us for a pair start up of the registry on your side

Thanks for the offer. If we do not succeed here, I would contact you accordingly.

Best Regards

Jane

emanuelaepure10 commented 2 years ago

Hi Jane,

Anew news? Did you succeed to migrate it?

If not, I can only propose to debug the migration module to see where is getting stuck. In case you are not able to do that we could give a try and debug it for you, but for that we would need a copy of you v1.3 database.

Let us know what is the best for you Best regards, Emanuela

jane-heller-bkg commented 2 years ago

Hi Emanuela,

Anew news? Did you succeed to migrate it?

unfortunately the last state from 7th of July persists on my side: I was not able to find any log messages and hence could not find any information about why the migration process fails. If you have any more information about where the logging could take place or what has to be configured to get logging running I could try that.

I will contact you personally w.r.t. to the other ideas.

Best

Jane

jane-heller-bkg commented 1 year ago

Hi @oscar9,

after #218 mentioned a logfile re3gistry2.log I had a look on my test deployment and could not find a file named a such in any directory. Do I have to enable logging somewhere? Where is this file located regularily?

Maybe also my tomcat version/specific package is an issue: I rolled the thing out on tomcat9, which is put into a container by systemd on my infrastructure. Therefore only the following directories are able to be accessed by webapps:

However, I might add further direcotries by the ReadWritePaths directive in the service definition of systemd.

Greets

Jane

oscar9 commented 1 year ago

Hi @jane-heller-bkg

A quick question for now, please can you check if in any of these folders you can find some of the following tomcat logs?

catalina.XXXX-XX-XX.log host-manager.XXXX-XX-XX.log localhost.XXXX-XX-XX.log localhost_access_log.XXXX-XX-XX.txt

Re3gistry logs are going to the /logs/ folder inside the Catalina folder.

Logs are configured in two places.

You can see the folder in the first lines of that configuration. Those lines would be similar to:

property.filefolder = ${sys:catalina.home}/logs/ property.filename = re3gistry2.log

and:

property.filefolder = ${sys:catalina.home}/logs/ property.filename = re3gistry2restapi.log

Maybe you just have to set permissions for that /logs/ folder.

PD: Thanks this was the correct issue thread.

jane-heller-bkg commented 1 year ago

Hi @oscar9 ,

A quick question for now, please can you check if in any of these folders you can find some of the following tomcat logs?

Yes, the usual log files are located there (/var/log/tomcat9/ in my case):

catalina.2022-06-24.log.gz  catalina.out.10.gz  catalina.out.7.gz            localhost.2022-08-17.log.gz
catalina.2022-07-06.log.gz  catalina.out.2.gz   catalina.out.8.gz            localhost_access_log.2022-06-24.txt.gz
catalina.2022-08-03.log.gz  catalina.out.3.gz   catalina.out.9.gz            localhost_access_log.2022-07-06.txt.gz
catalina.2022-08-17.log.gz  catalina.out.4.gz   localhost.2022-06-24.log.gz  localhost_access_log.2022-07-07.txt.gz
catalina.out                catalina.out.5.gz   localhost.2022-07-06.log.gz  localhost_access_log.2022-08-03.txt.gz
catalina.out.1              catalina.out.6.gz   localhost.2022-08-03.log.gz  localhost_access_log.2022-08-17.txt.gz

Re3gistry logs are going to the /logs/ folder inside the Catalina folder.

Logs are configured in two places.

* Re3gistry2/src/main/resources/los4j2.properties.

* Re3gistry2RestAPI\src\main\resources\log4j2.properties

You can see the folder in the first lines of that configuration. Those lines would be similar to:

property.filefolder = ${sys:catalina.home}/logs/ property.filename = re3gistry2.log

and:

property.filefolder = ${sys:catalina.home}/logs/ property.filename = re3gistry2restapi.log

I double checked that those are the same as you mentioned in my source tree (but I did not compile the whole project myself when running the test, if I remember correctly).

Maybe you just have to set permissions for that /logs/ folder.

In my case the catalina home is /var/lib/tomcat9/, where logs is a symlink to /var/log/tomcat9/. The directory is owned by user tomcat and writeable for it. I double checked, that my tomcat proccess is running as user tomcat. Also tomcat can write to the other log files in the directory and hence it should not be a problem for webapps as they are running within tomcat and so within the same container.

Does the re3gistry produce any logging in catalina.*.log if it fails to open re3gistry2.log for writing?

jane-heller-bkg commented 1 year ago

Hello @oscar9,

In my case the catalina home is /var/lib/tomcat9/, where logs is a symlink to /var/log/tomcat9/. The directory is owned by user tomcat and writeable for it. I double checked, that my tomcat proccess is running as user tomcat. Also tomcat can write to the other log files in the directory and hence it should not be a problem for webapps as they are running within tomcat and so within the same container.

After changing the variable to point to /var/log/tomcat9/ directly the logfile is written by the process. I also switched to 2.4.0 and the wizard seems to start at least for now. But hence I cannot completely reconstruct, what did the trick. Still I should get an error message, if the logfile is not accessible. In general a lot of error handling seems to be missing.

e.g. SOLR seems to be not completely working in my environment and the installation wizard does not break, even though it stumbled upon an error there: [ERROR] 2022-10-24 16:12:06.067 [http-nio-8081-exec-10] [solr.SolrHandler.indexSingleItem:149] - Error from server at http://localhost:8983/solr/re3gistry2: Expected mime type application/octet-stream but got text/html. <html>

Best

Jane

jane-heller-bkg commented 1 year ago

Hi @oscar9 (and @emanuelaepure10, @jescriu :)

probably we should open new tickets for my problems now, but I will denote my recent findings here now, to have it directed to you quickly:

After digging though all the problems with missing error messages and handling I stumbled upon a problem that now seems to be associated more with the real import process and the data model itself. The error I get through the web interface is Attempting to execute an operation on a closed EntityManager.

I will attach the log file and a screenshot.

Best

Jane

22_10_25_re3gistry_migration_error re3gistry2.migration_bkg.log

jane-heller-bkg commented 1 year ago

As discussed, this issue can be closed now, as the aforementioned error is already described in #218 and the other issue is not reproducable anymore atm.

I will try to drop you additional tickets wrt. to the 2 problems about error handling I discovered.

oruscalleda commented 1 year ago

Hi @jane-heller-bkg

A solution for this issue has been developed and we are running tests to ensure it's working.

Best regards