[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [provision] Spec issue #39: Iterator lifecycle management
The new "Resource Consideration" topic in draft 9 looks very good. Regarding a new <closeIteratorRequest>, I think it makes sense to give the RA at least a chance to support the provider in managing its resources. Looking at related APIs (e.g. for database connection management, memory allocation etc.) we find the same concepts. If the client misses to call a close/free/... function, the resources will (hopefully!) be released somehow by the server or operating system. Nevertheless, having at least some well-behaved clients using the new operation properly will definitely help to optimize the way resources are managed by the provider. Martin -----Original Message----- From: Gary P Cole [mailto:Gary.P.Cole@Sun.COM] Sent: Freitag, 3. Juni 2005 18:22 To: provision@lists.oasis-open.org 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 > > > --------------------------------------------------------------------- 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]