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: Comments on search and iterator


Title: Comments on search and iterator

Two comments on the search and iterator operations:

1. The iterator will allow the requestor to step through a result set when a search query matches more objects that the provider can place directly in the response. Line 2573 of draft 0.08 says that the provider is required to commit the resources for an unspecified period of time. In a situation where many iterators are kept alive/open by the provider and the targets (e.g. due to inactivity by the requestors), the amount of resources / memory will increase constantly and the overall performance will be affected. The system will also be vulnerable to denial of service attacks.

I think the spec should recommend a strategy how to deal with this issue. I see two options (which may also be combined):

- Definition of a iteratorTimeout parameter: Just like the timeout value for a HTTP session in a servlet container, this parameter will specify the time, in seconds, between iterator requests before the PSP / Target will invalidate (destroy and release resources of) the iterator. A negative time may indicate the iterator should never timeout.

- Definition of a iteratorLifetime parameter: This is to set a maximum value of a iterator's lifetime (again in seconds), independant of any requests sent by the RA.

Both parameters could be optional attributes of the searchRequestType. iteratorLifetime should overrule iteratorTimeout. If none is set by the requestor, default values for these parameters (e.g. set at bootstrap time) should apply.

2. In SPML 1.0 there is the possibility to constrain the target schema elements / attributes returned in the result by using the <attribute> element in the searchRequest. Since this is a reasonable feature and the returnData attribute of the searchRequestType does not yet provide a comparable functionality, I would suggest to include this feature in 2.0 again.

Martin



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]