D4Science Infrastructure

On dataminer0-proto.d4science.org I see:

$ svn update
Updating '.':
Skipped 'software/OPEN_MESH_RECONSTRUCTOR_interface.jar' -- Node remains in conflict
At revision 169146.
Summary of conflicts:
  Skipped paths: 1

So it seems that someone messed on the svn local files. On the other dataminers I tested (from 1 to 5), the latest algorithms installed are:

WTG  |  Tue Jun 12 13:13:47 UTC 2018
ALGORITHM_PUBLISHER  |  Wed Jun 13 13:35:36 UTC 2018

Also, you can check /var/log/syslog to see if the script is running (it's a cron job, so if it's not run there are bigger problems), and under /home/gcube/wps_algorithms_install_log you can find the execution logs and errors (if the script does not abort before doing anything, like when the svn tree is not consistent or it is consistent and there's nothing to do).

That's strange because in the RPrototypingLab SVN commit is only managed by the Pool Manager and locally only the cron does the checkout (@g.panichi@isti.cnr.it can you confirm?) . I guess this conflict may happen if the Pool Manager uploads a new version of a jar while the cron is checking out. Generally, the latest version on SVN should win and the jar should be reverted, otherwise this kind of deadlock may occur often.

BTW, is there a quick fix for the current issue?

OK, I confirm the algorithms work now.

As for the issue: The dm-pool-manager only acts on the SVN, I know. The algorithms named ALGORITHM_PUBLISHER and RBLACKBOXSAMPLE have been created through SAI by me today, but I ensure that I did not create local copies of these jars neither for the other Jars on the DM machines. If @g.panichi@isti.cnr.it did not touch the local repository either, this situation is probably an effect of some concurrent action on the SVN that will show up again soon or later.

Gianpaolo Coro wrote:

OK, I confirm the algorithms work now.

As for the issue: The dm-pool-manager only acts on the SVN, I know. The algorithms named ALGORITHM_PUBLISHER and RBLACKBOXSAMPLE have been created through SAI by me today, but I ensure that I did not create local copies of these jars neither for the other Jars on the DM machines. If @g.panichi@isti.cnr.it did not touch the local repository either, this situation is probably an effect of some concurrent action on the SVN that will show up again soon or later.

Locally the only operation on the svn repository that I know of is the svn update run by the updater script. It can fail because of a lock while the remote repository is being written by the dm-pool manager, but that event is already handled by the script.
Is there anything else?