[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [provision] Spec issue #39: Iterator lifecycle management
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: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 > >--------------------------------------------------------------------- >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 > > >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]