Please report new issues athttps://github.com/DOCGroup
Hello, basically I have the following problem - 1. A structured push supplier sends an event where: filterable_data[0].name="eventname" and filterable_data[0].value contains a user-defined IDL structure: struct someStruct { long aLong; }; 2. A CosNotifyFilter::Filter object is created using a CosNotifyFilter::ConstraintExpSeq based on the ETCL expression "$eventname.aLong < 7". Looking over the OMG Notification Service specs this is a valid expression for an IDL struct in filterable_data I believe. 3. This Filter object is added to a structured push consumer object's proxy supplier. Before the filter was applied, all the events subscribed to were being received correctly. 4. After the filter has been applied, no events are received regardless of the value of the "aLong" field of "someStruct". That is, it can be 3 or 10 (less than 7 and greater than 7 respectively), yet no events are received. 5. If I replace filterable_data[0].value with a CORBA long and change the ETCL expression to "$eventname < 7", the filter works as I would expect it too. It just seems to not work correctly for complex IDL types. I'm guessing that the filtering functionality I need is not built into TAO's implementation of the Notification Service based on the fact the NS does not use rely upon the interface repository. Is this assumption correct? Thanks in advance for your help, David Fugate ALMA SW Engineer
assigning to Jeff because this bug is about the ETCL library implementation.
It's been a few years since I worked on this. It's possible that ETCL was never tested for anything besides basic types.
Oops, forgot to reassign to my current email address.
Accepted.
Here's what is likely a related problem reported by Venkatraman Dhamodhran <ramandv@gmail.com>: -------------- IMHO, probably some mismatch between Notification Service Specification (October 2004 Version 1.1 formal/04-10-11) and implementation of Notification service. (if my understanding is correct) SYNOPSIS: [Brief description of the problem] DESCRIPTION: As per Notification Service Specification (October 2004 Version 1.1 formal/04-10-11) Section 2.3 "However, if event types are specified in the sequence, then only these types will be matched, and any additional types that are specified using constraints may never be matched (since the constraint will only be evaluated if the types in the sequence match)." As per my understanding, if I create a filter with some specific event types (say type_name = A ) and empty constraint expression, I should get only "A type events" from the event channel. Coding: -------- Relevent Steps: Step 1: Creating filter with filter grammer "EXTENDED_TCL" Step 2: create CosNotifyFilter::ConstraintInfoSeq with specific event_type [ A ] and empty constraint expression Step 3: Add the above constraints to filter. Step 4: Add the above filter to CosNotifyChannelAdmin::ConsumerAdmin. Output contradiction: --------------------- I am getting all the events instead of specific event_type [A] <<Note: code snippet and output at the bottom>> REPEAT BY: case 1: For TAO VERSION: 1.4.1; 1.4a_p1 client,server and services on SOLARIS case 2: For TAO VERSION: 1.4.8 client,server and naming service on SOLARIS Notification service on windows 2000 SAMPLE FIX/WORKAROUND: The desired output can be achieved by the following steps Step 1: Create filter with empty event_types and empty constraint expression. Step 2: CosNotifyComm::subscription_change(added,removed) here, "added " (CosNotification::EventTypeSeq) should contain specific event_type [A] code snippet -------------- // Get a FilterFactory CosNotifyFilter::FilterFactory_var filterFactory = m_eventChannel->default_filter_factory(); const char* filterGrammar = "EXTENDED_TCL"; CosNotifyFilter::Filter_var filter; try { filter = filterFactory->create_filter(filterGrammar); CosNotification::EventTypeSeq added(1); added.length(1); added[0].domain_name = CORBA::string_dup("domain1"); added[0].type_name = CORBA::string_dup("typeA"); CosNotifyFilter::ConstraintExpSeq constraintList (1); constraintList.length (1); constraintList[0].event_types = added; constraintList[0].constraint_expr = CORBA::string_dup (""); cout <<"Domain name of the eventype to be filtered : " <<constraintList[0].event_types[0].domain_name <<endl; cout << "Type_name of the eventtype to be filtered : "<<constraintList[0].event_types[0].type_name <<endl; CosNotifyFilter::ConstraintInfoSeq_var infoSeq = filter->add_constraints(constraintList); cout << "typename of the eventtype from the Infoseq [obtained after add_constraints()] : " <<infoSeq[0].constraint_expression.event_types[0].type_name << endl; CosNotifyFilter::FilterID filterID = m_consumerAdmin->add_filter( filter.in()); cout << "filterID: " << filterID << endl; //Just for debugging//start CosNotifyFilter::Filter_var tfilter; tfilter = m_consumerAdmin->get_filter(filterID); CosNotifyFilter::ConstraintInfoSeq_var tinfoSeq = tfilter->get_all_constraints(); cout << "typename of the eventtype from the Infoseq [obtained after get_all_constraints()] : " <<tinfoSeq[0].constraint_expression.event_types[0].type_name << endl; //Just for debugging//end } OUTPUT: ------- Domain name of the eventype to be filtered : tmf_mtnm Type_name of the eventtype to be filtered : typeA typename of the eventtype from the Infoseq [obtained after add_constraints()] : typeA filterID: 1 typename of the eventtype from the Infoseq [obtained after get_all_constraints()] : typeA Thanks in advance, Regards, Venkatraman.D
Johnny Willemsen asked me to reassign this one. Could someone at OCI just take a quick look and see if any of the work you've done on the Notification Service has had an effect on this bug?
(In reply to comment #6) > Johnny Willemsen asked me to reassign this one. Could someone at OCI just take > a quick look and see if any of the work you've done on the Notification Service > has had an effect on this bug? I don't think so. Our changes to the Notification Service generally fall into these categories: - Stability changes (fixed memory leaks, thread leaks, race conditions, etc.) - Implementation of Reliability QoS (ConnectionReliability, EventReliability) - Addition of a separate ORB for dispatching (so event dispatching to consumers is separated from request processing and handling of incoming events) - Addition of monitoring and control interfaces I don't believe we have made any changes that affect how event filtering works.
Reassigned this bug back to the reporter. If this feature is needed and you would like to sponsor or contribute its addition to TAO's Notification Service, we would be glad to help.
changed to enhancement