Notification Service Avatar
  1. OMG Specification

Notification Service — Closed Issues

  • Acronym: NOT
  • Issues Count: 25
  • Description: Issues resolved by a task force and approved by Board
Closed All
Issues resolved by a task force and approved by Board

Issues Summary

Key Issue Reported Fixed Disposition Status
NOT12-25 Semantics of Timeout Value NOT 1.1 NOT 1.2 Resolved closed
NOT12-24 Clarify Handling of Priority and Timeout NOT 1.1 NOT 1.2 Resolved closed
NOT12-15 Semantics of Disconnected exception NOT 1.1 NOT 1.2 Resolved closed
NOT12-14 Filter evaluation in pull mode NOT 1.1 NOT 1.2 Resolved closed
NOT12-21 TimeBase::UtcT where TimeBase::TimeT is needed NOT 1.1 NOT 1.2 Resolved closed
NOT12-20 CosNotifyChannelAdmin module: typed proxies not defined in ProxyType enum NOT 1.1 NOT 1.2 Resolved closed
NOT12-17 To add to "Reliablity" text, Page 54 after paragraph 3. NOT 1.1 NOT 1.2 Resolved closed
NOT12-16 Modify the DiscardPolicy text, paragraph 1 page 56 NOT 1.1 NOT 1.2 Resolved closed
NOT12-19 Modify paragraph 6, page 52 NOT 1.1 NOT 1.2 Resolved closed
NOT12-18 Modify RejectNewEvents description, paragraph 8 page 56 NOT 1.1 NOT 1.2 Resolved closed
NOT12-23 Problem with Sequence Pull Model NOT 1.1 NOT 1.2 Resolved closed
NOT12-22 Pull Methods on Sequence Suppliers NOT 1.1 NOT 1.2 Resolved closed
NOT12-11 CosNotification -- MaxEventsPerConsumer = 0 for infinity? NOT 1.1 NOT 1.2 Resolved closed
NOT12-10 Unnecessary restriction defined on Mapping Filters NOT 1.1 NOT 1.2 Resolved closed
NOT12-2 The term name-value pair is not well defined NOT 1.1 NOT 1.2 Resolved closed
NOT12-1 Notification Constraint language problem NOT 1.1 NOT 1.2 Resolved closed
NOT12-9 Inconsistency on p 54 NOT 1.1 NOT 1.2 Resolved closed
NOT12-8 Explicit statement missing in contraint grammar NOT 1.1 NOT 1.2 Resolved closed
NOT12-4 The section 2.4.5 NOT 1.1 NOT 1.2 Resolved closed
NOT12-3 Footnote on page 34 NOT 1.1 NOT 1.2 Resolved closed
NOT12-6 Not all references to event types have been updated NOT 1.1 NOT 1.2 Resolved closed
NOT12-5 Issue with the algorithm for evaluating $ expressions NOT 1.1 NOT 1.2 Resolved closed
NOT12-13 EventType IDL typos NOT 1.1 NOT 1.2 Resolved closed
NOT12-12 Default values for PacingInterval and MaximumBatchSize QoS properties? NOT 1.1 NOT 1.2 Resolved closed
NOT12-7 Text on p. 54 describing applicability of EvenReliability QoS out of date NOT 1.1 NOT 1.2 Resolved closed

Issues Descriptions

