| Summary: | No status or output from job submission | ||
|---|---|---|---|
| Product: | [Tools] PTP | Reporter: | Greg Watson <g.watson> |
| Component: | RM.PBS | Assignee: | Project Inbox <ptp-inbox> |
| Status: | RESOLVED WONTFIX | QA Contact: | |
| Severity: | enhancement | ||
| Priority: | P3 | CC: | arossi, roland |
| Version: | unspecified | ||
| Target Milestone: | --- | ||
| Hardware: | Macintosh | ||
| OS: | Mac OS X | ||
| Whiteboard: | |||
|
Description
Greg Watson
I did not realized that that component had specialized functionality according to RM ... I thought the same class handled this for every RM. I will look into it. A summary what was suggested today on the call: 1) leave the jobs in the view until either a (long) timeout or the user clicks remove terminated jobs 2) report exit code ( may be change the default template to have a way to find the exit code) 3) make sure to report difference for: scheduled, running, finished My suggestion: We should first make sure that the above things are reported by the proxy and then make sure the UI is ok. My question: should the proxy still have the terminated jobs in its model (thus not send the remove job event) or should the UI keep displaying the deleted ones? if the first: then how would the UI notify the proxy about that the user clicked remove terminated jobs. (In reply to comment #2) > My question: should the proxy still have the terminated jobs in its model (thus > not send the remove job event) or should the UI keep displaying the deleted > ones? > if the first: then how would the UI notify the proxy about that the user > clicked remove terminated jobs. There are two ways to go: 1. The proxy never sends a remove job event. The client side of the RM would need to handle the timer and removing the jobs on timeout. The UI code already handles removing the jobs when selected by the user. 2. The proxy keeps the terminated jobs in it's model and sends the remove job events after the timer expires. If the jobs have already been removed by the user, the client side would just ignore any remove jobs events for non-existent model elements. Either option seems fine to me. Superseded by new RM. |