Notification Service Avatar
  1. OMG Specification

Notification Service — Open Issues

  • Acronym: NOT
  • Issues Count: 5
  • Description: Issues not resolved
Open Closed All
Issues not resolved

Issues Descriptions

Premature in eliminating Txn interfaces?

  • Key: NOT13-3
  • Legacy Issue Number: 2501
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: I feel there is a flaw in the model described in the current Notification
    Service spec for supporting Transactional Notification.

  • Reported: NOT 1.1 — Wed, 3 Mar 1999 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

EventTypeRepository class issue

  • Key: NOT13-2
  • Legacy Issue Number: 2460
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: In Appendix A it is stated that "the EventTypeRepository class only has
    one instance in any given implementation of the Repository". At the same
    time, there is a package interface and a package factory that implies
    that it"s possible to create multiple repositories (unless the
    NotificationTypesPackage interface is expected to always returns the
    same objects, no matter how many packages one have created).

  • Reported: NOT 1.1 — Fri, 19 Feb 1999 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

CosNotifyChannelAdmin::ConsumerAdmin::obtain_notification_X_supplier oper

  • Key: NOT13-1
  • Legacy Issue Number: 2153
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: The CosNotifyChannelAdmin::ConsumerAdmin::obtain_notification_X_supplier
    operation, when asked for a proxy for a ClientType of ANY_EVENT,
    returns a proxy that is unuasable by event service clients.

    The reason is that the CosNotifyChannelAdmin::ProxyXSupplier interface
    returned inherits only from CosEventChannelAdmin::XSupplier, and then
    redefines the connect operation that was available in CosEventChannelAdmin::
    ProxyXSupplier as connect_any_x_supplier. The interface can never be
    narrowed to CosEventChannelAdmin::ProxyXSupplier, and therfore is
    unusable by the Event Service style client.

  • Reported: NOT 1.1 — Fri, 30 Oct 1998 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

suspend_connection/resume_connection messages - issue

  • Key: NOT13-4
  • Legacy Issue Number: 2512
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary:
    The suspend_connection/resume_connection messages do not describe what should happen to messages that are queued up. Are new messages rejected for the duration between the disconect and resume? Are messages that were queued up flushed? How does the Persistent Event Reliablity QoS effect the way both are handled? size=2> Along the same lines, what happens to events when a consumer disconnects? I assume events in this case would be lost.

  • Reported: NOT 1.1 — Thu, 4 Mar 1999 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

MaxEventsPerConsumer

  • Key: NOT11-1
  • Legacy Issue Number: 9079
  • Status: open  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    The type of MaxEventsPerConsumer should be an unsigned long, why should this be long, so far as I can't tell there is no need for a negative number

  • Reported: NOT 1.1 — Fri, 14 Oct 2005 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT