You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@qpid.apache.org by "Chuck Rolke (JIRA)" <qp...@incubator.apache.org> on 2010/05/26 22:31:44 UTC
[jira] Created: (QPID-2628) c++ messaging API dotnet binding needs
received message callback
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
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:dev-subscribe@qpid.apache.org
[jira] Commented: (QPID-2628) c++ messaging API dotnet binding
needs received message callback
Posted by "Gordon Sim (JIRA)" <qp...@incubator.apache.org>.
[ 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:dev-subscribe@qpid.apache.org
[jira] Commented: (QPID-2628) c++ messaging API dotnet binding
needs received message callback
Posted by "Gordon Sim (JIRA)" <qp...@incubator.apache.org>.
[ https://issues.apache.org/jira/browse/QPID-2628?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12872143#action_12872143 ]
Gordon Sim commented on QPID-2628:
----------------------------------
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.
> 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:dev-subscribe@qpid.apache.org
[jira] Updated: (QPID-2628) c++ messaging API dotnet binding needs
received message callback
Posted by "Chuck Rolke (JIRA)" <qp...@incubator.apache.org>.
[ https://issues.apache.org/jira/browse/QPID-2628?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Chuck Rolke updated QPID-2628:
------------------------------
Attachment: cpp_bindings_qpid_dotnet_update.patch
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.
> 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:dev-subscribe@qpid.apache.org
[jira] Commented: (QPID-2628) c++ messaging API dotnet binding
needs received message callback
Posted by "Chuck Rolke (JIRA)" <qp...@incubator.apache.org>.
[ 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:dev-subscribe@qpid.apache.org