Closed kauk closed 1 year 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):
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).
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
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
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
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
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:
/etc/tomcat9/Catalina/
/var/lib/tomcat9/webapps/
/var/log/tomcat9/
However, I might add further direcotries by the ReadWritePaths
directive in the service definition of systemd
.
Greets
Jane
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.
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?
Hello @oscar9,
In my case the catalina home is
/var/lib/tomcat9/
, wherelogs
is a symlink to/var/log/tomcat9/
. The directory is owned by usertomcat
and writeable for it. I double checked, that my tomcat proccess is running as usertomcat
. 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
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
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.
Hi @jane-heller-bkg
A solution for this issue has been developed and we are running tests to ensure it's working.
Best regards