[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [ptp-dev] Possible problem with job id in new job events
|
Dave,
There are actually two id's used for jobs.
The first is a regular element id, the same as the id for any other
element (node, machine, etc.) This id is generated by the proxy, and
must be unique in the model. The proxy should be able to create
unsolicited 'new job' events at any point after receiving a 'start
event's command, and these jobs will just appear in the job view.
The second id is a 'job submission id'. This id is used by the
resource manager to match up a 'job submission' command with a
corresponding 'new job' event, but otherwise plays no part in the
model. The 'job submission id' is sent as an attribute on the
submission command, and *the same value* is returned as an attribute
on the 'new job' event. If a 'new job' event does not have a 'job
submission id' attribute, then it is assumed to be an unsolicited
'new job' event. The 'job submission id' only needs to be unique
enough to distinguish between any outstanding job submissions.
As a consequence, I think the current implementation will meet your
requirements, but let me know if you have any problems.
Regards,
Greg
On Jun 11, 2007, at 8:58 AM, Dave Wootton wrote:
There may be a problem with the new job event generated by proxies in
response to a run request from a user. Currently, the new job event
contains the jobid which was passed by the front end as a parameter
in the
run command and the proxy generated id for the job object. This
works fine
in the case where the proxy is generating a new job event in
response to a
run command from the front end.
If the proxy is generating new job events for other reasons, such
as part
of proxy startup where we discover already running jobs on the
system and
want to notify the front end of their existence, then we don't have a
front end generated job id to send back in the new job event. This
also is
a problem in the case of a proxy restart, where we have the same
situation
with previously running jobs, or if we have to refresh entire state
of the
front end after a 'delete all' event has been sent.
Is there a way to inform the front end now for unsolicited new job
events,
maybe by using a jobid of -1> If not, is it possible to extend the
event
model to handle unsolicited notification of new jobs? I think the
front
end can deal already with unsolicted events for generation of other
objects (nodes, processes) since those do not have a front end
generated
identifier associated with them.
Dave
_______________________________________________
ptp-dev mailing list
ptp-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/ptp-dev
