Issue 2554:  Filter evaluation in pull mode (notif_service-rtf)
Source:  (, )
Nature:  Uncategorized Issue
Severity: 
Summary: Summary: It is unclear from the spec when filters are evaluated in pull mode. For
 suppliers there"s no problem as the filter is evaluated when the event
 is received. On the consumer side, the filter can either be evaluated
 when the event is entered into an internal queue (i.e. when the supplier
 proxy "receives" the event) or when the consumer decides to pull the
 event.
 
 This is only a problem when a filter constraint contains the $curtime
 reserved run-time variable. Perhaps the most intuitive for a user is
 filter evalution at pull time? However, the implications can be quite
 significant for sequence type consumers when invoking the
 try_pull_structured_events operation. The proxy will have to match all
 required events against the filters - and if there"s not enough events
 all filter results must be discarded.
 

Resolution: Added 2 sentences to 5th paragraph after constraints examples in section 2.3
Revised Text: 
Actions taken:
March 29, 1999: received issue
November 16, 1999: closed issue
Discussion: 
Synopsis: The spec does not currently state when filtering is performed in

          the case of pull-style consumers pulling events from pull-style 

          proxy suppliers. This is mainly an issue when filtering is done 

          based on $curtime. The submitter of this issue recommends that

          filtering be done when the consumer actually invokes "pull", but

          points out that the issue becomes very tricky in the case of

          sequence pull consumers invoking a "try_pull_structured_events".



Disposition: My personal recommendation is that if the spec is going to 

             specify when filtering is performed in the case of pull-style

             proxy suppliers, that it be specified to be done immediately as

             the proxy receives events (and not delay the filtering until the

             consumer invokes "pull" as recommended by the issue submitter).

             The main reason for this is to keep the implementation more

             straightforward. In general, there will be complications using the

             delayed semantic with regard to the "try_pull" varients because

             the results of "try_pull" on the same set of events would be

             variable over time if filtering is delayed until "try_pull" is

             attempted. For instance, "try_pull" may return TRUE if an event

             exist that is being filtered based on $curtime, and the event

             passes the filter when "try_pull" is invoke. Then, the consumer

             would invoke "pull" assuming an event existed, but the "pull"

             could result in the event being filtered based on $curtime. Now,

             the pull consumer would block due to no event being available

             to pull, even though the consumer had intentionally postponed

             doing "pull" until "try_pull" returned TRUE. 



             So, my recommendation would be to specify the semantic such that

             filtering is done only when the proxy supplier first queues the

             event. If this semantic is well-defined, consumers can construct

             their filters accordingly, and be aware of what will happen when

             they specify constraints based on $curtime.



VOTE: YES means to add text to the spec specifying that filtering by pull-style

      ProxySuppliers is performed prior to the proxy queuing the event to make

      it available for pulling (i.e., as soon as the Proxy receives the event).

      NO means to do nothing.
End of Annotations:=====
Date: Fri, 26 Mar 1999 08:39:50 -0600
From: Bjarne Rasmussen <br@us.prismtechnologies.com>
Organization: PrismTech Corp
To: issues@omg.org
Subject: Notification Service RTF: Filter evaluation in pull mode

Hi,

It is unclear from the spec when filters are evaluated in pull
mode. For
suppliers there's no problem as the filter is evaluated when the event
is received. On the consumer side, the filter can either be evaluated
when the event is entered into an internal queue (i.e. when the
supplier
proxy "receives" the event) or when the consumer decides to pull the
event.

This is only a problem when a filter constraint contains the $curtime
reserved run-time variable. Perhaps the most intuitive for a user is
filter evalution at pull time? However, the implications can be quite
significant for sequence type consumers when invoking the
try_pull_structured_events operation. The proxy will have to match all
required events against the filters - and if there's not enough events
all filter results must be discarded.

Best regards,
Bjarne.

--
Bjarne Rasmussen, Senior Software Engineer (M.Sc)
PrismTech Limited, http://www.prismtechnologies.com