RE: [provision] Spec issue #39: Iterator lifecycle management

["Bohren, Jeffrey" <Jeff_Bohren@bmc.com>]

An <closeIteratorRequest> would be useful but would only apply in the case
there the client does not want to retrieve further data. To be clear if an
iterate request is made on the last batch of data, there iterator should be
closed automatically (although this is certainly an implementation issue).

Jeff Bohren
BMC

-----Original Message-----
From: Gary P Cole [mailto:Gary.P.Cole@Sun.COM] 
Sent: Thursday, June 02, 2005 12:23 PM
To: provision@lists.oasis-open.org
Subject: Re: [provision] Spec issue #39: Iterator lifecycle management

Martin,

Thank you for writing this draft.  It looks excellent.  I will wait for 
any response or further comment on the list, but I will incorporate this 
into Draft 9 as quickly as possible.

Your suggestion of a <closeIteratorRequest> (which tells a provider that 
the requestor has finished with an iterated search result) seems very 
natural to me.  Many iterator implementations allow the client to 
"close" the iterator (and thus free any associated resources). 

Keeping the set of operations as small as possible is important.  
However, I believe that keeping search results open for an unspecified 
period of time is a significant resource issue for providers.  Your 
suggestion helps to address this.  In my opinion, it may be worth adding 
another request/response pair.

Jeff, what do you think?

Raepple, Martin wrote:

> @Gary: Please find below my draft text for issue #39:
>
> (Line 2571 ff) ... Storing the remaining objects allows the requestor 
> to iterate the remaining objects, but also requires the provider to 
> commit resources [DELETE (for an unspecified period of time)].
>
> (Line 2756 ff) ... Storing the remaining objects allows the requestor 
> to iterate the remaining objects, but also requires the provider to 
> commit resources [DELETE (for an unspecified period of time)].
>
> [INSERT] After the iterator has been created by the provider, the 
> requestor will only be interested in it for some finite period. This 
> period can not always be determined implicitly by the searchResponse 
> message containing the last object from the status set since the 
> requestor my not be interested in all results or simply started a new 
> query to refine the search. In any case, the provider is responsible 
> to control the lifecycle of its iterator instances in order to release 
> the resources (e.g. database connections) associated with them. 
> Otherwise, the provider may run out of resources or even be subject to 
> denial of service attacks.
>
> The PSTC recommends to follow best practices in managing these 
> resources at the provider. Since the provider cannot rely on the 
> requestor to control an iterator's lifecycle properly, the provider 
> may define a global timeout parameter that specifies the time between 
> iterator requests before the provider will invalidate and release the 
> resources assiciated with an iterator. In certain situations, this 
> strategy could still lead to a critical number of open resources at 
> the provider. Therefore, an additional lifetime parameter at the 
> provider may schedule the total amount of time after which an iterator 
> will be invalidated by the provider. To prevent denial of service 
> attacks, the requestor should provide proper authentication (see 
> security and privacy considerations in chapter 5) before any resources 
> are allocated by the provider.
>
> Upon receipt of an iterator request using an iterator ID attribute 
> value representing an invalidated iterator, the provider MUST return 
> to the requestor a <searchResponse> that specified "status='failure'" 
> (see the normative section above).
>
>
> @All: As another option to my former approach as described in [1], it 
> may be reasonable to define a very simple mechanism for the requestor 
> to let the provider (and the target) know that it does not need the 
> iterator any longer. This could be defined by a 
> <iteratorInvalidateRequest> message that only has the iterator ID 
> element. A <iteratorInvalidateResponse> will return the result of this 
> action by specifying the status attribute accordingly. Nevertheless, 
> this explicit invalidation of the provider resources triggered by the 
> requestor still requires a proper server-side resource management as 
> described above. What do you think?
>
> [1] 
>
_http://www.oasis-open.org/apps/org/workgroup/provision/email/archives/20050
5/msg00088.html_ 
>
>



---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that
generates this mail.  You may a link to this group and all your TCs in OASIS
at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php