[
https://issues.apache.org/jira/browse/QPID-2628?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12872257#action_12872257
]
Chuck Rolke commented on QPID-2628:
-----------------------------------
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.
> 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]