Semantics of Timeout Value

  • Key: NOT12-25
  • Legacy Issue Number: 2743
  • Status: closed  
  • Source: Anonymous
  • Summary:

    The issue author claims that the spec does not explicitly state

    when the service starts the "clock" with respect to an event's

    Timeout value. One possibility would be to start the clock as soon

    as the event enters the channel (i.e, at the receiving

    ProxyConsumer). Another would be to start the clock when the event

    is queued for delivery at the ProxySupplier.

  • Reported: NOT 1.1 — Wed, 16 Jun 1999 04:00 GMT
  • Disposition: Resolved — NOT 1.2
  • Disposition Summary:

    fixed, see below

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Clarify Handling of Priority and Timeout

  • Key: NOT12-24
  • Legacy Issue Number: 2740
  • Status: closed  
  • Source: Anonymous
  • Summary:

    The issue author describes the various ways that the Priority

    and Timeout QoS properties can be influenced, and mentions that

    the spec is too vague about the interactions between the various

    mechanisms. Specifically, the issue author enumerates the following

    problems in the spec with respect to this issue:

    1) If the StructuredEvent specifies a Priority/Timeout, and the

    ProxyConsumer specifies a Priority/Timeout, which one "wins"?

    2) Setting Priority/Timeout on a SupplierAdmin or on the Channel

    is only enabled to be inherited down to a ProxyConsumer, and not

    to have any actual effect. The spec does not state this.

    3) Setting Priority/Timeout on a ConsumerAdmin or ProxySupplier should

    be made illegal (cause UnsupportedQoS with UNSUPPORTED_PROPERTY

    error code to be raised).

    4) If a StructuredEvent does not contain a Priority/Timeout, does

    having this property set on the ProxyConsumer affect the contents

    of the StructuredEvent, or just the way the StructuredEvent is

    treated with respect to these properties.

    5) In the case that a Mapping filter is associated with a

    ProxySupplier, and its constraints all evaluate to FALSE for a

    particular event, does the "default_value" or the value for

    Priority/Timeout associated with the ProxyConsumer take precedence?

  • Reported: NOT 1.1 — Wed, 16 Jun 1999 04:00 GMT
  • Disposition: Resolved — NOT 1.2
  • Disposition Summary:

    Only 2740d passed

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Semantics of Disconnected exception

  • Key: NOT12-15
  • Legacy Issue Number: 2555
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: It would be nice if the spec explicitly stated what happens when a pull
    supplier or push consumer raises the Disconnected exception. One way to
    look at it is that when the client raises Disconnected it no longer
    wants to send or receive any events and it"s basically disconnected
    (i.e. the same as if the disconnect_xx_yy operation was invoked).

    I believe this is an issue because the disconnect_xx_yy operation
    controls the lifecycle of the proxy. If the above interpretation is
    valid, the proxy will be destroyed when the client raises Disconnected.
    Alternatively, the proxy could just change its state back to not
    connected (the same state as when the proxy was just created by an admin
    object).

  • Reported: NOT 1.1 — Mon, 29 Mar 1999 05:00 GMT
  • Disposition: Resolved — NOT 1.2
  • Disposition Summary:

    resolved, see below

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Filter evaluation in pull mode

  • Key: NOT12-14
  • Legacy Issue Number: 2554
  • Status: closed  
  • Source: Anonymous
  • 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.

  • Reported: NOT 1.1 — Mon, 29 Mar 1999 05:00 GMT
  • Disposition: Resolved — NOT 1.2
  • Disposition Summary:

    Added 2 sentences to 5th paragraph after constraints examples in section 2.3

  • Updated: Fri, 6 Mar 2015 20:58 GMT

TimeBase::UtcT where TimeBase::TimeT is needed

  • Key: NOT12-21
  • Legacy Issue Number: 2712
  • Status: closed  
  • Source: Anonymous
  • Summary:

    TimeBase::UtcT where TimeBase::TimeT is needed

  • Reported: NOT 1.1 — Tue, 8 Jun 1999 04:00 GMT
  • Disposition: Resolved — NOT 1.2
  • Disposition Summary:

    Modified offending text in Pacing Interval section of section 2.5.5

  • Updated: Fri, 6 Mar 2015 20:58 GMT

