[
https://issues.apache.org/jira/browse/PROTON-2308?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17463510#comment-17463510
]
ASF GitHub Bot commented on PROTON-2308:
----------------------------------------
astitcher commented on a change in pull request #346:
URL: https://github.com/apache/qpid-proton/pull/346#discussion_r773465245
##########
File path: cpp/include/proton/target_options.hpp
##########
@@ -27,6 +27,7 @@
#include "./duration.hpp"
#include "./target.hpp"
+#include <map>
#include <string>
Review comment:
Same comment here as above re ```#include <vector>```
##########
File path: cpp/include/proton/terminus.hpp
##########
@@ -103,6 +104,10 @@ class terminus {
/// Extension capabilities that are supported/requested
PN_CPP_EXTERN std::vector<symbol> capabilities() const;
+ /// Obtain the AMQP dynamic node properties for the
+ /// terminus as a standard map.
+ PN_CPP_EXTERN std::map<symbol, value> dynamic_properties();
Review comment:
I'm pretty sure this should also be a ```const``` method. In general
getters should be ```const``` as they don't change the object itself.
##########
File path: cpp/src/terminus.cpp
##########
@@ -61,4 +61,12 @@ std::vector<symbol> terminus::capabilities() const {
return caps.empty() ? std::vector<symbol>() : caps.get<std::vector<symbol>
>();
}
+std::map<symbol, value> terminus::dynamic_properties() {
Review comment:
As per my comment in the header file this method should be ```const```
##########
File path: cpp/src/link_test.cpp
##########
@@ -23,9 +23,114 @@
#include <proton/sender_options.hpp>
#include <proton/receiver_options.hpp>
#include <proton/container.hpp>
+#include <proton/connection.hpp>
+#include <proton/connection_options.hpp>
+#include <proton/listen_handler.hpp>
+#include <proton/listener.hpp>
+#include <proton/messaging_handler.hpp>
+#include <proton/types.hpp>
+#include <proton/message.hpp>
+#include <proton/target_options.hpp>
+#include <proton/source_options.hpp>
+#include <proton/delivery.hpp>
#include <iostream>
+#include <map>
+#include <condition_variable>
+#include <mutex>
+#include <thread>
+
+namespace {
+std::mutex m;
+std::condition_variable cv;
+bool listener_ready = false;
+int listener_port;
+const std::string DNP_SYMBOL = "DNP_SYMBOL";
+const std::string DNP_VALUE = "DNP_VALUE";
+} // namespace
Review comment:
If you are trying to replicate a realistic scenario as @gemmellr is
suggesting maybe you want to use real property values as defined in the section
3.5.9 of the AMQP standard?
If I read the standard correctly the 2 defined properties are the symbols
"lifetime-policy" and "supported-dist-modes":
The allowed values of lifetime policy seem to be described lists with values
'@delete-on-closed(43)[]', '@delete-on-nolinks(44)[]',
'@delete-on-no-messages{45)[]', '@delete-on-no-links-or-messages(46)[]' - these
all have specific meanings as to when the creator of the dynamic node should
delete the node. As a side note it seems unusual but these property values seem
to be described lists which should always be empty as there is no useful thing
to put in them.
The allowed values for 'supported-dist-modes' are the symbols 'move' and
'copy' and the list '['move', copy'] (or in the other order!). Or even single
element lists with just symbols 'copy' or 'move' I think.
Of course we have no code in the C++ binding that actually cares what the
values are so this doesn't matter a whole lot, but it might be nice to generate
realistic dynamic property values.
##########
File path: cpp/src/node_options.cpp
##########
@@ -19,15 +19,17 @@
*
*/
-#include "proton/codec/vector.hpp"
Review comment:
Not sure why this has been removed. It doesn't seem related to your
changes. If it's not needed it would be better (and less distracting) to remove
it in a separate change (it could be NO-JIRA if you're really sure it's not
needed - effectively that is what this change is!)
##########
File path: cpp/include/proton/source_options.hpp
##########
@@ -27,6 +27,7 @@
#include "./duration.hpp"
#include "./source.hpp"
+#include <map>
#include <string>
Review comment:
[@DreamPearl Not something you changed] I'm wondering why this header
doesn't ```#include <vector>``` as it clearly uses ```std::vector`` in the
capabilities API. I think this would be a separate change anyway!
##########
File path: cpp/src/link_test.cpp
##########
@@ -23,9 +23,114 @@
#include <proton/sender_options.hpp>
#include <proton/receiver_options.hpp>
#include <proton/container.hpp>
+#include <proton/connection.hpp>
+#include <proton/connection_options.hpp>
+#include <proton/listen_handler.hpp>
+#include <proton/listener.hpp>
+#include <proton/messaging_handler.hpp>
+#include <proton/types.hpp>
+#include <proton/message.hpp>
+#include <proton/target_options.hpp>
+#include <proton/source_options.hpp>
+#include <proton/delivery.hpp>
#include <iostream>
+#include <map>
+#include <condition_variable>
+#include <mutex>
+#include <thread>
+
+namespace {
+std::mutex m;
+std::condition_variable cv;
+bool listener_ready = false;
+int listener_port;
+} // namespace
+
+class test_recv : public proton::messaging_handler {
+ private:
+ class listener_ready_handler : public proton::listen_handler {
+ void on_open(proton::listener &l) override {
+ {
+ std::lock_guard<std::mutex> lk(m);
+ listener_port = l.port();
+ listener_ready = true;
+ }
+ cv.notify_one();
+ }
+ };
+
+ std::string url;
+ proton::listener listener;
+ listener_ready_handler listen_handler;
+
+ public:
+ test_recv(const std::string &s) : url(s) {}
+
+ void on_container_start(proton::container &c) override {
+ listener = c.listen(url, listen_handler);
+ }
+
+ void on_message(proton::delivery &d, proton::message &msg) override {
+ proton::symbol sym = "symbol";
+ proton::value val = "value";
+ std::map<proton::symbol, proton::value> props =
d.receiver().target().dynamic_node_properties();
+
+ ASSERT(!props.empty());
+ for(auto it=props.begin(); it!=props.end(); it++) {
+ ASSERT_EQUAL(sym, it->first);
+ ASSERT_EQUAL(val, it->second);
+ }
+ d.receiver().close();
+ d.connection().close();
+ listener.stop();
+ }
+};
+
+class test_send : public proton::messaging_handler {
+ private:
+ std::string url;
+ proton::sender sender;
+
+ public:
+ test_send(const std::string &s) : url(s) {}
+
+ void on_container_start(proton::container &c) override {
+ proton::target_options opts;
+ std::map<proton::symbol,proton::value> m({{proton::symbol("symbol"),
proton::value("value")}});
+ opts.dynamic_node_properties(m);
+ sender = c.open_sender(url, proton::sender_options().target(opts));
+ }
+
+ void on_sendable(proton::sender &s) override {
+ proton::message msg;
+ msg.body("message");
+ proton::tracker t = s.send(msg);
+ s.connection().close();
+ }
+};
+
+int test_dynamic_node_properties() {
Review comment:
Although @gemmellr is correct in his analysis of what is going on in a
real AMQP messaging interaction, this is probably not all that important as the
C++ binding (at least currently) has no logic at either sender or receiver to
do anything special for dynamic nodes - it just passes the info on to the
application which is expected to validate and act on that information.
So from the point of view of this test it is only important to check that
the properties get correctly carried in both directions. Unless the tester
itself generates the requested nodes the API is not going to so there really
isn't anything to validate in the test.
In a future change to the C++ binding it would definitely make sense to
validate that you can't set address and set dynamic if you are sender/target or
receiver/source. And also that if dynamic node properties are set the dynamic
must also be set for the node, but that isn't done by the binding (or proton-c)
currently so testing for it makes no sense. Producing realistic protocol
interactions makes some sense but only to make the test "more realistic".
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
> [cpp] Add support for setting Dynamic Node Properties
> -----------------------------------------------------
>
> Key: PROTON-2308
> URL: https://issues.apache.org/jira/browse/PROTON-2308
> Project: Qpid Proton
> Issue Type: Improvement
> Components: cpp-binding
> Affects Versions: proton-c-0.33.0
> Reporter: James Henry
> Assignee: Rakhi Kumari
> Priority: Major
> Labels: api-addition
>
> Requesting support for setting the dynamic node properties be added to the
> source and target options.
> This would allow the setting of termini node properties for senders and
> receivers.
> Similar to the following request made for Python here:
> https://issues.apache.org/jira/browse/PROTON-816
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
