${taskforce.name} Avatar
  1. OMG Task Force

Event RTF — All Issues

  • Key: EVNT11
  • Issues Count: 12
Open Closed All
All Issues

Issues Descriptions

Clarification needed for "at least one consumer" clause

  • Key: EVNT11-12
  • Legacy Issue Number: 640
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Section 4.4.4, p.4-13 last sentence:If channel responsible for pulling incoming events, then it will issue a request to get event.Or does it mean that event channel will not try to get event

  • Reported: EVNT 1.0b1 — Wed, 30 Jul 1997 04:00 GMT
  • Disposition: Resolved — EVNT 1.0
  • Disposition Summary:

    No Data Available

  • Updated: Sun, 8 Mar 2015 19:23 GMT

connect_* operations in sections 4.5.(4,5,6,7)

  • Key: EVNT11-11
  • Legacy Issue Number: 633
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: The connect_* operations in these sections raise an AlreadyConnected exception if the client is already connected!? In some cases the channel will allow consumer to connect twice

  • Reported: EVNT 1.0b1 — Thu, 24 Jul 1997 04:00 GMT
  • Disposition: Resolved — EVNT 1.0
  • Disposition Summary:

    Rejected

  • Updated: Sun, 8 Mar 2015 19:23 GMT

Disconnected exception

  • Key: EVNT11-10
  • Legacy Issue Number: 93
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: The conditions for raising the Disconnected exception are not consistent with the state diagram on page 4-14.

  • Reported: EVNT 1.0b1 — Wed, 28 Aug 1996 04:00 GMT
  • Disposition: Resolved — EVNT 1.0
  • Disposition Summary:

    No Data Available

  • Updated: Sun, 8 Mar 2015 19:23 GMT

Key type definition

  • Key: EVNT11-8
  • Legacy Issue Number: 17
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: TypedConsumerAdmin and TypedSupplierAdmin have operations that take a "Key" type (which identifies an interface), but do not specify the specific value needed to ID an interface.

  • Reported: EVNT 1.0b1 — Wed, 26 Jun 1996 04:00 GMT
  • Disposition: Resolved — EVNT 1.0
  • Disposition Summary:

    No Data Available

  • Updated: Sun, 8 Mar 2015 19:23 GMT

Creation of ProxyPushSupplier interfaces

  • Key: EVNT11-9
  • Legacy Issue Number: 25
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Is it implied that obtain_push_supplier causes the creation/allocation of a ProxyPushSupplier interface?

  • Reported: EVNT 1.0b1 — Mon, 1 Jul 1996 04:00 GMT
  • Disposition: Resolved — EVNT 1.0
  • Disposition Summary:

    Rejected

  • Updated: Sun, 8 Mar 2015 19:23 GMT

Semantics of Event Service disconnect_push_consumer/supplier()

  • Key: EVNT11-7
  • Legacy Issue Number: 3427
  • Status: closed  
  • Source: Motorola ( Tom Ziomek)
  • Summary:

    The question concerns the disconnect_push_consumer() family of operations
    (push and pull, consumer and supplier) on both the Event Svc side (proxy
    suppliers and consumers) and application side (suppliers and consumers).

    1) Is a proxy's disconnect_..._...() meant to be called by (any or all of)

    • the corresponding application supplier/consumer?
    • some other part of the application?
    • any portion of the Event Svc implementation? If "yes" in this case,
      is the connected application object also supposed to be invoked, to
      notify it of the proxy's shutdown?

    2) Is an application consumer/supplier's disconnect_..._...() meant to be
    called by

    • some other part of the application? If "yes" in this case, is the
      application consumer/supplier then expected to invoke disconnect_()
      on the corresponding proxy object?
    • any portion of the Event Svc implementation? If "yes", under what
      circumstances?

    The specific issue at hand presumes the application object's disconnect_()
    operation is to be invoked by the Event Svc. The question is when – one
    opinion is that a call to the proxy's disconnect_() results in the invoca-
    tion of disconnect_() on the proxy's application object. The opposing o-
    pinion is that the application object's disconnect_() is invoked only when
    the application object is being disconnected by some means other than a
    call to the proxy's disconnect_() (for example, if the event channel's
    destroy() is called while application objects are still connected).

  • Reported: EVNT 1.0 — Wed, 15 Mar 2000 05:00 GMT
  • Disposition: Resolved — EVNT 1.1
  • Disposition Summary:

    No Data Available

  • Updated: Sun, 8 Mar 2015 18:22 GMT

