1. OMG Issue

CORBA3 — How correlate requests and replies when using pollable sets?

  • Key: CORBA3-10
  • Legacy Issue Number: 3541
  • Status: closed  
  • Source: UBS ( Hans Kneubuehl)
  • Summary:

    When using the pollable sets, pollers are registered with
    PollableSet::add_pollable() and retrieved using
    PollableSet::get_ready_pollable(). As pollers are valuetypes they are passed by
    copy, thus portable applications must assume that get_ready_pollable() returns
    a different poller instance than the one passed to add_pollable(). Thus, with
    non-TII, currently there is no portable way to find out how requests
    (represented by the pollers returned from sendp) and replies (represented by
    the pollers returned from get_ready_pollable ) correlate.

    Consider the following IDL:

    module Stock
    interface Quoter

    { long get_quote(in string stock_name); }


    and a client that does a 1000 invocations in the style

    poller = quoter->sendp_get_quote(portfolio[i].stock_name);

    Now, the client could retrieve the 1000 replies in the order:

    while(poll_set->number_left() > 0)

    { pollable = poll_set->get_ready_pollable(timeout); ... }


    But how can the client find out which returned quote belongs to which

    Possible resolutions:
    (a) Reconsider the introduction of a correlation id on pollers which can be
    used to compare if two pollers are referring to the same request/reply.

    (b) Based on the fact that pollable set is locality-constrained and that
    valuetypes support sharing semantics (see CORBA 2.3, Sharing
    Semantics), it could be required that PollableSet::get_ready_pollable() returns
    a pointer to the same valuetype instance as the one passed as argument of

    (c) Close without action, i.e. has to be solved at the application level, e.g.
    in our example the application would have to solve this by changing get_quote to

    long get_quote(in string stock_name, out string stock_name);

    (c) contradicts with the CORBA Messaging Philosophy that AMI is a mere
    client-side issue and that in principle any existing target can be called

    (b) means that we would have two different polling-related correlation

    • one for correlating requests and replies in different processes based on the
      PersistentRequest objref
    • one for correlating requests and replies in the same process based on poller

    (a) means that a generic correlation mechanism is defined that covers both:
    intra- and inter-process correlation. This was variant (a) of issue 2803 in the
    latest vote. It failed with 5 NO : 4 YES : 3 ABSTAIN.

    I could work out two straw men for (a) and (b) for the next vote, or much
    better, we could try to discuss this before the next vote and just work out a
    straw man for the variant that has better acceptance.

  • Reported: CPP 1.1 — Mon, 10 Apr 2000 04:00 GMT
  • Disposition: Resolved — CORBA 3.0.2
  • Disposition Summary:

    close no change

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