OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

provision message

[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]