Para w/SqlDAO writes data, but doesn't read it back when rebooted about para

[albogdano]

🙄 I really have no clue why this happens. Debugging docker containers is not my strong side. I'll try to recreate it on my machine. Thanks for you patience!

[albogdano]

The API for rebuilding the index is yet to be released in 1.30.0 - the request is going to be POST /v1/_reindex. Currently this is only possible by calling Para.getSearch().rebuildIndex() from Java code.

[jswiesner]

Is the Sysprop actually still in your MySQL database? To help debug it would be better to check the database directly as opposed to reading through Para.

[arthmoeros]

@jswiesner in n°5 I attached a screenshot of MySQL Workbench querying the table and the Sysprop is there, I will query the database again tomorrow when I'm at work and upload the screenshot :)

[arthmoeros]

@jswiesner the Sysprop is still in the MySQL database

[albogdano]

If it's in the DB it's probably not indexed by Lucene then. Since only the Lucene index is stored inside the container, it's probably wiped clean on restart. Docker volumes - how do they work? 😃 I honestly know very little about docker volumes.

[jswiesner]

Well that explains the issue! You need to mount a docker volume that is attached to a directory on the host machine and thus persistent. This probably should be a config parameter so the user can specify which file path on the host machine should be used to mount inside the Docker container. I suggest having a read through this page: https://docs.docker.com/storage/

[arthmoeros]

@albogdano Ahhh, that must be it.

A Docker volume is basically like a remote directory (like a NFS), that is stored outside the container.

At the moment I'm not using a volume, so the container "dies" with everything stored when restarted.

There are two solutions for this, if this is the case:

1. Suggest using a volume where the Lucene information is stored, when using docker.
2. Rebuild the index (I don't know if this is possible) on start.

I will do the nº1 for now, I will leave nº2 to you if you consider it as a feature request and a more robust solution. Thanks!

[arthmoeros]

@albogdano @jswiesner

Indeed, that solved it, thanks!

Although I had to register another sysprop to test it, the old one is gone, Is there any way to re-index by reading the database (being manually or on startup)?,
What happens if I change the engine to ElasticSearch for example?

[albogdano]

Just FYI, the reindex API has been implemented now in release v1.30.0. The client libraries will be updated shortly.
Closing this for now...

[arpan-r0y]

This doesn't seem to be fixed yet. I am using Lucene as default index, even rebuilding the index does not populate the data.

[albogdano]

@arpanrnc Can you describe your issue in details? Did you perform the same steps as above? Do you have the latest version of Para and the SQL plugin for Para?

[arpan-r0y]

Hi @albogdano,

Master branch of para used (1.31.x) along with 1.31.1 build of para-sql-dao

Steps:

1. Installed para (with MySQL, Hazelcast, default lucene search) and scoold on separate VMs.
2. Created some questions using scoold.
3. Checked that the questions are persisted on MySQL.
4. Stopped para & scoold.
5. Rebuilt para from master, installed on another VM and booted.
6. No data picked up from MySQL. Data still present in MySQL
7. Rebuilt index using para client. Rebuild successful, yet no effect.
8. Disabled cached & restarted. No effect.
9. Disabled search & restarted. No effect.
10. Set flag to read from index to false. No effect.

[albogdano]

@arpanrnc Ok, I'll investigate this further and report back here...

[albogdano]

I couldn't reproduce the issue - MySQL works well with Para and Scoold.