[
https://issues.apache.org/jira/browse/QPID-2628?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12872150#action_12872150
]
Gordon Sim commented on QPID-2628:
----------------------------------
+ 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).
> c++ messaging API dotnet binding needs received message callback
> ----------------------------------------------------------------
>
> Key: QPID-2628
> URL: https://issues.apache.org/jira/browse/QPID-2628
> Project: Qpid
> Issue Type: Improvement
> Components: C++ Client
> Environment: Fresh build from current trunk
> Reporter: Chuck Rolke
> Attachments: cpp_bindings_qpid_dotnet_update.patch
>
>
> 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.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:[email protected]
