[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [ptp-dev] Possible addition to PTP 2.0 todo list
|
Dave,
I don't see a problem with what you're asking. The client (Java) side
already supports remove events for every type of model element. I
think I had intended to provide a proxy remove event, but just never
needed it with the ORTE proxy.
As far as the node numbering is concerned, it is totally up to the
server side to determine the numbering using the nodeNumber
attribute. This attribute has no intrinsic meaning in the model. The
only places the node number is used is for the tooltip popup when you
hover over a node, and the node attributes panel. Both of these will
display anything you supply. The node number is also used for the
ruler on the left side of the nodes view, but I think it can deal
with gaps in the numbering.
While we're on the topic of events, I'd like to propose the following
changes to the proxy events. Currently, when an error occurs (e.g.
job submission fails for some reason, or the proxy does not start
properly), the proxy sends a MESSAGE event back to Eclipse. The event
has a value that indicates the level of the error (FATAL, ERROR, etc.)
Instead of this general message event, I'd like to have a specific
event types for errors. Currently they would be:
IProxyRuntimeInitErrorEvent
IProxyRuntimeModelDefErrorEvent
IProxyRuntimeStartEventsErrorEvent
IProxyRuntimeStopEventsErrorEvent
IProxyRuntimeSubmitJobErrorEvent
IProxyRuntimeTerminateJobErrorEvent
In other words, each command would have a corresponding error event.
As we add more commands, there would need be a corresponding error
event for the command.
The general message events would still remain, but would be used for
message logging rather than error indication.
Let me know if anyone has objections to this. Otherwise I'll go ahead
and add the code.
Greg
On May 29, 2007, at 7:01 AM, Dave Wootton wrote:
I have a possible addition to the 2.0 todo list. I think that
events to
signal the deletion of model objects are needed, at least for nodes
and
jobs.
With one of my resource managers, new nodes are added to a machine
as the
host list file specifying those nodes is processed, since that is
the only
place I have any information about which nodes exist within the
machine
(cluster). When the job completes, I'd like to remove those nodes
from the
machine view if I have no other jobs using those nodes. Note that this
could result in gaps in node numbering, since I may have one job
running
using nodes 0-7 and another job using nodes 0-3, and a third using
nodes
4-7. If the first two jobs complete before the third, then at the time
just the third job is running, I would have deleted nodes 0-3.
Would that
cause problems with node numbering in the front end? Would it be a
problem
if these node numbers got reused, maybe for different nodes?
With another resource manager, it's possible to either cancel a job
before
it starts, or migrate it to a different machine (cluster) before it
starts. In those cases, I'd like to delete the job out of the queue
for
the machine the job was initially submitted to rather than laeving
it in
the queue.
The other alternative is to put the affected nodes or jobs into a
special
state (unavailable for nodes, maybe canceled for jobs), but I think
that
may leave the display cluttered.
Dave
_______________________________________________
ptp-dev mailing list
ptp-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/ptp-dev
