Issues for Event Working Group of the CORBAservices RTF

List of issues (green=resolved, yellow=pending Board vote, red=unresolved)

List options: All ; Open Issues only; or Closed Issues only

Issue 17: Key type definition
Issue 25: Creation of ProxyPushSupplier interfaces
Issue 93: Disconnected exception
Issue 633: connect_* operations in sections 4.5.(4,5,6,7)
Issue 640: Clarification needed for "at least one consumer" clause

Issue 17: Key type definition (events)

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.

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.
Resolution:
The Key type is a the repository ID of the required interface, such as "IDL:myorg.com/MyModule/MyInterface:1.0

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

Yes, the obtain* operations on the *Admin objects are effectively factory operations for proxies.

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

The specification talks about raising a Disconnected exception when a client invokes an operation on a destroyed object. This is impossible because such a call will raise OBJECT_NOT_EXIST.
Change specification to raise OBJECT_NOT_EXIST in these cases.

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

Whether a proxy is connected is a property of the proxy, not of the connecting party. In particular, a client can connect to a particular proxy only once, whereupon the proxy enters the connected state; the only way out of the connected state is to destroy the proxy. If a client calls the connect operation on a particular proxy a seond time (or another client calls the connect operation on an already connected proxy), the AlreadyConnected exception is raised. This enforces the one-to-one relationship between consumers and producers.

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

The relevant para in the spec reads (page 2-6, section 2.2.4):
If an event channel has at least one push-style consumer or at least one pending pull request, the event channel requires an event. If the event channel has pull suppliers, it will issue a request on a pull supplier to satisfy its requirement.
The implication of this is that an event channel will pull events from a supplier only if there is at least one consumer connected to the channel.
This is wrong -- if a channel were to do this, the supplier would no longer be shielded from its consumers because the supplier could tell the absence of consumers from the presence of consumers. In turn, that causes problems for the supplier.
In particular, a supplier will typically choose the pull model if its event source is itself synchronous and blocking. This has the advantage that the supplier can simply put the pull operation from the channel to sleep until an event arrives from the supplier's event source.
If a channel stops pulling events from the supplier when there are no consumers connected to the channel, the supplier ends up with buffering problems. (Where would the events go that the supplier obtains or generates but the channel refuses to pull?) In effect, such a channel would look like a broken channel to the supplier.