Incident #11947
closed
Algorithms are not being installed in the RPrototypingLab
Added by Gianpaolo Coro about 7 years ago. Updated about 7 years ago.
100%
Description
I have added two algorithms through the SAI in the RPrototypingLab. The algorithms are correctly uploaded on the SVN (thus the DM Pool Manager works) but they are not being installed on the DataMiner machines (no update of the DM configuration, but the jars are present on the machine), like the installer script is not being run.
Updated by Andrea Dell'Amico about 7 years ago
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
Updated by Andrea Dell'Amico about 7 years ago
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).
Updated by Gianpaolo Coro about 7 years ago
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?
Updated by Andrea Dell'Amico about 7 years ago
- Status changed from New to In Progress
Gianpaolo Coro wrote:
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.
The dm-pool-manager should never touch the non dm servers, and it does not have access to dataminer0-proto nor any other non dm-pool dataminer
And I confirm that there are (there were) local modifications to the files.
BTW, is there a quick fix for the current issue?
I removed the local copies of the involved files:
software/ALGORITHM_PUBLISHER_interface.jar software/ITALIAN_EVENTS_RECOGNITION_NER_interface.jar software/OPEN_MESH_RECONSTRUCTOR_interface.jar software/RBLACKBOXSAMPLE_interface.jar
Now I see that a lot of algorithms are being processed (the problem existed on that machine since May).
Updated by Andrea Dell'Amico about 7 years ago
- Status changed from In Progress to Feedback
- % Done changed from 0 to 100
Updated by Gianpaolo Coro about 7 years ago
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.
Updated by Gianpaolo Coro about 7 years ago
- Assignee changed from _InfraScience Systems Engineer to Giancarlo Panichi
Updated by Andrea Dell'Amico about 7 years ago
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?
Updated by Giancarlo Panichi about 7 years ago
- Due date set to Jun 13, 2018
- Status changed from Feedback to Resolved
I confirm that dm-pool-manager only acts on the SVN so it does not create conflicts.
Since the problem is solved I close the ticket, reopen it if necessary.
Updated by Giancarlo Panichi about 7 years ago
- Status changed from Resolved to Closed
