Bug 2049 - Structured events containing a user-defined IDL struct with an enumeration field never received by non-TAO ORBs
Summary: Structured events containing a user-defined IDL struct with an enumeration fi...
Status: NEW
Alias: None
Product: TAO
Classification: Unclassified
Component: Notification Service (show other bugs)
Version: 1.4.2
Hardware: x86 Linux
: P3 enhancement
Assignee: midnightdf
URL:
Depends on: 2048
Blocks:
  Show dependency tree
 
Reported: 2005-02-11 19:18 CST by midnightdf
Modified: 2008-02-14 01:28 CST (History)
0 users

See Also:

Attachments
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description midnightdf 2005-02-11 19:18:17 CST 
Hello, basically I have the following problem - 

1. A (TAO) structured push supplier sends an event where:  
      filterable_data[0].name="eventname"
and filterable_data[0].value contains a user-defined IDL structure:
    enum anEnum {
	APC_CORRECTED,
	APC_UNCORRECTED,
	APC_CORRECTED_AND_UNCORRECTED
    };

    struct anEvent
    {
	anEnum enumField;
    };

2. The "enumField" of "someStruct" is not explicitly setting an enumeration value:
    ncfail::anEvent data;
before being packed into a structured event.

3. (TAO) structured event consumers receive this event perfectly.

4. (omniORBPy) structured event consumers never receive this event.

5. If I explicitly set the "anEnum" field of the struct before publishing the
event, both TAO and omniORBPy structured event consumers receive the event.

Is this a problem with TAO or omniORB?

Thanks in advance for your help,

David Fugate
ALMA SW Engineer
Comment 1 pradeep 2005-03-20 17:22:09 CST 
assigning to Jeff because this bug is about the ETCL library implementation.
Comment 2 Jeff Parsons 2005-11-30 19:37:00 CST 
See comment for Bug 2048.
Comment 3 Jeff Parsons 2005-12-08 13:33:40 CST 
Accepted.
Comment 4 Jeff Parsons 2008-02-13 14:11:12 CST 
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 has had an effect on this bug?
Comment 5 Steve Totten 2008-02-13 14:45:33 CST 
(In reply to comment #4)
> 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 has had an effect on this
> bug?

Same answer as in Bug 2048:

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 would affect this use case.
Comment 6 Steve Totten 2008-02-13 14:49:03 CST 
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.
Comment 7 Johnny Willemsen 2008-02-14 01:28:15 CST 
changed to enhancement