[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: Coordinator timeouts (was Re: Managers, addressses and the like)
Mark, I agree with your substantive point on the nature of coordinator timeout. It does not mix well with participant timeouts, on reflection. I have some questions and issues, however. I presume that the coordinator timeout is transmitted in the CONTEXT, and that it is in some way communicated to participants. I presume that services that forward the CONTEXT are allowed to trim the timeout to avoid excessive prolongation (minor point). Here's where it gets a little less obvious. If a participant gets the timeout and it expires then it is only advisory: if the participant is happy to hang around and hold resources after the expiry, that is its business. It will never go wrong, get a wrong result. It could decide to send an INFERIOR_STATUS to the coordinator, and get back an Active status, in which case it might decide to hang on. If the status messages included a timeout value then it could receive an updated timeout. In other words, this coordinator timeout could be viewed as a hint (can't really be viewed as anything else). * * * The minutes from Mt Laurel are accurate. The decision concerned participant timeouts, and is accurately recorded. The point that you raised there on participant timeouts, which was agreed to, is also recorded, namely that the PREPARE can be qualified with a "minimum upper bound" on the participant timeout, sent from the Coordinator to the Participant. There was no decision or concrete proposal about coordinator timeouts. It was mentioned in discussion, but mentioning things doesn't make them decisions, nor did the minutes attempt to record every issue that was mentioned. Every thing I minuted as agreed was read over to the meeting before a vote was taken, and before I noted it, sometimes verbatim, sometimes very close to verbatim when we hadn't arrived at the absolutely precise wording. A side comment on participant timeouts: I think that you will not avoid the need for failure recovery in participants by participant timeouts, if that is what you have in mind. Also, the motivation for participant timeouts is that a coordinator should not be able to wrest control of time-sensitive data or locks from its owner. Denial of service is only one special case of this. Expiry of offers is actually a much more likely use, in my view. Alastair
begin:vcard n:Green;Alastair J. tel;cell:+44 795-841 2107 tel;fax:+44 207-670 1785 tel;work:+44 207-670 1780 x-mozilla-html:FALSE url:www.choreology.com org:Choreology Ltd adr:;;13 Austin Friars;London;;EC2N 2JX;England version:2.1 email;internet:alastair.green@choreology.com title:Managing Director fn:Alastair J. Green end:vcard
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC