That's true. A <closeIteratorRequest> would help only when a requestor
wanted to abandon search results that the requestor had not finished
iterating, and would help only when the requestor is *well-behaved*.
This is nice, but does not really address the general problem (which
would assume large numbers of requests from clients that are not
necessarily well-behaved).
Is it worth having a <closeIteratorRequest> (so that a well-behaved
client will have a way to tell a provider it's okay to free a search
result), or should we just let the search result expire "naturally"?
Bohren, Jeffrey wrote:
>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:]
>Sent: Thursday, June 02, 2005 12:23 PM
>To:
>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
>
>---------------------------------------------------------------------
>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
>
>
>
