Ira,
> On Nov 26, 2014, at 11:51 AM, Ira McDonald <blueroofmusic at gmail.com> wrote:
>> Hi Mike,
>> For operation (3) DeregisterOutputDevice, I was thinking of the case
> where a running service (Print in the near term) crashes (and this is
> noticed by System Service, let us hope). If DeregisterOutputDevice
> is (redundantly) supported by the System Service, then an Administrator
> could do the cleanup for the Infrastructure Printer (who might queue
> jobs).
Presumably DeregisterSystem is the way for the System service to clean up references to the output device in all services it manages, even those that have "crashed" (which is a state we don't really model semantically...) If you want to deregister from a single service, you talk to that one service.
> Or, I'm crazy, and the System Service would automatically do this
> cleanup internally and no external operation needs to be exposed.
> But that risks a Deregister when the crashed service can be
> successfully automatically restarted by the System Service after
> a brief interval of unavailability.
I would assume that self-healing of this sort would be expected of a cloud/SDN solution, with notifications sent to the relevant admin/operator. And I don't think we can necessarily recover from all situations like this - the Proxy might well have gotten a response from its Deregister-Output-Device request, with the cloud service crashing after successfully sending a response, so we have to hope that implementations will provide a way to perform manual cleanup as needed...
> I have mixed feelings about the reliability (and advisability) of
> automatic recovery by the System Service for crashed or stalled
> Job Services.
Typically servers will be restarted a certain number of times in order to provide continuous service, with an alert going out for each crash/failed restart. And such things are typically configurable by service and various events - I have such things setup with our PWG.org <http://pwg.org/> server instance, for example...
_________________________________________________________
Michael Sweet, Senior Printing System Engineer, PWG Chair
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.pwg.org/pipermail/ipp/attachments/20141201/040b57b2/attachment.html>