Qpid
  1. Qpid
  2. QPID-2628

c++ messaging API dotnet binding needs received message callback

    Details

    • Type: Improvement Improvement
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: 0.7
    • Component/s: C++ Client
    • Labels:
      None
    • Environment:

      Fresh build from current trunk

      Description

      This issue builds upon or obsoletes QPID-2589.

      The dotnet binding as-is provides only access to the functions in the native C++ Messaging API. Customers will need some features beyond that straight away. The proposal here is to add a managed dll that wraps the native session.nextReceiver() function to provide callbacks through an interface to deliver messages to the client.

        Activity

        Hide
        Chuck Rolke added a comment -

        This patch fills in many missing pieces in the current implementation in nearly every Messaging component. In addition it adds a callback server to forward all messages on a session to managed user code.

        Show
        Chuck Rolke added a comment - This patch fills in many missing pieces in the current implementation in nearly every Messaging component. In addition it adds a callback server to forward all messages on a session to managed user code.
        Hide
        Gordon Sim added a comment -

        I think it would be clearer to keep QPID-2589 for improvements to the core binding, and restrict this Jira to the stated scope i.e. consideration of dispatching received messages to a callback.

        Show
        Gordon Sim added a comment - I think it would be clearer to keep QPID-2589 for improvements to the core binding, and restrict this Jira to the stated scope i.e. consideration of dispatching received messages to a callback.
        Hide
        Gordon Sim added a comment -

        + public void open()
        + {
        + Receiver rcvr = session.createReceiver();

        What is the above call for? Is it just creating a Receiver handle for passing in to nextReceiver? If so this seems like a confusing pattern that diverges from the API it is wrapping.

        + Message msg;
        +
        + keepRunning = true;
        + while (keepRunning)
        + {
        + if (session.nextReceiver(rcvr, DurationConstants.SECOND))
        + {
        + if (keepRunning)
        +

        { + msg = rcvr.fetch(DurationConstants.SECOND); The point of the nextReceiver() call is that the receiver returned (if any) is guaranteed to have a message available. Therefore this second level of timeout on the fetch is unnecessary. + this.callback.SessionReceiver(rcvr, msg); + }

        + }
        + //else
        + // receive timed out
        + // eventEngine exits the nextReceiver() function periodically
        + // in order to test the keepRunning flag
        + }
        + // Private thread is now exiting.
        + }

        I fully accept that providing code that dispatches messages to a callback is a useful pattern. However the exact manner in which that should be exposed needs careful consideration. (For example see some of the discussion on QPID-2589 around the desire to remove thread-per-session restrictions). It is important that we delineate parts of the API that we feel are stable and will be supported long term from parts that are likely to change as the implementation evolves. My instinct is that there may be some evolution in the area this Jira is aimed at as the underlying c++ client implementation is extended to support more flexible event driven patterns. (I'd also point out that the amount of code required fr the dispatch as you have proposed is pretty small).

        Show
        Gordon Sim added a comment - + public void open() + { + Receiver rcvr = session.createReceiver(); What is the above call for? Is it just creating a Receiver handle for passing in to nextReceiver? If so this seems like a confusing pattern that diverges from the API it is wrapping. + Message msg; + + keepRunning = true; + while (keepRunning) + { + if (session.nextReceiver(rcvr, DurationConstants.SECOND)) + { + if (keepRunning) + { + msg = rcvr.fetch(DurationConstants.SECOND); The point of the nextReceiver() call is that the receiver returned (if any) is guaranteed to have a message available. Therefore this second level of timeout on the fetch is unnecessary. + this.callback.SessionReceiver(rcvr, msg); + } + } + //else + // receive timed out + // eventEngine exits the nextReceiver() function periodically + // in order to test the keepRunning flag + } + // Private thread is now exiting. + } I fully accept that providing code that dispatches messages to a callback is a useful pattern. However the exact manner in which that should be exposed needs careful consideration. (For example see some of the discussion on QPID-2589 around the desire to remove thread-per-session restrictions). It is important that we delineate parts of the API that we feel are stable and will be supported long term from parts that are likely to change as the implementation evolves. My instinct is that there may be some evolution in the area this Jira is aimed at as the underlying c++ client implementation is extended to support more flexible event driven patterns. (I'd also point out that the amount of code required fr the dispatch as you have proposed is pretty small).
        Hide
        Chuck Rolke added a comment -

        Thanks for reviewing this.

        *+ Receiver rcvr = session.createReceiver();
        *
        *What is the above call for? Is it just creating a Receiver handle for passing in to nextReceiver? If so this seems like a confusing pattern that diverges from the API it is wrapping.

        The managed object, Receiver, cannot contain an actual ::qpid::messaging::Receiver, only a pointer to one. The freshly-added function createReceiver() with no args returns a managed Receiver with the pointer to a C++ Receiver that is simply allocated from the heap but not related to the Session.

        *+ msg = rcvr.fetch(DurationConstants.SECOND);
        *
        *The point of the nextReceiver() call is that the receiver returned (if any) is guaranteed to have a message available. Therefore this second level of timeout on the fetch is unnecessary.

        Can you trust the client not to be doing get() or fetch(), or to be running two callback servers on the same session so that the getNext returns but by the time the fetch gets there the message is gone? If there's a performance issue of adding the timer, or if the fetch throws if there's no message available then this can easily be changed. To do the fetch with a FOREVER seems dangerous.

        *My instinct is that there may be some evolution in the area this Jira is aimed at as the underlying c++ client implementation is extended to support more flexible event driven patterns. (I'd also point out that the amount of code required fr the dispatch as you have proposed is pretty small).

        Absolutely! The example code was designed to illustrate how easy it is to generate a callback from the current c++ client implementation. Raising a general event will require more careful analysis and possible changes to the c++ client. The c++ client and the binding will evolve together.

        Show
        Chuck Rolke added a comment - Thanks for reviewing this. *+ Receiver rcvr = session.createReceiver(); * *What is the above call for? Is it just creating a Receiver handle for passing in to nextReceiver? If so this seems like a confusing pattern that diverges from the API it is wrapping. The managed object, Receiver, cannot contain an actual ::qpid::messaging::Receiver, only a pointer to one. The freshly-added function createReceiver() with no args returns a managed Receiver with the pointer to a C++ Receiver that is simply allocated from the heap but not related to the Session. *+ msg = rcvr.fetch(DurationConstants.SECOND); * *The point of the nextReceiver() call is that the receiver returned (if any) is guaranteed to have a message available. Therefore this second level of timeout on the fetch is unnecessary. Can you trust the client not to be doing get() or fetch(), or to be running two callback servers on the same session so that the getNext returns but by the time the fetch gets there the message is gone? If there's a performance issue of adding the timer, or if the fetch throws if there's no message available then this can easily be changed. To do the fetch with a FOREVER seems dangerous. *My instinct is that there may be some evolution in the area this Jira is aimed at as the underlying c++ client implementation is extended to support more flexible event driven patterns. (I'd also point out that the amount of code required fr the dispatch as you have proposed is pretty small). Absolutely! The example code was designed to illustrate how easy it is to generate a callback from the current c++ client implementation. Raising a general event will require more careful analysis and possible changes to the c++ client. The c++ client and the binding will evolve together.
        Hide
        Chuck Rolke added a comment -

        A receiver callback in .NET is available in org.apache.qpid.messaging.sessionreceiver.

        Its use is demonstrated by csharp.map.callback.receiver.cs.

        Show
        Chuck Rolke added a comment - A receiver callback in .NET is available in org.apache.qpid.messaging.sessionreceiver. Its use is demonstrated by csharp.map.callback.receiver.cs.

          People

          • Assignee:
            Unassigned
            Reporter:
            Chuck Rolke
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development