Error occurred while initializing: XLog data of this log is missing

Hi,

I’m using the docker CE version of Apromore on a Azure VM. Whenever I upload a log to Apromore and afterwards turn off the VM and turn it back on and I want to open again the logs, I get the following error:
image

How can I avoid this so that I don’t have to every time reupload the logs when I turn the VM on?

I’m using docker-compose version 1.28.5, build c4eb3a1f on a linux virtual machine.
I’m using the docker comunity edition with the following versions:

  • apromore/community:7.15
  • mysql:5.7

Thanks in advance for your help,
Thomas

I suggest to stop and restart Apromore (using the start/stop script) every time you bring back the VM. This looks like a caching error due to the cache coming back in an inconsistent state. Stopping the Apromore process and restartng should solve all such caching issues.

Hi @marlon.dumas ,
Thanks for your help, but even if I don’t turn off the VM but use the start script to start the docker, upload the log and then use the stop script to stop the docker and then re-start the docker with the start script I still have the same issue…

Kind regards,
Thomas

@marlon.dumas do you have an idea how I can solve this or investigate further what happens?
Thanks in advance,
Thomas

We have been unable to reproduce this on an Azure VM with Linux Ubuntu 18.04.
The error message suggests that the temporary storage used by the cache (Ehcache) is not being deleted when the VM is restarted. Ehcache would normally store some files in /tmp (or wherever the parameter java.io.tmpdir points to). If that is emptied, the cache should be fully reset.

Hi @marlon.dumas ,
Thanks, how can I check where the parameter java.io.tmpdir points to? I guess this is inside the docker container and not on the Azure VM? Also this error happens as well when I just stop and restart the docker (without restarting the VM itself).
Or how can I manually delete the Ehcache temporary storage to test if this would solve the issue?

Thanks in advance for your help,
Thomas

If it’s a cache problem, then wiping out the /tmp folder inside the Docker container and re-starting Apromore should do the job. But I’m starting to think it’s not a cache problem after all.
A more probable cause is that, for some reason, the EventsLogRepository directory inside the Docker container was wiped out when the Docker container was stopped and restarted. In the Community Edition, the event logs are persisted in that directory (one file per event log). If you look for a directory like this: /wherever/you/keep/ApromoreDocker/Event-Logs-Repository

…can you see the .xes.gz file corresponding to the event log that cannot be opened in the Apromore portal?

Hi @marlon.dumas ,
Indeed I checked that directory and I can only see the files that come already as a part of the apromore docker github repo, but not my imported files:


So this might indicate that the docker volumes don’t work for a certain reason?

Kind regards,
Thomas

Hi @marlon.dumas

I’ve checked your docker compose file, but I see that you have mapped the volume of the Event-Logs-Repository as such:

        volumes:
              - "./site.properties:/opt/apromore/virgo-tomcat-server-3.6.4.RELEASE/repository/usr/site.properties"
              - "./Event-Logs-Repository:/opt/Event-Logs-Repository"

But when I go into the apromore docker using the following command: sudo docker exec -it apromore /bin/bash, I see that my logs are actually saved into /opt/apromore/Event-Logs-Repository.

So it’s normal that the docker bind mount does not work if it does not point to the right path. However, I tried modifying this in the docker-compose.yml, but seems that it still doesn’t work, also weird is now that if I go with : sudo docker exec -it apromore /bin/bash inside the docker and go to /opt/apromore/Event-Logs-Repository I get permissionDenied errors whenever I try to write any file.

Does this help in the investigation?

Kind regards,
Thomas

It’s not clear where the problem comes from. Let me loop back to the technical team to figure out a possible resolution - all that is needed is to map the Event-Logs-Repository directory so that it points to the right place with suitable access rights.

1 Like

There was indeed a configuration error in the docker-compose file, which resulted in the Event-Logs-Repository not been maped to the right directory (inside the docker image) where it is supposed to be. So files were being created in the Apromore portal, but the actual log was not in the right place. It worked while the cached version was in memory, but then when you stopped and started the VM, Apromore did not find the log file where it expected it.
The configuration file has now been fixed. You can pull again the Docker image and this time logs will persist in the right place:

Hi @marlon.dumas

Ah thank you very much! it works now indeed!

Kind regards,
Thomas