Issue 3856: Propose Remove use of Filter (ft-ftf) Source: AT&T (Mr. Robert E. Gruber, ) Nature: Uncategorized Issue Severity: Summary: Motivation: The Notifier will be easier to replicate if it is a single object. At present, all Filters created by the Notifier must also be replicated. Furthermore, there is no requirement that a Filter be destroyed by the client that created it (once it is done using it), raising a garbage collection issue. FOr a connected consumer, if the consumer no longer exists the Notifier can discard the connection. There is no analagous test for Filters. The Notifier interface is already a collapsed version of multiple CosNotification APIs to get rid of the channel/admin/proxy objects in favor of one object, so I am just proposing we carry through on that approach. Óne proposal: First, remove method create_subscription_filter. Second, change the 2 connect_foo_fault_consumer methods (connect_structured_fault_consumer + connect_sequence_fault_consumer) to take just a consumer and a grammar: ConsumerId connect_foo_fault_consumer (in CosNotifyComm::FooPushConsumer, in string constraint_grammar) raises (ÏnvalidGrammar, AlreadyConnected) One or more event forwarding constraints is associated with each connected consumer, with the default being a constraint that matches all events. The ConsumerID returned from a call can be passed into methods that modify these constraints. When a consumer is disconnected, the associated constraints are discarded. Third add methods for manipulating constraints associated with a ConsumeID: string constraint_grammar(in ConsumerID) void add_constraints(in ConsumerID, ...) void remove_constraints(in ConsumerID, ...) void remove_all_constraints(in ConsumerID) void modify_constraints(in ConsumerID, ...) ConstraintExpSeq get_constraints(in ConsumerID) where ... means the normal arguments that are in the corresponding methods in the Filter spec. The above methods correspond to the Filter methdos that are required in the current version of the spec, except I left out 2 of them, match_structured and destroy. I do not think we need to support match_structured -- only the Notifier needs to be able to do matching. destroy is not needed because there is no filter object to be destroyed. (disconnect is sufficient.) ALTERNATE PROPOSAL A simpler scheme is to associate a single constraint with each consumer. This is not very restrictive, especially when you consider that there is currently only one event type in use in the FT spec. The default would still be a constraint that matched all events. In this case the only method needed to modify this constraint is: void replace_constraint(in ConsumerID, in EventTypeSeq event_types, in string constraint_expression) Further, if we are willing to stick to the default constraint grammar, no grammar needs to be specified, which simplifies connect_foo_consumer -- not only by removing the constraint_grammar argument but also by removing the InvalidGrammar exception, which comes from CosNotifyFilter. I believe one could simplify things enough to get rid of any dependencies on CosNotifyFilter. It is not clear how important this is, but I thought I should mention the possibility. Resolution: see below Revised Text: A. Associate a single contraint with each consumer. The default would be a contraint that matched all events. B. Use the default constraint grammar, which eliminates the need to specify a grammar and results in simplification of the specification. Revised Text: Replace the text in Section 27.4.6 on page 27-73 by: The Fault Notifier propagates all events of a given format to all consumers that accept that format. While a consumer is connected to the Fault Notifier, it may use the method replace_constraint() to replace a constraint for a given sequence of event types. module FT{ interface FaultNotifier { typedef unsigned long long ConsumerId; void push_structured_fault( in CosNotification::StructuredEvent event); void push_sequence_fault( in CosNotification::EventBatch events); ConsumerId connect_structured_fault_consumer( in CosNotifyComm:StructurePushCOnsumer push_consumer); ConsumerId connect_sequence_fault_consumer( in CosNotifyComm:StructurePushCOnsumer push_consumer); void disconnect_consumer(in ConsumerId connection) raises(CosEventComm::Disconnected); void replace_constraint(in ConsumerId connection, in CosNotification::EventTypeSeq event_types, in string constr_expr); }; }; Pages 27-74 and 27-75: Remove "create_subscription_filter ... grammar identified by the in parameter." Page 27-75: Remove "The consumer may tailor ... modify_constraints() methods of the CosNotifyFilter::Filter interface." Remove from connect_structured_fault_consumer "in CosNotifyFilter::Filter filter" Remove from table "filter The reference to the filter that the Fault Notifier must use to restrict the set of events that are to be delivered to the consumer." Page 27-76: Remove "The consumer may tailor ... modify_constraints() methods of the CosNotifyFilter::Filter interface." Remove from connect_sequence_fault_consumer "in CosNotifyFilter::Filter filter" Remove from table "filter The reference to the filter that the Fault Notifier must use to restrict the set of events that are to be delivered to the consumer." Page 27-77: Replace first paragraph of Section 27.3.6.3 by "Filtering is done by the Fault Notifier based on the constraints provided by the consumer." Page 27-78: Replace the last paragraph by "Consumer, such as the Replication Manager or a consumer object created by the Replication Manager, connect to the Fault Notifier through the connect_structured_fault_consumer() and connect_sequence_fault_consumer() methods. The consumer sets the contraints for a given sequence of event types using the replace_constraint() method." Page 27-79: Remove item 4. Page 27-80: Replace item 2 by item 5 with the following rewording: "The Replication Manager invokes connect_structured_fault_consumer() with a push consumer reference as an in parameter. The Fault Notifier returns a consumer identifier to the Replication Manager." Replace the first four lines of item 3 by "The Replication Manager creates a sequence of event types and their corresponding constraint expressions, as follows: CosNotification::EventTypeSeq event_types; event_types.length(1); event_types[0].domain_name = "FT_CORBA"; event_types[0].type_name = "ObjectCrashFault"; const CORBA::string constraint_expr; constraint_expr = "$FTDomainId = 'acme.com' and $ObjectGroupId == 1 and $Location[0].id == 'myhost.acme.com'"; " Replace the first line of item 4 by "The Replication Manager invokes replace_constraint( consumer_id, event_types, constraint_expr). Make item 6 item 5 and replace modify_constraints() by "replace_constraints()" Make item 7 item 6. Actions taken: September 13, 2000: received issue May 24, 2001: closed issue Discussion: End of Annotations:===== From: "Robert E. Gruber" To: "Juergen Boldt" , "ft-ftf" Cc: "Robert E Gruber" Subject: FT-FTF Issue: Propose Remove use of Filter Date: Wed, 13 Sep 2000 15:16:48 -0400 Message-ID: <000001c01db7$29eb96e0$988ccf87@135-207-7-46.research.att.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3155.0 Content-Type: text/plain; charset="iso-8859-1" X-UIDL: pgi!!=S,e9hB'!!;>n!! Motivation: The Notifier will be easier to replicate if it is a single object. At present, all Filters created by the Notifier must also be replicated. Furthermore, there is no requirement that a Filter be destroyed by the client that created it (once it is done using it), raising a garbage collection issue. FOr a connected consumer, if the consumer no longer exists the Notifier can discard the connection. There is no analagous test for Filters. The Notifier interface is already a collapsed version of multiple CosNotification APIs to get rid of the channel/admin/proxy objects in favor of one object, so I am just proposing we carry through on that approach. Sne proposal: First, remove method create_subscription_filter. Second, change the 2 connect_foo_fault_consumer methods (connect_structured_fault_consumer + connect_sequence_fault_consumer) to take just a consumer and a grammar: ConsumerId connect_foo_fault_consumer (in CosNotifyComm::FooPushConsumer, in string constraint_grammar) raises (OnvalidGrammar, AlreadyConnected) One or more event forwarding constraints is associated with each connected consumer, with the default being a constraint that matches all events. The ConsumerID returned from a call can be passed into methods that modify these constraints. When a consumer is disconnected, the associated constraints are discarded. Third add methods for manipulating constraints associated with a ConsumeID: string constraint_grammar(in ConsumerID) void add_constraints(in ConsumerID, ...) void remove_constraints(in ConsumerID, ...) void remove_all_constraints(in ConsumerID) void modify_constraints(in ConsumerID, ...) ConstraintExpSeq get_constraints(in ConsumerID) where ... means the normal arguments that are in the corresponding methods in the Filter spec. The above methods correspond to the Filter methdos that are required in the current version of the spec, except I left out 2 of them, match_structured and destroy. I do not think we need to support match_structured -- only the Notifier needs to be able to do matching. destroy is not needed because there is no filter object to be destroyed. (disconnect is sufficient.) ALTERNATE PROPOSAL A simpler scheme is to associate a single constraint with each consumer. This is not very restrictive, especially when you consider that there is currently only one event type in use in the FT spec. The default would still be a constraint that matched all events. In this case the only method needed to modify this constraint is: void replace_constraint(in ConsumerID, in EventTypeSeq event_types, in string constraint_expression) Further, if we are willing to stick to the default constraint grammar, no grammar needs to be specified, which simplifies connect_foo_consumer -- not only by removing the constraint_grammar argument but also by removing the InvalidGrammar exception, which comes from CosNotifyFilter. I believe one could simplify things enough to get rid of any dependencies on CosNotifyFilter. It is not clear how important this is, but I thought I should mention the possibility. From: "Robert E. Gruber" To: "Barker, Thomas" , , Cc: "Robert E. Gruber" Subject: RE: Issues 3856 Date: Fri, 1 Dec 2000 10:20:10 -0500 Message-ID: <000501c05baa$319462b0$c216cf87@pong.research.att.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 Importance: Normal In-Reply-To: <5841DBD3C786D4118A0E00508BE39E98B2336B@emss35m02.owg.fs.lmco.com> Content-Type: text/plain; charset="iso-8859-1" X-UIDL: :9?!!gH5!!@0fd9jT0!! > It's simplicity was justified primarily on the basis that the > current FT spec only defines "one event type in use in the FT spec". Multiple event types can be handled by the current proposal (see below). I think the proposal as fine as it stands which is why I voted yes. -- Bob Handing Multiple Event Types ---------------------------- Suppose in the future there is an event type FT_CORBA::NewPrimary. There are 2 ways one could have a consumer filter over events of type FT_CORBA::ObjectCrashFault and also of type FT_CORBA::NewPrimary. (1) Create 2 connections Do two connect_structured_fault_consumer() calls for the same consumer and provide an ObjectCrashFault constraint for one connection and a NewPrimary constraint for the other connection. Each connection has an identifier, so there is no reason why the same consumer cannot create 2 connections. (A connection is modified/disconnected by passing in the identifier, not the consumer reference.) (2) Create 1 connection; use $type_name tests in the constraint expression. The constraint that you specify takes a list of event types (implicit OR semantics) and a single constraint expression, which is an arbitrary boolean expression. Each clause in the boolean expression could provide a test for one of the specified event types. Example: event type list = { FT_CORBA::ObjectCrashFault, FT_CORBA::NewPrimary } constraint expression = ( $type_name == 'ObjectCrashFault' and $ObjectGroupId == 1 and $Location[0].id == 'myhost.acme.com' ) or ( $type_name == 'NewPrimary' and $objectGroupId == 1 ) I did not put in $domain_name == 'FT_CORBA' tests since the example uses only one domain, but if other domains were introduced, tests over $domain_name could handle them.