CosNotifyChannelAdmin module: typed proxies not defined in ProxyType enum

  • Key: NOT12-20
  • Legacy Issue Number: 2662
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: The CosNotifyChannelAdmin::ProxyConsumer and the
    CosNotifyChannelAdmin::ProxySupplier interfaces define
    the MyType attribute as a ProxyType.

    This ProxyType enum is defined as:

    enum ProxyType

    { PUSH_ANY, PULL_ANY, PUSH_STRUCTURED, PULL_STRUCTURED, PUSH_SEQUENCE, PULL_SEQUENCE }

    ;

    The CosTypedNotifyChannelAdmin::TypedProxyPushConsumer and
    the CosTypedNotifyChannelAdmin::TypedProxyPullConsumer
    interfaces inherit the CosNotifyChannelAdmin::ProxyConsumer
    interface.
    Likewise, the CosTypedNotifyChannelAdmin::TypedProxyPushSupplier
    and the CosTypedNotifyChannelAdmin::TypedProxyPullSupplier
    interfaces inherit the CosNotifyChannelAdmin::ProxySupplier
    interface.

    The objects inheriting those typed interfaces have no meaningfull
    way to initialize the MyType attribute, therefore I think the
    PUSH_TYPED and PULL_TYPED values are missing to this enum.

    Thua, the resulting ProxyType enum should be defined as:

    enum ProxyType

    { PUSH_ANY, PULL_ANY, PUSH_STRUCTURED, PULL_STRUCTURED, PUSH_SEQUENCE, PULL_SEQUENCE, PUSH_TYPED, PULL_TYPED }

    ;

  • Reported: NOT 1.1 — Tue, 25 May 1999 04:00 GMT
  • Disposition: Resolved — NOT 1.2
  • Disposition Summary:

    resolved, see below

  • Updated: Fri, 6 Mar 2015 20:58 GMT

To add to "Reliablity" text, Page 54 after paragraph 3.

  • Key: NOT12-17
  • Legacy Issue Number: 2653
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: The current description of the Reliability quality of service settings
    allows the possibility of modifying quality of service values in
    a way that would violate validatation rules.

  • Reported: NOT 1.1 — Tue, 18 May 1999 04:00 GMT
  • Disposition: Resolved — NOT 1.2
  • Disposition Summary:

    Added text to bottom of Reliability section of Section 2.5.5.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Modify the DiscardPolicy text, paragraph 1 page 56

  • Key: NOT12-16
  • Legacy Issue Number: 2652
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: The description of when and how to apply discard policies is ambiguous.
    It is unclear whether the discard policy is intended to be applied on
    the events in their original order or as ordered by an order policy.

  • Reported: NOT 1.1 — Tue, 18 May 1999 04:00 GMT
  • Disposition: Resolved — NOT 1.2
  • Disposition Summary:

    resolved, see below

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Modify paragraph 6, page 52

  • Key: NOT12-19
  • Legacy Issue Number: 2655
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: The document implies that all factories can assign quality of service
    properties when objects are created. This is not the case.

  • Reported: NOT 1.1 — Tue, 18 May 1999 04:00 GMT
  • Disposition: Resolved — NOT 1.2
  • Disposition Summary:

    resolved, see below

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Modify RejectNewEvents description, paragraph 8 page 56

  • Key: NOT12-18
  • Legacy Issue Number: 2654
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: The description of the RejectNewEvents does not sufficiently constrain
    its use to the event channel.

  • Reported: NOT 1.1 — Tue, 18 May 1999 04:00 GMT
  • Disposition: Resolved — NOT 1.2
  • Disposition Summary:

    resolved, see below

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Problem with Sequence Pull Model

  • Key: NOT12-23
  • Legacy Issue Number: 2714
  • Status: closed  
  • Source: Anonymous
  • Summary:
  • Reported: NOT 1.1 — Wed, 9 Jun 1999 04:00 GMT
  • Disposition: Resolved — NOT 1.2
  • Disposition Summary:

    Modified text in sections 3.3.13.1 and 3.3.13.2

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Pull Methods on Sequence Suppliers

  • Key: NOT12-22
  • Legacy Issue Number: 2713
  • Status: closed  
  • Source: Anonymous
  • Summary:
  • Reported: NOT 1.1 — Tue, 8 Jun 1999 04:00 GMT
  • Disposition: Resolved — NOT 1.2
  • Disposition Summary:

    Modified text in sections 3.3.13.1 and 3.3.13.2

  • Updated: Fri, 6 Mar 2015 20:58 GMT

