Bar (v2) installation process is currently as follows:
It returns ready if Box exists and progress info does not exist on memcache
After the Box box is created, then progress info is created on memcache
As a consequence, if you get Box metadata right after requesting Box installation, there is an instance where "ready" is returned in spite of the fact that the box is still in installation process.
Overmore, when multiple box installations are concurrently handled, some of them may get queued and need to wait for processing. In this situation, "ready" is returned for these waiting installations.
Workaround
We need to advise users to retrieve the box metadata after waiting a while (e.g. 1 sec.) after box installation.
We also need to advise to increase the following unit configuration in accordance with the installation load so that box installations are not queued.
(Code should be changed so that the progress info is created before the box is created)
If excessive number of Box installations are handled, the time during when false "ready" is returned will get longer. It is due to the configuration of the thread pool that is in charge of executing the runner. When all the threads in the pool are occupied, then it just put the job in a queue and let it wait till an unoccupied thread gets released.
Problem Overview
Bar (v2) installation process is currently as follows:
As a consequence, if you get Box metadata right after requesting Box installation, there is an instance where "ready" is returned in spite of the fact that the box is still in installation process.
Overmore, when multiple box installations are concurrently handled, some of them may get queued and need to wait for processing. In this situation, "ready" is returned for these waiting installations.
Workaround
We need to advise users to retrieve the box metadata after waiting a while (e.g. 1 sec.) after box installation.
We also need to advise to increase the following unit configuration in accordance with the installation load so that box installations are not queued.
Remedy
Change the code so that the progress info is created before Box creation.
Details
It returns ready if Box exists and progress info does not exist on memcache
https://github.com/personium/personium-core/blob/develop/src/main/java/io/personium/core/rs/box/BoxResource.java#L205
After the Box box is created, then progress info is created on memcache
MKCOL Method Bar file (v2) request: https://github.com/personium/personium-core/blob/develop/src/main/java/io/personium/core/bar/BarFileInstaller.java#L123
BarFileInstallRunner constructor creates a Box. https://github.com/personium/personium-core/blob/develop/src/main/java/io/personium/core/bar/BarFileInstaller.java#L223 https://github.com/personium/personium-core/blob/develop/src/main/java/io/personium/core/bar/BarFileInstallRunner.java#L150
Then it returns an HTTP response immediately after asking the Box IO thread pool (ExecutorService) to execute the Runner.
The first progress info is written at the beginning of BarFileInstallRunner#run(), by executing the runner by the Box IO thread pool,
https://github.com/personium/personium-core/blob/develop/src/main/java/io/personium/core/bar/BarFileInstallRunner.java#L205
(Code should be changed so that the progress info is created before the box is created)
If excessive number of Box installations are handled, the time during when false "ready" is returned will get longer. It is due to the configuration of the thread pool that is in charge of executing the runner. When all the threads in the pool are occupied, then it just put the job in a queue and let it wait till an unoccupied thread gets released.
https://github.com/personium/personium-lib-common/blob/develop/src/main/java/io/personium/common/utils/PersoniumThread.java#L82 https://docs.oracle.com/javase/8/docs/api/java/util/concurrent/Executors.html#newFixedThreadPool-int-