Community
Participate
Working Groups
Reminder that we need to provide debugging support for interactive jobs launched using the new JAXB framework.
I have created a wiki page to document the launch process here: http://wiki.eclipse.org/PTP/designs/debugger_launch
Currently, only the Open MPI and MPICH2 RMs use debug launch help. For these, the routing information is obtained using the legacy process information that is generated by the AbstractToolResourceManager framework. Since JAXB does not generate process information (for scalability reasons), so I don't think launch help can (or should) be used for JAXB. Using the JAXB framework, the debug launch steps are likely to be: 1. Run a "start-debugger" command prior to the job submission in order to launch the sdm master process. 2. Submit the debug job to the target system. 3. Generate a routing file using information obtained from the target system: a. For a non batch-system interactive launch (e.g. Open MPI, MPICH2 or PE), a command must be run on the target to obtain the routing information. This command must be run after the debug job has started running. b. For a batch-system interactive launch (e.g. PBS), the command to obtain routing information will probably need to be sent as input to the interactive session. This command must be run after the interactive session has been started.
Greg, It is highly unlikely I will have time to make the implementation modifications for this before I leave. However, I can modify the XSD and generate the updated Java objects necessary to support this. How do you see this as playing out, schema-wise? IMO, it seems cleanest just to add a new command, "start-debugger" and have the command called in the JAXBcontrol in the correct place. Do we also need a "stop-debugger"? What XSD support should be there for the routing file? Al
Yes, understood. Would you do me a favor and add something to the "Environment setup" page describing how to generate the Java objects from the XSD? I've been toying with the idea of adding a command-sequence-type, which would run a series of commands sequentially (probably needs a stopOnError attribute, maybe others). The submit-interactive-debug element would then be able to be an arbitrary sequence of, say, start debugger, submit job, generate routing, stop debugger, etc. Haven't thought through all the implications yet though.
Sure, I'll try to remind myself to add the documentation on what to do for JAXB compilation (I use an external tools command). The command-sequence already exists for start-up and shut-down. All we'd have to do is generalize it to the submit command as well. I don't believe that is hard. The command-sequence by default already behaves the way you state: subsequent commands are not run if a command fails. One can expose an option to ignore this if that is desirable.
(In reply to comment #5) > Sure, I'll try to remind myself to add the documentation on what to do for JAXB > compilation (I use an external tools command). > > The command-sequence already exists for start-up and shut-down. All we'd have > to do is generalize it to the submit command as well. I don't believe that is > hard. > > The command-sequence by default already behaves the way you state: subsequent > commands are not run if a command fails. One can expose an option to ignore > this if that is desirable. Just one further thought, though: the behavior of the commands inside the control is slightly different if the command involves a jobId. start-up and shut-down sequences don't. It may be simplest not to generalize the command-sequence, but to provide for debugger start-up and shut-down specifically.
(In reply to comment #6) > (In reply to comment #5) > > Sure, I'll try to remind myself to add the documentation on what to do for JAXB > > compilation (I use an external tools command). > > > > The command-sequence already exists for start-up and shut-down. All we'd have > > to do is generalize it to the submit command as well. I don't believe that is > > hard. > > > > The command-sequence by default already behaves the way you state: subsequent > > commands are not run if a command fails. One can expose an option to ignore > > this if that is desirable. > > Just one further thought, though: the behavior of the commands inside the > control is slightly different if the command involves a jobId. start-up and > shut-down sequences don't. It may be simplest not to generalize the > command-sequence, but to provide for debugger start-up and shut-down > specifically. Another possibility is to mark a command specifically as a "submit" or "get-status" command, and treat those inside the sequence differently. I need to look at the code again, but it may not be all that much of a problem. In terms of the option, we would probably want to mark each command separately for whether it should be run if there is a preceding error or not. If you start the debugger, but the actual submit fails, you'll want to stop the debugger; but if the start-debugger fails, you won't want to submit (actually, you won't want to stop the debugger either, so there might need to be some further qualifier here ...)
(In reply to comment #7) > (In reply to comment #6) > > (In reply to comment #5) > > > Sure, I'll try to remind myself to add the documentation on what to do for JAXB > > > compilation (I use an external tools command). > > > > > > The command-sequence already exists for start-up and shut-down. All we'd have > > > to do is generalize it to the submit command as well. I don't believe that is > > > hard. > > > > > > The command-sequence by default already behaves the way you state: subsequent > > > commands are not run if a command fails. One can expose an option to ignore > > > this if that is desirable. > > > > Just one further thought, though: the behavior of the commands inside the > > control is slightly different if the command involves a jobId. start-up and > > shut-down sequences don't. It may be simplest not to generalize the > > command-sequence, but to provide for debugger start-up and shut-down > > specifically. > > Another possibility is to mark a command specifically as a "submit" or > "get-status" command, and treat those inside the sequence differently. I need > to look at the code again, but it may not be all that much of a problem. > > In terms of the option, we would probably want to mark each command separately > for whether it should be run if there is a preceding error or not. If you > start the debugger, but the actual submit fails, you'll want to stop the > debugger; but if the start-debugger fails, you won't want to submit (actually, > you won't want to stop the debugger either, so there might need to be some > further qualifier here ...) one could conceivably have something like this: <command> <on-success>command2,command3</on-success> <on-failure>command3<on-failure> </command> or something similar
I have added pre- and post-launch commands that are be invoked prior to, and immediately after the main command is launched. The syntax is: <submit-interactive-debug ...> <arg>...</arg> <stdout-parser>...</stdout-parser> <pre-launch-cmd ... /> <post-launch-cmd ... /> </submit-interactive-debug> The pre-launch commands will typically be used to clean up any debugger files. In the case of the SDM, this would be the routing file from a previous debug session. The post-launch commands will be used to perform any debugger actions after the main job is launched. In the case of the SDM, this would be a) generating a new routing file, and b) launching the SDM front-end.
Added a sample interactive RM to the contrib plugin.