CosNotification -- MaxEventsPerConsumer = 0 for infinity?

  • Key: NOT12-11
  • Legacy Issue Number: 2433
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: The CosNotification spec is careful to say that, for the administrative
    properties (MaxQueueLength, MaxConsumers and MaxSuppliers), the default
    value is zero, and it means that there is no limit.

    As far as I can see there is not similar wording for the QoS property
    MaxEventsPerConsumer. Two questions that should probably be answered are:

    • is there a magic value that means "no limit"?
    • what is the default value if it"s not eqplicitly set at any level?

    I would suggest that, for consistency with MaxQueueLength, the magic value
    should be 0, and the default should be that same value.

  • Reported: NOT 1.1 — Wed, 3 Feb 1999 05:00 GMT
  • Disposition: Resolved — NOT 1.2
  • Disposition Summary:

    Added sentence to end of MaxEventsPerConsumer section of section 2.5.5

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Unnecessary restriction defined on Mapping Filters

  • Key: NOT12-10
  • Legacy Issue Number: 2297
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: The sections in Chapter 3 that discuss the semantics of priority_filter and
    lifetime_filter associated with Proxy objects indicate that Mapping Filters
    associated with Proxy objects are only applied if there is no equivalent
    Mapping Filter defined for the Admin that created the Proxy. If there
    is a Mapping Filter defined at the Admin level, the one defined at the
    Proxy level is ignored.

    We feel this restriction is unnecessary, and in some cases even undesirable.
    We thus feel the text that indicates this semantic should be removed wherever
    it appears.

  • Reported: NOT 1.1 — Thu, 7 Jan 1999 05:00 GMT
  • Disposition: Resolved — NOT 1.2
  • Disposition Summary:

    fix see below

  • Updated: Fri, 6 Mar 2015 20:58 GMT

The term name-value pair is not well defined

  • Key: NOT12-2
  • Legacy Issue Number: 2211
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: 1) The term name-value pair is not well defined in the Notification
    document.

    Suggested resolution:

    We need to decide as a group to explicitly state that either only
    CosNotification::PropertySeq is supported (as well as structutally
    equivalent types only when IIOP messages elide member naming or IR
    info), OR that any structurally equivalent type is supported.
    I would favour the former - as it allows implementers to rely on the
    TypeCode::equal() operation to do comparisons portably rather
    than doing explicit traversals of the typecode.

  • Reported: NOT 1.1 — Mon, 16 Nov 1998 05:00 GMT
  • Disposition: Resolved — NOT 1.2
  • Disposition Summary:

    Added text to 2nd paragraph of section 2.5.2

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Notification Constraint language problem

  • Key: NOT12-1
  • Legacy Issue Number: 2203
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Section 2.4.3 (final bullet) says:

    • When a boolean operand is used in an arithmetic operation, it is
      treated as weakly-typed CORBA::Long.

    This is semantically very dubious. What value is used for TRUE and
    FALSE? 1 and 0 perhaps? This results in "TRUE + TRUE == 2" producing a
    match and "TRUE / FALSE" producing a divide by zero error!

  • Reported: NOT 1.1 — Wed, 11 Nov 1998 05:00 GMT
  • Disposition: Resolved — NOT 1.2
  • Disposition Summary:

    Added text at end of 3rd bullet from top of new page 45

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Inconsistency on p 54

  • Key: NOT12-9
  • Legacy Issue Number: 2229
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Just a minor note to page 54 in the 98-11-01 spec. In the last paragraph
    of the Reliability section, you say that EventReliability can be set
    both at channel, admin and group level. This is inconsistent with Table
    2-4. If the table is correct you should probably remove that last
    paragraph completely as I think it makes sense to set
    ConnectionReliability at any level.

  • Reported: NOT 1.1 — Mon, 30 Nov 1998 05:00 GMT
  • Disposition: Resolved — NOT 1.2
  • Disposition Summary:

    Fix for issue 2219 also fixed this problem

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Explicit statement missing in contraint grammar

  • Key: NOT12-8
  • Legacy Issue Number: 2220
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Issue: No explicit statement is given in the contraint grammar about
    which operators apply to enumerated types.

    Suggested solution:

    Only equality and inequality operators (== != >= > < <=) should be
    defined as legal on enums... as these are all that CORBA requires are
    available in a language mapping.

  • Reported: NOT 1.1 — Wed, 18 Nov 1998 05:00 GMT
  • Disposition: Resolved — NOT 1.2
  • Disposition Summary:

    fix see below

  • Updated: Fri, 6 Mar 2015 20:58 GMT