Typed event service and disconnect (identical to issue 3156 Notif-service)

  • Key: EVNT11-6
  • Legacy Issue Number: 3426
  • Status: closed  
  • Source: Triodia Technologies Pty Ltd ( Michi Henning)
  • Summary:

    For the untyped event service, a Disconnected exception is raised
    if push() or pull() are called by the appropriate connect operation wasn't
    called previously.

    What should happen if I use a typed event service?

  • Reported: EVNT 1.0 — Wed, 15 Mar 2000 05:00 GMT
  • Disposition: Duplicate or Merged — EVNT 1.1
  • Disposition Summary:

    No Data Available

  • Updated: Sat, 7 Mar 2015 06:16 GMT

Specification: Event Service -- IDL section

  • Key: EVNT11-5
  • Legacy Issue Number: 9815
  • Status: open  
  • Source: MITRE ( Kevin Richardson)
  • Summary:

    There are incorrect comments in the posted complete IDL file referring to the Naming Service. In addition this IDL only reflects the Lightweight Event Service and not the full Event Service IDL.

  • Reported: EVNT 1.2 — Fri, 9 Jun 2006 04:00 GMT
  • Updated: Sat, 7 Mar 2015 05:04 GMT

meaning of "dispose(d)" throughout this specification.

  • Key: EVNT11-4
  • Legacy Issue Number: 5905
  • Status: open  
  • Source: Connox ( Raf Schietekat)
  • Summary:

    This is about the meaning of "dispose(d)" throughout this specification. "dispose" does not occur in all of CORBA 3.0 (02-06-01.pdf), so I have no clear idea of what it means.

    As a possible interpretation, it makes no sense that a reference would be released, as a result of calling an operation through it. It would make sense if a PushConsumer's PushSupplier object reference were released when the PushConsumer executes a disconnect_push_supplier(), but "2.1.1 The PushConsumer Interface" specifically says "The PushConsumer object reference is disposed.".

    I can accept that a proxy would be destroyed when it is disconnected, because it is dedicated to a specific event relationship, and implied destruction would be a convenience there, but, other than "Figure 2-6 State diagram of a proxy." in "2.2.5 Event Channel Administration" on p. 2-8, I see nothing to emphasise this as a difference with plain (non-proxy) end points. Yet, as I see it, plain end points may be long-lived objects, that may engage in several event-passing relationships during their lifetimes. There is no possibility for the "infinite recursive calls to these disconnect operations" that "2.1.5 Disconnection Behavior" mentions if the reference to the other side is simply released after sending it a disconnect; there is no need to destroy anything for that purpose, or faking OBJECT_NOT_EXIST. So why do I get the impression that the revision to the Event Service Specification wants those non-proxy end points to be destroyed as well, although not unequivocally?

    It all looks rather messy, especially the thing about the inappropriate OBJECT_NOT_EXIST. And yet, I need to know for certain, to ensure interoperability and portability (I am currently implementing an Event Service for RayORB, not just using one).

    And can I make a suggestion on the side: there should be a document comprising known errata and issues for every official document, to avoid duplicate reports. w3c.org seems to do a good job of helping itself that way.

  • Reported: EVNT 1.1 — Sun, 16 Mar 2003 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

