Re: [c++]: messaging api, uuids and handles
On 01/13/2010 11:04 AM, Andrew Stitcher wrote: On Wed, 2010-01-13 at 10:52 -0500, Alan Conway wrote: On 01/13/2010 09:42 AM, Gordon Sim wrote: I have an outstanding Jira (QPID-2323) to add support for uuids as a value for a Variant in the 'new' API (it is wanted for QMF and seems like it might be a generically useful type). The current Uuid class is in qpid::framing and has exposed dependencies on things I don't want to be part of the API (such as boost::array and qpid::framing::Buffer). My thought therefore is to create a copy of that class in the qpid::messaging namespace, pimpled and cleaned up to avoid the undesired dependencies. Does that sound like the right approach? I don't think it should be pimpled, it's a value type and the 16-byte representation will never change. I'd suggest a char[16] member and manually write the stuff that boost::array provides (copy, assign etc.) I think it's a toss up between these approaches, but I'd note that pimpling will allow force you to make the interface explicit (including the assigns/copies etc.) so that you should easily be able to move to the other implementation. Although in that case the ABI would change, but the effective API wouldn't. I think the key point here is that a pimpl has reference semantics rather than value semantics. I think UUID should have value semantics i.e. Uuid x = ...; UUid y = x; // modifing y should not affect x With pimpl, modifying y *will* modify x since y is a reference to the same impl as x, which I think would be surprising to the user. - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
[jira] Created: (QPID-2340) [Java] ProducerFlowControlTest failing due to race condition in test
[Java] ProducerFlowControlTest failing due to race condition in test Key: QPID-2340 URL: https://issues.apache.org/jira/browse/QPID-2340 Project: Qpid Issue Type: Bug Components: Java Tests Affects Versions: 0.6 Reporter: Rob Godfrey Assignee: Rob Godfrey Fix For: 0.7 ProducerFlowControlTest occasionally fails with unexpected numbers of messages being sent due to the fact that the test is based on sleeping for an amount of time, and assuming that the flow control will have kicked in by then. this is necessary as sending messages cannot be made synchronous in 0-8. To fix, introduce a .sync() method on AMQSession and call this after sends in the test. This will ensure that any necessary flow control will have been enacted before the next client operation is invoked. -- 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-subscr...@qpid.apache.org
Re: [c++]: messaging api, uuids and handles
On Thu, 2010-01-14 at 09:06 -0500, Alan Conway wrote: On 01/13/2010 11:04 AM, Andrew Stitcher wrote: On Wed, 2010-01-13 at 10:52 -0500, Alan Conway wrote: On 01/13/2010 09:42 AM, Gordon Sim wrote: I have an outstanding Jira (QPID-2323) to add support for uuids as a value for a Variant in the 'new' API (it is wanted for QMF and seems like it might be a generically useful type). The current Uuid class is in qpid::framing and has exposed dependencies on things I don't want to be part of the API (such as boost::array and qpid::framing::Buffer). My thought therefore is to create a copy of that class in the qpid::messaging namespace, pimpled and cleaned up to avoid the undesired dependencies. Does that sound like the right approach? I don't think it should be pimpled, it's a value type and the 16-byte representation will never change. I'd suggest a char[16] member and manually write the stuff that boost::array provides (copy, assign etc.) I think it's a toss up between these approaches, but I'd note that pimpling will allow force you to make the interface explicit (including the assigns/copies etc.) so that you should easily be able to move to the other implementation. Although in that case the ABI would change, but the effective API wouldn't. I think the key point here is that a pimpl has reference semantics rather than value semantics. I think UUID should have value semantics i.e. Uuid x = ...; UUid y = x; // modifing y should not affect x With pimpl, modifying y *will* modify x since y is a reference to the same impl as x, Not if you have a copying assignment operator, which I think I included above, In that case you get value semantics. I agree Uuid should have value semantics, but you _can_ implement with a pimpl. Andrew - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
Release
Andrew, where do you believe we are in the release process? Carl. - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
[jira] Resolved: (QPID-2340) [Java] ProducerFlowControlTest failing due to race condition in test
[ https://issues.apache.org/jira/browse/QPID-2340?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rob Godfrey resolved QPID-2340. --- Resolution: Fixed [Java] ProducerFlowControlTest failing due to race condition in test Key: QPID-2340 URL: https://issues.apache.org/jira/browse/QPID-2340 Project: Qpid Issue Type: Bug Components: Java Tests Affects Versions: 0.6 Reporter: Rob Godfrey Assignee: Rob Godfrey Fix For: 0.7 ProducerFlowControlTest occasionally fails with unexpected numbers of messages being sent due to the fact that the test is based on sleeping for an amount of time, and assuming that the flow control will have kicked in by then. this is necessary as sending messages cannot be made synchronous in 0-8. To fix, introduce a .sync() method on AMQSession and call this after sends in the test. This will ensure that any necessary flow control will have been enacted before the next client operation is invoked. -- 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-subscr...@qpid.apache.org
Re: Release
On Thu, 2010-01-14 at 11:14 -0500, Carl Trieloff wrote: Andrew, where do you believe we are in the release process? I'm busy doing other things at the moment - I'll look at this tomorrow. Andrew - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
Re: Release
On 01/14/2010 11:22 AM, Andrew Stitcher wrote: On Thu, 2010-01-14 at 11:14 -0500, Carl Trieloff wrote: Andrew, where do you believe we are in the release process? I'm busy doing other things at the moment - I'll look at this tomorrow. I was more asking, are we going to vote or RCx next... ot you don't know yet. Carl. - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
[jira] Commented: (QPID-2335) Arguments for a binding to an XML exchange are not visible through management
[
https://issues.apache.org/jira/browse/QPID-2335?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12800298#action_12800298
]
Gordon Sim commented on QPID-2335:
--
What about:
Index: cpp/src/qpid/xml/XmlExchange.cpp
===
--- cpp/src/qpid/xml/XmlExchange.cpp(revision 898714)
+++ cpp/src/qpid/xml/XmlExchange.cpp(working copy)
@@ -82,7 +82,7 @@
XmlBinding::vector::ConstPtr p = bindings.snapshot();
if (!p || std::find_if(p-begin(), p-end(), MatchQueue(queue)) ==
p-end()) {
Query query(xqilla.parse(X(queryText.c_str(;
- XmlBinding::shared_ptr binding(new XmlBinding (routingKey,
queue, this, query));
+ XmlBinding::shared_ptr binding(new XmlBinding (routingKey,
queue, this, *bindingArguments, query));
bindings.add(binding);
QPID_LOG(trace, Bound successfully with query: queryText
);
Index: cpp/src/qpid/xml/XmlExchange.h
===
--- cpp/src/qpid/xml/XmlExchange.h (revision 898714)
+++ cpp/src/qpid/xml/XmlExchange.h (working copy)
@@ -49,8 +49,8 @@
boost::shared_ptrXQQuery xquery;
bool parse_message_content;
-XmlBinding(const std::string key, const Queue::shared_ptr queue,
Exchange* parent, Query query):
-Binding(key, queue, parent), xquery(query),
parse_message_content(true) {}
+XmlBinding(const std::string key, const Queue::shared_ptr queue,
Exchange* parent, const framing::FieldTable args, Query query):
+Binding(key, queue, parent, args), xquery(query),
parse_message_content(true) {}
};
Your concern around potential concurrent access to
Exchange::Binding::mgmtBinding seems like it would be better addressed via a
separate Jira? My inclination (though I'm not sure I properly understand your
concern) would be something simple like making that member private:
Index: cpp/src/qpid/broker/Exchange.cpp
===
--- cpp/src/qpid/broker/Exchange.cpp(revision 898714)
+++ cpp/src/qpid/broker/Exchange.cpp(working copy)
@@ -87,9 +87,7 @@
msg.getMessage().blockContentRelease();
for(std::vectorBinding::shared_ptr::const_iterator i = b-begin(); i
!= b-end(); i++, count++) {
-msg.deliverTo((*i)-queue);
-if ((*i)-mgmtBinding != 0)
-(*i)-mgmtBinding-inc_msgMatched();
+(*i)-route(msg);
}
}
@@ -333,6 +331,13 @@
}
}
+void Exchange::Binding::route(Deliverable msg)
+{
+msg.deliverTo(queue);
+if (mgmtBinding != 0)
+mgmtBinding-inc_msgMatched();
+}
+
Exchange::Binding::~Binding ()
{
if (mgmtBinding != 0) {
Index: cpp/src/qpid/broker/Exchange.h
===
--- cpp/src/qpid/broker/Exchange.h (revision 898714)
+++ cpp/src/qpid/broker/Exchange.h (working copy)
@@ -41,19 +41,22 @@
class Exchange : public PersistableExchange, public management::Manageable {
public:
-struct Binding : public management::Manageable {
+class Binding : public management::Manageable {
+ public:
typedef boost::shared_ptrBinding shared_ptr;
typedef std::vectorBinding::shared_ptr vector;
Queue::shared_ptr queue;
const std::string key;
const framing::FieldTable args;
-qmf::org::apache::qpid::broker::Binding* mgmtBinding;
Binding(const std::string key, Queue::shared_ptr queue, Exchange*
parent = 0,
framing::FieldTable args = framing::FieldTable(), const
std::string origin = std::string());
~Binding();
management::ManagementObject* GetManagementObject() const;
+void route(Deliverable msg);
+ private:
+qmf::org::apache::qpid::broker::Binding* mgmtBinding;
};
private:
Arguments for a binding to an XML exchange are not visible through management
-
Key: QPID-2335
URL: https://issues.apache.org/jira/browse/QPID-2335
Project: Qpid
Issue Type: Bug
Components: C++ Broker
Affects Versions: 0.6
Reporter: Ted Ross
Assignee: Ted Ross
Priority: Minor
If you create a binding to the XML exchange (using
python/examples/xml-exchange/declare_queues.py for example), then look at the
binding using qpid-tool, the arguments field is {} (an empty map).
Arguments for headers exchanges can be viewed correctly, this only affects
the xml exchange.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
Re: [c++]: messaging api, uuids and handles
On 01/14/2010 11:05 AM, Andrew Stitcher wrote: On Thu, 2010-01-14 at 09:06 -0500, Alan Conway wrote: On 01/13/2010 11:04 AM, Andrew Stitcher wrote: On Wed, 2010-01-13 at 10:52 -0500, Alan Conway wrote: On 01/13/2010 09:42 AM, Gordon Sim wrote: I have an outstanding Jira (QPID-2323) to add support for uuids as a value for a Variant in the 'new' API (it is wanted for QMF and seems like it might be a generically useful type). The current Uuid class is in qpid::framing and has exposed dependencies on things I don't want to be part of the API (such as boost::array and qpid::framing::Buffer). My thought therefore is to create a copy of that class in the qpid::messaging namespace, pimpled and cleaned up to avoid the undesired dependencies. Does that sound like the right approach? I don't think it should be pimpled, it's a value type and the 16-byte representation will never change. I'd suggest a char[16] member and manually write the stuff that boost::array provides (copy, assign etc.) I think it's a toss up between these approaches, but I'd note that pimpling will allow force you to make the interface explicit (including the assigns/copies etc.) so that you should easily be able to move to the other implementation. Although in that case the ABI would change, but the effective API wouldn't. I think the key point here is that a pimpl has reference semantics rather than value semantics. I think UUID should have value semantics i.e. Uuid x = ...; UUid y = x; // modifing y should not affect x With pimpl, modifying y *will* modify x since y is a reference to the same impl as x, Not if you have a copying assignment operator, which I think I included above, In that case you get value semantics. I agree Uuid should have value semantics, but you _can_ implement with a pimpl. Agreed, since there are no modifying operations other than assignment. Seems excessive though, for a fixed 16 byte quantity. - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
[jira] Commented: (QPID-2335) Arguments for a binding to an XML exchange are not visible through management
[
https://issues.apache.org/jira/browse/QPID-2335?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12800335#action_12800335
]
john dunning commented on QPID-2335:
Yes, I thought about (and tried) making the cosntructor for XmlBinding mimic
the others, but take an extra arg for query. That works, in the sense that it
fixes the original bug. That wasn't my first choice, because it seemed wrong
to (somewhat gratuitously) make that class have a constructor with a different
signature that his siblings, but maybe we don't care. If the community feels
like it's more tasteful to do it that way than to do the parsing in the
constructor, that's fine with me.
You're also correct that the issue about when the registration of the object
happens w/r/t the constructor deserves a separate bug. I'll clone this one or
open a new one or something along in here for that issue. But see below...
Re the bigger concern, it wasn't simply about access to the mgmtobject, but
about access to the binding itself. If you've stashed that object in some
global location where other threads can get at it, prior to finishing execution
of all the parts of the constructor, you've got a race condition. That's the
situation I thought I had with my modified constructor. I was sure I'd tripped
over that in the process of running some test code.
Since then, I changed some stuff around, and svn updated, and now I can't
reproduce that error any more. I need to do some more careful testing and code
inspection, and try to determine whether the bug is really there (meaning I was
unlucky before, and got lucky now) or whether I was confusing myself with
something that just looked like the race condition, but wasn't really.
Arguments for a binding to an XML exchange are not visible through management
-
Key: QPID-2335
URL: https://issues.apache.org/jira/browse/QPID-2335
Project: Qpid
Issue Type: Bug
Components: C++ Broker
Affects Versions: 0.6
Reporter: Ted Ross
Assignee: Ted Ross
Priority: Minor
If you create a binding to the XML exchange (using
python/examples/xml-exchange/declare_queues.py for example), then look at the
binding using qpid-tool, the arguments field is {} (an empty map).
Arguments for headers exchanges can be viewed correctly, this only affects
the xml exchange.
--
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-subscr...@qpid.apache.org
[jira] Commented: (QPID-2335) Arguments for a binding to an XML exchange are not visible through management
[
https://issues.apache.org/jira/browse/QPID-2335?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12800364#action_12800364
]
Gordon Sim commented on QPID-2335:
--
I don't think it is gratuitous to have a subclass add an argument to its
constructor to initialise a member it defines. To me that seems entirely
sensible.
The Exchange::Binding instance is not stashed in a global location - the
addObject() method only passes in the mgmtBinding pointer - but it will be
accessed by multiple threads (the exchanges are required to be threadsafe). The
only mutable members of Exchange::Binding are the mgmtBinding and the queue
pointer. The queue pointer can be marked const leaving just the mgmtBinding
pointer which can then be made private. I think that goes a reasonable way to
preventing incorrect usage. Would that alleviate your concerns?
Arguments for a binding to an XML exchange are not visible through management
-
Key: QPID-2335
URL: https://issues.apache.org/jira/browse/QPID-2335
Project: Qpid
Issue Type: Bug
Components: C++ Broker
Affects Versions: 0.6
Reporter: Ted Ross
Assignee: Ted Ross
Priority: Minor
If you create a binding to the XML exchange (using
python/examples/xml-exchange/declare_queues.py for example), then look at the
binding using qpid-tool, the arguments field is {} (an empty map).
Arguments for headers exchanges can be viewed correctly, this only affects
the xml exchange.
--
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-subscr...@qpid.apache.org
[jira] Updated: (QPID-2261) QMF V2 API implementation.
[ https://issues.apache.org/jira/browse/QPID-2261?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ken Giusti updated QPID-2261: - Attachment: qmfv2-01-14-10.patch checkpoint: trival blocking method call test passes. QMF V2 API implementation. -- Key: QPID-2261 URL: https://issues.apache.org/jira/browse/QPID-2261 Project: Qpid Issue Type: Improvement Components: Qpid Managment Framework Reporter: Ken Giusti Assignee: Ted Ross Attachments: qmfv2-01-04-10.patch, qmfv2-01-11-10.patch, qmfv2-01-14-10.patch, qmfv2-12-14-09.patch, qmfv2-12-16-09.patch, qmfv2-12-22-09.patch, qmfv2.patch To track code proposed for implementing the QMFv2 api. -- 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-subscr...@qpid.apache.org