The section 2.4.5

  • Key: NOT12-4
  • Legacy Issue Number: 2213
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: 3) The section 2.4.5 - "A Short-hand Notation for Filtering
    a Generic Event" is supposed to provide a way of addressing all event
    types, IMO including typed event transmissions that appear within an
    Any as a CosNotification::PropertySeq with properties for the
    operation name and each parameter.
    Some text should be included which states that $<ident> matches not
    only $.<ident> for anys, but also $(<ident>) in the case where the any
    contains a single CosNotification::PropertySeq.

  • Reported: NOT 1.1 — Mon, 16 Nov 1998 05:00 GMT
  • Disposition: Resolved — NOT 1.2
  • Disposition Summary:

    Added text to end of 2nd to last paragraph in section 2.4.5 (the 2nd change bar on page 47)

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Footnote on page 34

  • Key: NOT12-3
  • Legacy Issue Number: 2212
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: 2) I note that a footnote on page 34 of the spec says that the term
    "name-value pair" is not meant to denote CORBA::NVList, but it doesn"t
    actually say what it does mean. This should be fixed too (before table
    2.2 where it"s used first).

  • Reported: NOT 1.1 — Mon, 16 Nov 1998 05:00 GMT
  • Disposition: Resolved — NOT 1.2
  • Disposition Summary:

    Added text to footnote on page 34

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Not all references to event types have been updated

  • Key: NOT12-6
  • Legacy Issue Number: 2217
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Not all references to event types have been updated to refer to
    the correct IDL type names:

    struct EventType

    { string domain_name; string type_name; }

    ;

  • Reported: NOT 1.1 — Tue, 17 Nov 1998 05:00 GMT
  • Disposition: Resolved — NOT 1.2
  • Disposition Summary:

    fix see below

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Issue with the algorithm for evaluating $ expressions

  • Key: NOT12-5
  • Legacy Issue Number: 2216
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: The algorithm for evaluating $<variable> expressions does not
    allow for $domain_name and $type_name to be used.

  • Reported: NOT 1.1 — Tue, 17 Nov 1998 05:00 GMT
  • Disposition: Resolved — NOT 1.2
  • Disposition Summary:

    Added text to middle of 2nd to last paragraph in section 2.4.5 (the 1st change bar on page 47)

  • Updated: Fri, 6 Mar 2015 20:58 GMT

EventType IDL typos

  • Key: NOT12-13
  • Legacy Issue Number: 2448
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: The Notification Service IDL EventType contains the element domain_name.
    In the text of the specification this is refered to as domain_type on
    pages 28, 29, 33, 37, 79 etc.

  • Reported: NOT 1.1 — Wed, 10 Feb 1999 05:00 GMT
  • Disposition: Resolved — NOT 1.2
  • Disposition Summary:

    Fix to issue 2217 fixed this problem

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Default values for PacingInterval and MaximumBatchSize QoS properties?

  • Key: NOT12-12
  • Legacy Issue Number: 2434
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Are there any default values for the PacingInterval and MaximumBatchSize QoS
    properties? The default value for PacingInterval could be 0 meaning that a
    sequence type consumer is willing to wait indefinitely for an event sequence.
    But the MaximumBatchSize can"t be 0 as both zero and an indefinite number of
    events are infeasible (an exception could be raised if this QoS is set to a
    value less than 1).

  • Reported: NOT 1.1 — Wed, 3 Feb 1999 05:00 GMT
  • Disposition: Resolved — NOT 1.2
  • Disposition Summary:

    Added sentences to end of MaximumBatchSize and PacingInterval sections in section 2.5.5

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Text on p. 54 describing applicability of EvenReliability QoS out of date

  • Key: NOT12-7
  • Legacy Issue Number: 2219
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: The text on page 54 describing the applicability of EventReliability
    QoS is out of date:

    "Note that the QoS properties related to reliability can be
    set at the channel, group, and proxy levels, but not on an
    individual event basis."

  • Reported: NOT 1.1 — Wed, 18 Nov 1998 05:00 GMT
  • Disposition: Resolved — NOT 1.2
  • Disposition Summary:

    Reworded last paragraph in Reliability section of section 2.5.5

  • Updated: Fri, 6 Mar 2015 20:58 GMT