2.3.1 The EventChannel Interface

  • Key: EVNT11-3
  • Legacy Issue Number: 5904
  • Status: open  
  • Source: Connox ( Raf Schietekat)
  • Summary:

    The first issue is whether one EventChannel has at most one or more ConsumerAdmin objects (and similarly for both Typed... and Supplier..., orthogonally). On the one hand, the specification says things like "Destruction of a ConsumerAdmin or SupplierAdmin object causes the implementation to invoke the disconnect operation on all proxies that were created via that ConsumerAdmin or SupplierAdmin object." (same section, previous page), on the other it says something like this conflicting "In such a case, the creator would simply export the ConsumerAdmin object." (my emphasis). Also, the only time a ConsumerAdmin is destroyed is when its EventChannel is destroyed, because only the EventChannel has a destroy-like operation, so there might as well be at most one ConsumerAdmin. The specification should therefore be more explicit about cardinality (and perhaps replace or back up the potato diagrams with UML ones). My current bet is that there is at most one of each ...Admin, and that the Proxy... objects are owned directly by the EventChannel (I went that way before I spotted the discrepancy): is that correct?
    I need to know because I am implementing (not just using) an Event Service as part of RayORB, and, other than verifying interoperability with Java, I am trying to make this a clean-room implementation, from the specifications only. I may also look at the Notification Service Specification, but this specification should be self-contained.
    I have grouped some errors below that require no clarification, because their appropriate correction is clear.
    There is a typing error "ProsyPushSupplier" in "2.3.7 The ProxyPushSupplier Interface", ironically two lines below the word "TypeError".
    There is an IDL error in "2.7 The CosTypedEventChannelAdmin Module": "ProxyPullConsumer obtain_typed_pull_consumer" must be corrected to "CosEventChannelAdmin::ProxyPullConsumer obtain_typed_pull_consumer" for successful compilation, and likewise "ProxyPushSupplier obtain_typed_push_supplier" must become "CosEventChannelAdmin::ProxyPushSupplier obtain_typed_push_supplier".
    In Appendix B, the example uses ...Ref, which, as far back as CORBA 2.2 (the first version I've worked with), is deprecated for C+. Unless I'm mistaken, the use of an environment is only required for C+ compilers that do not support exceptions (are there any left?), and is more distracting than educational. Please update to agree with the current mapping specification.

  • Reported: EVNT 1.1 — Sun, 16 Mar 2003 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

pull request/destroy request issue

  • Key: EVNT11-2
  • Legacy Issue Number: 4651
  • Status: open  
  • Source: Anonymous
  • Summary:

    The event service specification states: "The pull operation blocks until the event data is available or an exception is raised."

    If there are pull requests pending (because no data is available) and a destroy request is issued, do the pull requests have to return with a "Disconnected" exception ?

    Remember (p. 2-9): The destroy request should destroy all admin and proxy objects associated, so the proxies being pulled might not be active any more.

    Testing some notification implementations (e.g. OpenOrb, OpenFusion and dCon) showed that none of them returned from pull request in reasonable time: http://asi28.informatik.uni-hamburg.de/test/Hanging_Pull.java

    If the pull requests are not supposed to return with an exception, what is the intended way to abort the requests, so that channel and client resources can be reclaimed ?

  • Reported: EVNT 1.1 — Tue, 30 Oct 2001 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

event channel buffer should generate exception when buffer beg. to overflow

  • Key: EVNT11-1
  • Legacy Issue Number: 4338
  • Status: open  
  • Source: ANSYS, Inc. ( William Visnich)
  • Summary:

    The Event Service spec should be revised to include a mandatory throwing of
    an exception if an Event Channel buffer begins to overflow. This exception
    should be able to be caught by both the server and client applications. The
    reason is that without an exception, the Event Service is making a implicit
    comment on the value of an individual message. Although the Event Service
    paradigm is publish/subscribe, there may be uses within that context when
    the dropping of a single message is critical. Without implementing
    traditional message tracking solutions such as the sequencing messages,
    there is currently no way of knowing if a message has been dropped. The
    throwing of an exception that can be caught, or not caught, seems to be a
    reasonable solution. It would also increase the value of the services
    currently provided by the Event Service.

  • Reported: EVNT 1.1 — Tue, 5 Jun 2001 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT