Community
Participate
Working Groups
(First reported by Bob Fuhrer) I seem to have discovered a bug in PTP 5's handling of user settings for the OpenMPI version. When the user selects an explicit OpenMPI version, say 1.4, in our user interface, I'd later get an NPE inside the PTP because the discover/launch/debug commands hadn't been set in the OpenMPIServiceProvider. This happens even though the versionId property on the OpenMPIServiceProvider is "1.4". I tracked this down to the following: - EffectiveOpenMPIResourceManagerConfiguration's constructor always asks the IOpenMPIResourceManagerConfiguration for the "detected version", which is stored in the fields OpenMPIServiceProvider.majorVersion and minorVersion. However, if the user set an explicit version, those fields are still at their defaults (0), since no version has been "detected". As a result, the constructor fails to initialize the discover/launch/debug command fields. My proposed change is for EffectiveOpenMPIResourceManagerConfiguration to ask whether the version ID is "auto": if so, use what getDetectedVersion() returns; if not, use what getVersionId() returns. [see patch below] I'm not sure this would be consistent with the code's intent, though. On a related note: - OpenMPIServiceProvider.setVersionId() doesn't set the majorVersion and minorVersion fields. I'd think it should do so, analogously to what setDetectedVersion() does.
Yes, it does look like a bug. However, I'm a bit puzzled by what the code in the EffectiveOpenMPIResourceManagerConfiguration constructor is for, as the values seem to be already be set in OpenMPIConfigurationWizardPage#handleVersionSelected. Committing a simpler patch.
I'm less sure about the change to setVersionId(). From what I can tell, the discover command is always run regardless of the auto setting, and the major/minor versions will always be updated with the discovered values. The only difference I can see between the auto setting and selecting a version is that in the latter case if the version doesn't match the detected version, an error dialog will be displayed.
(In reply to comment #1) > Yes, it does look like a bug. However, I'm a bit puzzled by what the code in the > EffectiveOpenMPIResourceManagerConfiguration constructor is for, as the values > seem to be already be set in > OpenMPIConfigurationWizardPage#handleVersionSelected. Committing a simpler > patch. On further examination, it looks like OpenMPIConfigurationWizardPage#handleVersionSelected only sets the defaults for each version. The constructor for EffectiveOpenMPIResourceManagerConfiguration needs to check the detected version and select the correct commands for that version.
Committed fix.
