[jira] Created: (QPID-2409) qpid-route route map can list the same broker multiple times
qpid-route route map can list the same broker multiple times -- Key: QPID-2409 URL: https://issues.apache.org/jira/browse/QPID-2409 Project: Qpid Issue Type: Bug Environment: Should be any Reporter: john dunning In the case of multi-homed brokers (i.e. that can be addressed by more than one name/address), the route-map feature of qpid-route can list the same broker more than once. This is because it indexes its list of brokers by the URL (not the broker's uuid). Version-Release number of selected component (if applicable): 1.1.6 / 1.2 How reproducible: 100% Steps to Reproduce: 1. Start two brokers on your local system (ports 5672 and 1) 2. Create a bidirectional set of dynamic federation routes: $ qpid-route dynamic add localhost localhost:1 amq.topic $ qpid-route dynamic add localhost:1 localhost amq.topic 3. View the route map: $ qpid-route route map Finding Linked Brokers: localhost:5672... Ok localhost:1... Ok Dynamic Routes: Exchange amq.topic: localhost:1 = localhost:5672 Static Routes: none found 4. View the map again using the ethernet hostname (i.e. not localhost) $ hostname dhcp-100-18-254.bos.redhat.com $ qpid-route route map dhcp-100-18-254.bos.redhat.com Finding Linked Brokers: dhcp-100-18-254.bos.redhat.com:5672... Ok localhost:1... Ok localhost:5672... Ok Dynamic Routes: Exchange amq.topic: localhost:1 = dhcp-100-18-254.bos.redhat.com:5672 localhost:5672 = localhost:1 Static Routes: none found Actual results: Note the fact that three brokers are listed in the second map. This is incorrect because dhcp-100-18-254.bos.redhat.com:5672 and localhost:5672 are different names for the same broker. This causes confusion in the display of the routes themselves. Expected results: The first map is correct. -- 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-2029) Clustering and Management don't work well together
[ https://issues.apache.org/jira/browse/QPID-2029?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] john dunning updated QPID-2029: --- Attachment: object-names-2.diff Thanks Alan for the feedback! Here's a revised patch. I finished the cleanup, got rid of the obsolete stuff; thought I got it all before, mea typo I took the extra debug code out of verify. That was leftover from a previous debugging attempt, and you're right, it doesn't belong there. I tried a couple things to make verify be loadable, but I couldn't work out how to do that in python, my simple attempts failed. Hints? Clustering and Management don't work well together -- Key: QPID-2029 URL: https://issues.apache.org/jira/browse/QPID-2029 Project: Qpid Issue Type: Bug Components: C++ Broker Affects Versions: 0.5 Reporter: Ted Ross Assignee: Ted Ross Fix For: 0.7 Attachments: object-names-2.diff, object-names.diff Several aspects of management of the C++ broker are not well integrated with clustering. 1) object-ids assigned to management objects are not synchronized across nodes of a cluster. 2) persistent object-ids are not synchronized across nodes of a cluster. 3) cached data within the QMF broker are not synchronized. 4) next-object-id and reboot-sequence are not synchronized. -- 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-2029) Clustering and Management don't work well together
[ https://issues.apache.org/jira/browse/QPID-2029?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] john dunning updated QPID-2029: --- Attachment: object-names.diff Attached is a patch with addresses part of this problem. Essentially, the substance of this change is to stop depending on OIDs being sync'ed between members of a cluster. That's extraordinarily difficult to get right, given the current structure of the code. We allow for objects to have fairly free-form names, and rely on object hierarchy to provide unambiguous paths to objects. We add a python script which relies on these ideas to validate that cluster members really do have the same state. Clustering and Management don't work well together -- Key: QPID-2029 URL: https://issues.apache.org/jira/browse/QPID-2029 Project: Qpid Issue Type: Bug Components: C++ Broker Affects Versions: 0.5 Reporter: Ted Ross Assignee: Ted Ross Fix For: 0.7 Attachments: object-names.diff Several aspects of management of the C++ broker are not well integrated with clustering. 1) object-ids assigned to management objects are not synchronized across nodes of a cluster. 2) persistent object-ids are not synchronized across nodes of a cluster. 3) cached data within the QMF broker are not synchronized. 4) next-object-id and reboot-sequence are not synchronized. -- 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] Resolved: (QPID-2375) --load-module msgstore.so without --store-dir causes explosion
[ https://issues.apache.org/jira/browse/QPID-2375?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] john dunning resolved QPID-2375. Resolution: Cannot Reproduce Apparently this was cruft in my environment. I updated to qpid svn 904375 and msgstore svn 3830, rebuilt everything, and it stopped croaking, now errors with exactly the right message. Never mind. --load-module msgstore.so without --store-dir causes explosion -- Key: QPID-2375 URL: https://issues.apache.org/jira/browse/QPID-2375 Project: Qpid Issue Type: Bug Components: C++ Broker Environment: Running from trunk, on F12 Reporter: john dunning Priority: Minor I was testing something else, tried to start a broker with a msgstore, and omitted the store-dir: [r...@jrd cpp]# src/.libs/qpidd -p5672 --auth no --load-module cluster.so --cluster-name=foo --load-module /home/jrd/work/messaging/sre/store/trunk/cpp/lib/.libs/msgstore.so --no-data-dir --log-enable trace 2010-01-28 16:42:04 trace SEND PackageInd package=org.apache.qpid.broker to=schema.package Segmentation fault (core dumped) [r...@jrd cpp]# With --store-dir it starts ok. I realize it might not be expected to work, but probably should die more gracefully. -- 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-2357) Broker boot sequence doesn't synchronize when clustered.
[ https://issues.apache.org/jira/browse/QPID-2357?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] john dunning updated QPID-2357: --- Attachment: qpid-sync-proposed-2.diff Revised patch, after comments from aconway. Broker boot sequence doesn't synchronize when clustered. Key: QPID-2357 URL: https://issues.apache.org/jira/browse/QPID-2357 Project: Qpid Issue Type: Bug Components: C++ Broker Environment: Linux Reporter: john dunning Attachments: qpid-sync-proposed-2.diff, qpid-sync-proposed.diff I discovered this when debugging something else. If you start broker 1 with a data-dir, and broker 2 with no data-dir or a different one, you can (almost always) end up with a different boot sequence. That means if you cluster these two together, when the updatee gets updates, he'll use different OIDs that the master. -- 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] Created: (QPID-2375) --load-module msgstore.so without --store-dir causes explosion
--load-module msgstore.so without --store-dir causes explosion -- Key: QPID-2375 URL: https://issues.apache.org/jira/browse/QPID-2375 Project: Qpid Issue Type: Bug Components: C++ Broker Environment: Running from trunk, on F12 Reporter: john dunning Priority: Minor I was testing something else, tried to start a broker with a msgstore, and omitted the store-dir: [r...@jrd cpp]# src/.libs/qpidd -p5672 --auth no --load-module cluster.so --cluster-name=foo --load-module /home/jrd/work/messaging/sre/store/trunk/cpp/lib/.libs/msgstore.so --no-data-dir --log-enable trace 2010-01-28 16:42:04 trace SEND PackageInd package=org.apache.qpid.broker to=schema.package Segmentation fault (core dumped) [r...@jrd cpp]# With --store-dir it starts ok. I realize it might not be expected to work, but probably should die more gracefully. -- 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-2357) Broker boot sequence doesn't synchronize when clustered.
[ https://issues.apache.org/jira/browse/QPID-2357?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] john dunning updated QPID-2357: --- Attachment: qpid-sync-proposed.diff Attached patch fixes this problem, for at least simple cases. NB that there are other ways to get OIDs out of sync during an update operation, most notably by having timers fire at an inopportune time. That bug is being worked separately. Comments welcome. Broker boot sequence doesn't synchronize when clustered. Key: QPID-2357 URL: https://issues.apache.org/jira/browse/QPID-2357 Project: Qpid Issue Type: Bug Components: C++ Broker Environment: Linux Reporter: john dunning Attachments: qpid-sync-proposed.diff I discovered this when debugging something else. If you start broker 1 with a data-dir, and broker 2 with no data-dir or a different one, you can (almost always) end up with a different boot sequence. That means if you cluster these two together, when the updatee gets updates, he'll use different OIDs that the master. -- 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] Created: (QPID-2357) Broker boot sequence doesn't synchronize when clustered.
Broker boot sequence doesn't synchronize when clustered. Key: QPID-2357 URL: https://issues.apache.org/jira/browse/QPID-2357 Project: Qpid Issue Type: Bug Components: C++ Broker Environment: Linux Reporter: john dunning I discovered this when debugging something else. If you start broker 1 with a data-dir, and broker 2 with no data-dir or a different one, you can (almost always) end up with a different boot sequence. That means if you cluster these two together, when the updatee gets updates, he'll use different OIDs that the master. -- 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-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:all-tabpanel
]
john dunning updated QPID-2335:
---
Attachment: qpid-2335.diff
Proposed fix.
I'm no longer able to reproduce the race condition that I saw before, so I'm
treating that as a separate issue. This fixes the main problem we started
with, plus what looked like an ordering problem when building the binding, as
well as a bug I found in the test suite while testing it.
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
Attachments: qpid-2335.diff
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=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=12799837#action_12799837
]
john dunning commented on QPID-2335:
This turns out be rather larger than the bug description says.
The root of the problem is that as currently constituted, the XmlBinding has
its own constructor which takes different args than the other Binding classes.
In particular, in place of the bindgingArguments arg, it has a query, which is
meant to be the pre-parsed XQQuery. That's why the binding object doesn't show
its args, they were never passed in.
It's relatively straightforward to change the constructor so as to adhere to
the same protocol as the rest of them. That implies that the body of the
constructor parses the string into a query, and stores the query in the binding
object. The parent class constructor stores bindingArguments, and everybody's
happy.
However, that causes a different problem. The parent class's (Binding)
constructor, as a side-effect, stores the object in the managed objects
database. See src/qpid/broker/Exchange.cpp:328. This means that if there's a
derived class whose constructor does anything to the state of the object, you
have a race condition, where somebody else gets their hands on this object
before the guy running the constructor has finished running it. I've observed
this while debugging my patch for the original problem.
It seems to me that it's risky to assume that constructors of derived classes
cannot alter the state of an object after the base class constructor has run.
I propose to fix this by removing the implicit addObject, and making it
explicit. This means that all the callers of constructors of bindings must now
addObject themselves, which touches a lot of files. The upside is that it's a
little more obvious from looking at the code what's going on, and therefore
less prone to error.
There are other variations on that theme; I could rejigger the classes so that
only derived classes call addObject from their constructors. That would mean
that there's a new class to replace Binding, which is probably just as big a
change. That also still leaves us open to a repeat of this bug if somebody
down the road derives from one of these new classes. I could also find a way
to interlock things; there are plenty of locks around, and I couldn introduce a
new one, essentially locking the global datastore while anybody is running a
constructor. Given the frequency with which things are getting created, that's
probably not desirable either.
There's another way of fixing the top-level problem, namely go back to
pre-parsing the query, and only call the constructor when it's ready to go.
IOW, go back to the model where the constructor doesn't do any work. This is
less intrusive, but leaves the core assumption in place, with the associated
likelihood that somebody down the road will make a constructor which does work,
and trip over the same bug.
Comments welcome, particularly if anybody thinks there's a less intrusive way
to make this solid.
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-2327) Enhance qpid-config to deal with xml and headers brokers
[ https://issues.apache.org/jira/browse/QPID-2327?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] john dunning updated QPID-2327: --- Attachment: bz-549443-take-two.patch Revised patch, fixes non-local build problem Enhance qpid-config to deal with xml and headers brokers Key: QPID-2327 URL: https://issues.apache.org/jira/browse/QPID-2327 Project: Qpid Issue Type: Improvement Components: Python Test Suite, python tools Affects Versions: 0.7 Environment: Tested on linux (fedora), at least partially affects all platforms Reporter: john dunning Assignee: Ted Ross Fix For: 0.7 Attachments: bz-549443-take-two.patch, bz-549443.patch qpid-config currently doesn't have a way to configure xml or header type bindings. This patch adds the ability to do so, with extra arg parsing to deal with the specialized args for those bind types. -- 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] Created: (QPID-2327) Enhance qpid-config to deal with xml and headers brokers
Enhance qpid-config to deal with xml and headers brokers Key: QPID-2327 URL: https://issues.apache.org/jira/browse/QPID-2327 Project: Qpid Issue Type: Improvement Components: Python Test Suite, python tools Affects Versions: 0.7 Environment: Tested on linux (fedora), at least partially affects all platforms Reporter: john dunning Fix For: 0.7 qpid-config currently doesn't have a way to configure xml or header type bindings. This patch adds the ability to do so, with extra arg parsing to deal with the specialized args for those bind types. -- 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-2327) Enhance qpid-config to deal with xml and headers brokers
[ https://issues.apache.org/jira/browse/QPID-2327?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] john dunning updated QPID-2327: --- Attachment: bz-549443.patch This patch implements the new qpid-config functionality, and enhances the test suite to test it. Enhance qpid-config to deal with xml and headers brokers Key: QPID-2327 URL: https://issues.apache.org/jira/browse/QPID-2327 Project: Qpid Issue Type: Improvement Components: Python Test Suite, python tools Affects Versions: 0.7 Environment: Tested on linux (fedora), at least partially affects all platforms Reporter: john dunning Fix For: 0.7 Attachments: bz-549443.patch qpid-config currently doesn't have a way to configure xml or header type bindings. This patch adds the ability to do so, with extra arg parsing to deal with the specialized args for those bind types. -- 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
