Re: QPID C++ - Dynamically Managing Broker
Hey Gordon,
Thank you very much! That should give me a great start on this task.
As for the 'shutdown' command, that's actually exactly what I was thinking
too. I'm thinking about running a receiver process on the broker machine.
When it receives a message that says "shutdown" from an authenticated user,
it will perform 'system("/sbin/service qpid-stop");' or whatever the
relevant OS command is. In your opinion, is this a reasonable way to
accomplish this task? Would there perhaps be a better way than creating a
system call?
Thank you in advance,
Spencer
--
View this message in context:
http://qpid.2158936.n2.nabble.com/QPID-C-Dynamically-Managing-Broker-tp7613792p7613863.html
Sent from the Apache Qpid users mailing list archive at Nabble.com.
-
To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org
For additional commands, e-mail: users-h...@qpid.apache.org
Re: [VOTE] Release Qpid 0.30 components
+1 - Qpid C++ (qpid-cpp-0.30.tar.gz) Qpid Java (qpid-java-0.30.tar.gz) Qpid Java QMF tools (qpid-java-qmf-tools-0.30.tar.gz) +1 - Qpid Python (qpid-python-0.30.tar.gz) +1 - Qpid QMF (qpid-qmf-0.30.tar.gz) +1 - Qpid tests (qpid-tests-0.30.tar.gz) +1 - Qpid tools (qpid-tools-0.30.tar.gz) On 09/16/2014 03:12 PM, Justin Ross wrote: > Hi, everyone. The voting process this time is somewhat different. Instead > of voting for "Qpid" as a single release, we are voting for each Qpid > source component individually (excluding Proton and Dispatch). > > The RC artifacts are here: > > https://dist.apache.org/repos/dist/dev/qpid/0.30-rc/ > > They are signed. If a given component is approved, the RC bits will be > come the GA bits. > > Please indicate your vote for each component below. If you favor > proceeding to GA with these RC bits, vote +1. If you have reason to think > a component is not ready for release, vote -1. > > - Qpid C++ (qpid-cpp-0.30.tar.gz) > > - Qpid Java (qpid-java-0.30.tar.gz) > > - Qpid Java QMF tools (qpid-java-qmf-tools-0.30.tar.gz) > > - Qpid Python (qpid-python-0.30.tar.gz) > > - Qpid QMF (qpid-qmf-0.30.tar.gz) > > - Qpid tests (qpid-tests-0.30.tar.gz) > > - Qpid tools (qpid-tools-0.30.tar.gz) > > Thanks! > Justin > > --- > 0.30 release page: > https://cwiki.apache.org/confluence/display/qpid/0.30+Release > - To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org For additional commands, e-mail: users-h...@qpid.apache.org
Re: [VOTE] Release Qpid 0.30 components
+1 - Qpid C++ (qpid-cpp-0.30.tar.gz) - Qpid Java (qpid-java-0.30.tar.gz) - Qpid Java QMF tools (qpid-java-qmf-tools-0.30.tar.gz) - Qpid Python (qpid-python-0.30.tar.gz) - Qpid QMF (qpid-qmf-0.30.tar.gz) - Qpid tests (qpid-tests-0.30.tar.gz) - Qpid tools (qpid-tools-0.30.tar.gz) - Original Message - > From: "Justin Ross" > To: users@qpid.apache.org > Sent: Tuesday, September 16, 2014 3:12:22 PM > Subject: [VOTE] Release Qpid 0.30 components > > Hi, everyone. The voting process this time is somewhat different. Instead > of voting for "Qpid" as a single release, we are voting for each Qpid > source component individually (excluding Proton and Dispatch). > > The RC artifacts are here: > > https://dist.apache.org/repos/dist/dev/qpid/0.30-rc/ > > They are signed. If a given component is approved, the RC bits will be > come the GA bits. > > Please indicate your vote for each component below. If you favor > proceeding to GA with these RC bits, vote +1. If you have reason to think > a component is not ready for release, vote -1. > > - Qpid C++ (qpid-cpp-0.30.tar.gz) > > - Qpid Java (qpid-java-0.30.tar.gz) > > - Qpid Java QMF tools (qpid-java-qmf-tools-0.30.tar.gz) > > - Qpid Python (qpid-python-0.30.tar.gz) > > - Qpid QMF (qpid-qmf-0.30.tar.gz) > > - Qpid tests (qpid-tests-0.30.tar.gz) > > - Qpid tools (qpid-tools-0.30.tar.gz) > > Thanks! > Justin > > --- > 0.30 release page: > https://cwiki.apache.org/confluence/display/qpid/0.30+Release > - To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org For additional commands, e-mail: users-h...@qpid.apache.org
Re: [VOTE] Release Qpid 0.30 components
I tested a subset, see below. Testing on Centos 6 x86_64 VM, built and installed, then ran a series of Openstack oslo.messaging tests using the installed components. - Original Message - > From: "Justin Ross" > To: users@qpid.apache.org > Sent: Tuesday, September 16, 2014 3:12:22 PM > Subject: [VOTE] Release Qpid 0.30 components > > Hi, everyone. The voting process this time is somewhat different. Instead > of voting for "Qpid" as a single release, we are voting for each Qpid > source component individually (excluding Proton and Dispatch). > > The RC artifacts are here: > > https://dist.apache.org/repos/dist/dev/qpid/0.30-rc/ > > They are signed. If a given component is approved, the RC bits will be > come the GA bits. > > Please indicate your vote for each component below. If you favor > proceeding to GA with these RC bits, vote +1. If you have reason to think > a component is not ready for release, vote -1. > > - Qpid C++ (qpid-cpp-0.30.tar.gz) +1 > > - Qpid Java (qpid-java-0.30.tar.gz) > > - Qpid Java QMF tools (qpid-java-qmf-tools-0.30.tar.gz) > > - Qpid Python (qpid-python-0.30.tar.gz) +1 > > - Qpid QMF (qpid-qmf-0.30.tar.gz) +1 > > - Qpid tests (qpid-tests-0.30.tar.gz) > > - Qpid tools (qpid-tools-0.30.tar.gz) +1 > > Thanks! > Justin > > --- > 0.30 release page: > https://cwiki.apache.org/confluence/display/qpid/0.30+Release > -- -K - To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org For additional commands, e-mail: users-h...@qpid.apache.org
Re: Proton tutorial: synchronous request-response
http://svn.apache.org/viewvc/qpid/proton/branches/examples/tutorial/sync_client.py?view=markup&pathrev=1626029 I think "invoke" is an unintuitive name there. It's not "invoking the request" or "invoking the client". Invoke usually implies a named piece of application logic. I think in this case "send" or "send_request" would be better, as in "send the request (and this is a request for which I expect a synchronous response)". On Thu, Sep 18, 2014 at 1:23 PM, Alan Conway wrote: > I checked this in on the examples branch. > > > r1626029 | aconway | 2014-09-18 13:11:12 -0400 (Thu, 18 Sep 2014) | 7 > lines > > NO-JIRA: Added tutorial/sync_client.py to demonstrate a synchronous > request-response client. > > This client uses the familiar paradigm of making blocking calls that > send a > request and return the response. > > Made some improvements to BlockingThread error handling and timeouts. > > > > It needs a little work to be realistic (needs to check correlation ids > at least) but it is quite neat. > > Most of the current tutorial examples are in an event driven style, > which is great for servers and intermediaries but less familiar on the > client side. This demo shows that you can also do traditional > client-driven request response quite easily. The error handling is > simple: invoke() throws if anything goes wrong. > > I did this the hard way first - by writing my own raw event handlers. It > was instructive but, well, hard. Then I noticed Gordon's > BlockingConnection class already did everything I had figured out the > hard way (blocking and error handing) so I rewrote it using that and it > was very easy. > > So far I think this is promising. > > Cheers, > Alan. > > > - > To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org > For additional commands, e-mail: users-h...@qpid.apache.org > >
Proton tutorial: synchronous request-response
I checked this in on the examples branch. r1626029 | aconway | 2014-09-18 13:11:12 -0400 (Thu, 18 Sep 2014) | 7 lines NO-JIRA: Added tutorial/sync_client.py to demonstrate a synchronous request-response client. This client uses the familiar paradigm of making blocking calls that send a request and return the response. Made some improvements to BlockingThread error handling and timeouts. It needs a little work to be realistic (needs to check correlation ids at least) but it is quite neat. Most of the current tutorial examples are in an event driven style, which is great for servers and intermediaries but less familiar on the client side. This demo shows that you can also do traditional client-driven request response quite easily. The error handling is simple: invoke() throws if anything goes wrong. I did this the hard way first - by writing my own raw event handlers. It was instructive but, well, hard. Then I noticed Gordon's BlockingConnection class already did everything I had figured out the hard way (blocking and error handing) so I rewrote it using that and it was very easy. So far I think this is promising. Cheers, Alan. - To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org For additional commands, e-mail: users-h...@qpid.apache.org
Re: [VOTE] Migrate the repo for the new JMS client work to use Git
+1 Just promoting git in general. - Original Message - > From: "Robbie Gemmell" > To: users@qpid.apache.org > Sent: Tuesday, September 16, 2014 12:35:09 PM > Subject: [VOTE] Migrate the repo for the new JMS client work to use Git > > Hello all, > > I mentioned this briefly in a previous thread, and have decided just to > call a vote on the subject. I would like to migrate the repo for the new > JMS client work to use Git rather than Subversion. > > This wont affect the rest of the Qpid codebase, though it could be viewed > as a test for any such move in future. Only the bits in the following > subtree are under consideration for migation at this time: > http://svn.apache.org/repos/asf/qpid/jms/ > > I believe it would make things easier for those of us currently working on > it, and ease future usage of things like the Github integration we > can/should have Apache infra enable. For anyone still wanting to use a > Subversion client to check things out, there will still be an option there > as e.g. Github repos can also be checked out with svn clients, and Apache > mirror things to Github. > > Please cast your votes. Even if you don't intend to work on the code in > question, please vote or at least contribute your thoughts to any > discussion that pops up. I will tally the votes after this point on Friday, > i.e. 72hrs. > > Robbie > - To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org For additional commands, e-mail: users-h...@qpid.apache.org
Re: [VOTE] Migrate the repo for the new JMS client work to use Git
+1 On Tue, Sep 16, 2014 at 12:35 PM, Robbie Gemmell wrote: > > Please cast your votes. Even if you don't intend to work on the code in > question, please vote or at least contribute your thoughts to any > discussion that pops up. I will tally the votes after this point on Friday, > i.e. 72hrs. > > Robbie >
RE: [VOTE] Migrate the repo for the new JMS client work to use Git
+ 1 bizillion Jack and Jimmy cast your votes. -Original Message- From: Steve Huston [mailto:shus...@riverace.com] Sent: Thursday, September 18, 2014 11:13 AM To: users@qpid.apache.org Subject: RE: [VOTE] Migrate the repo for the new JMS client work to use Git +1 > -Original Message- > From: Robbie Gemmell [mailto:robbie.gemm...@gmail.com] > Sent: Tuesday, September 16, 2014 12:35 PM > To: users@qpid.apache.org > Subject: [VOTE] Migrate the repo for the new JMS client work to use > Git > > Hello all, > > I mentioned this briefly in a previous thread, and have decided just > to call a vote on the subject. I would like to migrate the repo for > the new JMS client work to use Git rather than Subversion. > > This wont affect the rest of the Qpid codebase, though it could be > viewed as a test for any such move in future. Only the bits in the > following subtree are under consideration for migation at this time: > http://svn.apache.org/repos/asf/qpid/jms/ > > I believe it would make things easier for those of us currently > working on it, and ease future usage of things like the Github > integration we can/should have Apache infra enable. For anyone still > wanting to use a Subversion client to check things out, there will > still be an option there as e.g. Github repos can also be checked out with > svn clients, and Apache mirror things to Github. > > Please cast your votes. Even if you don't intend to work on the code > in question, please vote or at least contribute your thoughts to any > discussion that pops up. I will tally the votes after this point on Friday, > i.e. 72hrs. > > Robbie B CB [ X ܚX KK[XZ[ \ \ ][ X ܚX P \Y \X K ܙ B ܈Y][ۘ[ [X[ K[XZ[ \ \ Z[ \Y \X K ܙ B B
RE: [VOTE] Migrate the repo for the new JMS client work to use Git
+1 > -Original Message- > From: Robbie Gemmell [mailto:robbie.gemm...@gmail.com] > Sent: Tuesday, September 16, 2014 12:35 PM > To: users@qpid.apache.org > Subject: [VOTE] Migrate the repo for the new JMS client work to use Git > > Hello all, > > I mentioned this briefly in a previous thread, and have decided just to call a > vote on the subject. I would like to migrate the repo for the new JMS client > work to use Git rather than Subversion. > > This wont affect the rest of the Qpid codebase, though it could be viewed as > a test for any such move in future. Only the bits in the following subtree are > under consideration for migation at this time: > http://svn.apache.org/repos/asf/qpid/jms/ > > I believe it would make things easier for those of us currently working on it, > and ease future usage of things like the Github integration we can/should > have Apache infra enable. For anyone still wanting to use a Subversion client > to check things out, there will still be an option there as e.g. Github repos > can > also be checked out with svn clients, and Apache mirror things to Github. > > Please cast your votes. Even if you don't intend to work on the code in > question, please vote or at least contribute your thoughts to any discussion > that pops up. I will tally the votes after this point on Friday, i.e. 72hrs. > > Robbie
Re: [VOTE] Migrate the repo for the new JMS client work to use Git
On 18 September 2014 10:38, Gordon Sim wrote: > On 09/18/2014 10:07 AM, Robbie Gemmell wrote: > >> On 17 September 2014 09:25, Gordon Sim wrote: >> >> On 09/16/2014 05:35 PM, Robbie Gemmell wrote: >>> >>> Hello all, I mentioned this briefly in a previous thread, and have decided just to call a vote on the subject. I would like to migrate the repo for the new JMS client work to use Git rather than Subversion. This wont affect the rest of the Qpid codebase, though it could be viewed as a test for any such move in future. Only the bits in the following subtree are under consideration for migation at this time: http://svn.apache.org/repos/asf/qpid/jms/ I believe it would make things easier for those of us currently working on it, and ease future usage of things like the Github integration we can/should have Apache infra enable. For anyone still wanting to use a Subversion client to check things out, there will still be an option there as e.g. Github repos can also be checked out with svn clients, and Apache mirror things to Github. Please cast your votes. Even if you don't intend to work on the code in question, please vote or at least contribute your thoughts to any discussion that pops up. I will tally the votes after this point on Friday, i.e. 72hrs. >>> I'm in favour of those doing the work deciding what suits them best. Git >>> is now well enough established that switching isn't in any real sense >>> raising a barrier to new contributors. >>> >>> >>> Just to be certain, is your reply to be taken as +1 vote Gordon? >> > > It's more in the category of 'contributing my thoughts' :-) Thats actually what I thought, just wanted to confirm before the final tally. > I'm not going to be immediately involved, so I feel odd voting on it and > since I don't think you are short of votes, I'm just saying explicitly that > what you decide is alright with me. (as opposed to being silent which might > be interpreted differently) > Ok. Additional votes are welcome though ;)
Re: [VOTE] Migrate the repo for the new JMS client work to use Git
On 09/18/2014 10:07 AM, Robbie Gemmell wrote: On 17 September 2014 09:25, Gordon Sim wrote: On 09/16/2014 05:35 PM, Robbie Gemmell wrote: Hello all, I mentioned this briefly in a previous thread, and have decided just to call a vote on the subject. I would like to migrate the repo for the new JMS client work to use Git rather than Subversion. This wont affect the rest of the Qpid codebase, though it could be viewed as a test for any such move in future. Only the bits in the following subtree are under consideration for migation at this time: http://svn.apache.org/repos/asf/qpid/jms/ I believe it would make things easier for those of us currently working on it, and ease future usage of things like the Github integration we can/should have Apache infra enable. For anyone still wanting to use a Subversion client to check things out, there will still be an option there as e.g. Github repos can also be checked out with svn clients, and Apache mirror things to Github. Please cast your votes. Even if you don't intend to work on the code in question, please vote or at least contribute your thoughts to any discussion that pops up. I will tally the votes after this point on Friday, i.e. 72hrs. I'm in favour of those doing the work deciding what suits them best. Git is now well enough established that switching isn't in any real sense raising a barrier to new contributors. Just to be certain, is your reply to be taken as +1 vote Gordon? It's more in the category of 'contributing my thoughts' :-) I'm not going to be immediately involved, so I feel odd voting on it and since I don't think you are short of votes, I'm just saying explicitly that what you decide is alright with me. (as opposed to being silent which might be interpreted differently). - To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org For additional commands, e-mail: users-h...@qpid.apache.org
Re: Java QMF library and ObjectId
Hello Fraser and thanks for an exhaustive answer.
There are still some foggy parts in this behavior for me, but let me clarify
firstly some parts which were not explained clearly from my side:
* we are connecting to the C++ Qpid broker
* we are really using asynchronous mechanism from Java QMF API:
>From what you have written we might be really the only users using
query+subscribe mechanism :) but we are quite satisfied with it. In
particular, what we do is following:
- create qmfPredicate describing what kind of objects are we interested in
- create subscription based on the query using the predicate
- register subscription to the console
- in the onEvent() callback we receive updates and from the WorkItem we
finally mine the List with that ObjectId(s) using which we
identify what was changed/deleted/added and store it in our internal
structures
Now why do we have a problem with the 'recycled' ObjectIds. Because of
auditing/monitoring reasons we need to keep track of also deleted objects on
the broker (for some time). Things are more complicated since objects can
reference each other - e.g. binding references queue and exchange it binds
together. However, if the references are the same for deleted and newly
created objects (with the same name) it is quite a challenge to keep track
of what is referencing what.
Of course, if it is given by the broker, there is not too much we can do
about it.
Now, what still puzzles me:
* from the Python I have been using qmf.console API and again it's
asynchronous mechanism to receive object's updates. Briefly:
...Session(self.eventListener, rcvObjects=True, manageConnections=True,
userBindings=True, rcvEvents=True)
...bindClass("org.apache.qpid.broker", "queue")
where eventListener implements objectProps(self, broker, record) and
objectStats(self, broker, record) callbacks. From here I am getting Object
ID:
oid = record.getObjectId()
and here I can see that the ID has a different ('more unique') format: e.g.
the same queue recreated had 0-2-1-0-15440 and later after deletion
0-2-1-0-1592.
I can buy the argument that it uses older QMF1 protocol, but looking into
the code of console.py I can see that it supports both QMF1 + QMF2 and if
the QMF2 is available, the temporary request/response queues created should
have form qmfc-v2-... - which is exactly what I can see on the broker.
This makes me think: is my Python client communicating with QMF1 or QMF2? If
QMF2 why do I see different ObjectId's than in Java QMF if they should be
generated by the broker?
Is there something I am missing?
Thank you.
Cheers,
Michal
--
View this message in context:
http://qpid.2158936.n2.nabble.com/Re-Java-QMF-library-and-ObjectId-tp7613784p7613803.html
Sent from the Apache Qpid users mailing list archive at Nabble.com.
-
To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org
For additional commands, e-mail: users-h...@qpid.apache.org
Re: Qpid with RabbitMQ and Glassfish4 SOLVED
On 09/17/2014 10:43 PM, Nathan Kunkee wrote: On 09/15/2014 03:35 PM, Nathan Kunkee wrote: Hi all, I'm trying to get QPID JCA adapter, Glassfish, and RabbitMQ to work together. At this point, I believe that the Destination is not recreated correctly from the initial Queue when creating a MessageProducer. I can see in the log messages that the Queue is populated correctly when initially created, but later when the Session is creating the MessageProducer, it is empty, causing AMQNoRouteException. It would be really nice if this could be addressed in your next release. I downloaded the 0.30-rc code (r6489 I think) and built with maven, with one change as listed below. It allows use of the JCA adapter if transactions are not required. When I create a MessageProducer, I get the following error: org.apache.qpid.client.AMQNoRouteException: Error: NO_ROUTE [error code 312: no route] Hi all, I reproduced this using Wildfly, which at least caused me to look closer at the error message. In this case, the error was in the bounced message handler, which I missed earlier. RabbitMQ was rejecting the message as it decided the routing was too vague. When I updated my BURL destination string to include exchange, queue, and routing key (BURL:direct://outbound/hello/fromjava), then I was able to send outbound messages successfully. I have been able to get inbound messages from RabbitMQ working by setting the ActivationConfigProperty destination to the JNDI name of the queue, and useLocalTx to true. I also ran into issue QPID-5906 and had to set the -DIMMEDIATE_PREFETCH=true property. My glassfish-ejb-jar.xml maps the bean name, jndi name, and resource adapter module name together as required by Glassfish. Hopefully this is helpful to someone else! I'm sure it will be, thanks for taking the time to update the list. I'm afraid I have no expertise with the JCA adapter. Regarding your patch, could you attach it to a JIRA? That's the best mechanism for getting it applied. - To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org For additional commands, e-mail: users-h...@qpid.apache.org
Re: 0.30 release update - Release notes preview
On 09/17/2014 10:16 AM, Erik Aschenbrenner wrote: Hi Qpid-Devs, when can we expect the release of Qpid 0.30? A release candidate has been produced and a vote on the artefacts has been initiated. Unless there are any blocking issues identified at this stage it should not be too long to get the RC published, possibly next week some time, at the latest I would hope the week after that. - To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org For additional commands, e-mail: users-h...@qpid.apache.org
Re: [VOTE] Migrate the repo for the new JMS client work to use Git
On 17 September 2014 09:25, Gordon Sim wrote: > On 09/16/2014 05:35 PM, Robbie Gemmell wrote: > >> Hello all, >> >> I mentioned this briefly in a previous thread, and have decided just to >> call a vote on the subject. I would like to migrate the repo for the new >> JMS client work to use Git rather than Subversion. >> >> This wont affect the rest of the Qpid codebase, though it could be viewed >> as a test for any such move in future. Only the bits in the following >> subtree are under consideration for migation at this time: >> http://svn.apache.org/repos/asf/qpid/jms/ >> >> I believe it would make things easier for those of us currently working on >> it, and ease future usage of things like the Github integration we >> can/should have Apache infra enable. For anyone still wanting to use a >> Subversion client to check things out, there will still be an option there >> as e.g. Github repos can also be checked out with svn clients, and Apache >> mirror things to Github. >> >> Please cast your votes. Even if you don't intend to work on the code in >> question, please vote or at least contribute your thoughts to any >> discussion that pops up. I will tally the votes after this point on >> Friday, >> i.e. 72hrs. >> > > I'm in favour of those doing the work deciding what suits them best. Git > is now well enough established that switching isn't in any real sense > raising a barrier to new contributors. > > Just to be certain, is your reply to be taken as +1 vote Gordon? Robbie
Re: [VOTE] Migrate the repo for the new JMS client work to use Git
Adding my fairly obvious +1 explicitly, as I always forget to do it in the initial mail. Robbie On 16 September 2014 17:35, Robbie Gemmell wrote: > Hello all, > > I mentioned this briefly in a previous thread, and have decided just to > call a vote on the subject. I would like to migrate the repo for the new > JMS client work to use Git rather than Subversion. > > This wont affect the rest of the Qpid codebase, though it could be viewed > as a test for any such move in future. Only the bits in the following > subtree are under consideration for migation at this time: > http://svn.apache.org/repos/asf/qpid/jms/ > > I believe it would make things easier for those of us currently working on > it, and ease future usage of things like the Github integration we > can/should have Apache infra enable. For anyone still wanting to use a > Subversion client to check things out, there will still be an option there > as e.g. Github repos can also be checked out with svn clients, and Apache > mirror things to Github. > > Please cast your votes. Even if you don't intend to work on the code in > question, please vote or at least contribute your thoughts to any > discussion that pops up. I will tally the votes after this point on Friday, > i.e. 72hrs. > > Robbie >
Re: QPID C++ - Dynamically Managing Broker
On 09/18/2014 12:56 AM, Spencer.Doak wrote: Hello, I'm faced with a bit of an issue. For an application I'm working on, I'm in need of several abilities: 1. Create, destroy, and clear queues on an exchange. 2. Create and destroy exchanges on a broker. 3. Fetch a list of all existing connections on a broker. 4. If possible, send a management message telling the broker to shutdown. 5. Verify the existence of a queue. (I have a workaround for this) Based on what I've been reading, I believe QMF would be the way to go for this. The issue is that I cannot seem to find much information about QMF despite all of the digging I've been doing. Yes, sorry about that, it is indeed not documented very well at all. Fortunately, it's quite simple. All you do is send specially structured map messages to the broker of interest, and then process the replies that come back. There are two categories of request. The first is a method request, the two methods of most interest being 'create' and 'delete'. With these you can create or delete queues, exchanges and bindings. The second category is a query request. With these you get back the objects of a particular type (e.g. connection, queue, exchange) or indeed a specific object by id. All qmf request messages are sent to 'qmf.default.direct/broker '(i.e. to the exchange named 'qmf.default.direct', with a routing key or subject of 'broker'). The message should contain a reply-to address through which responses will be sent. There are two message properties that must also be set. These are 'x-amqp-0-10.app-id', which should always have the value 'qmf2' and 'qmf.opcode' which for method requests should always have the value '_method_request' and for query requests should have the value '_query_request'. For a method requests the content is a map with three top-level entries. The first is an entry with key _object_id whose value is a nested map identifying the target of the command. For the commands considered here (create and delete) the target is always the broker itself. Thus the _object_id map contains a single value with key _object_name and value org.apache.qpid.broker:broker:amqp-broker. The second is an entry with key '_method_name' whose value is the method name (i.e. create or delete). The third is an entry with key '_arguments' which is a nested map represention the arguments to the method. For create and delete, the name and type arguments are required. For create you often want an additional 'properties' entry, whose value is a nested map containing the properties of the object you want to create (e.g. for a queue qpid.max_count or similar). For a query request the content is a map with one entry named '_schema_id' that usually contains a nested map with one entry, '_class_name' containing the type of object to query, e.g. queue, exchange etc. In addition there is an entry with key '_what' and value 'OBJECT'. The expected response for a method request will have the qmf.opcode property set to _method_response. For a query request it will be _query_response. I've attached a very rudimentary example that shows create, delete and querying which I suspect is easier to follow then the textual description of the structure. To use it specify one of create, delete or list and a type (queue, exchange, binding etc). For create and delete you also need a 'name'. The 'name' for a binding is a concatenation of exchange name, queue name and key name, with '/' separating them. E.g. qmf_ctrl create queue my-queue qmf_ctrl create exchange my-exchange qmf_ctrl create binding my-exchange/my-queue/my-key qmf_ctrl create queue another-queue qmf_ctrl list queue qmf_ctrl create queue another-queue qmf_ctrl list queue qmf_ctrl list connection Hopefully this is enough to get you started. If you have further questions please don't hesitate to ask. Regarding point 4. in your mail, there is at present no way to shutdown the broker via qmf. You could perhaps create a special 'agent' program to do that. I.e. it would run colocated with the broker, and listen on a special address for a shutdown message, on receiving which it would send a signal to the broker. You might want some sort of security around that, either message based or acl controls on the address in question for the broker. --Gordon. /* * * Licensed to the Apache Software Foundation (ASF) under one * or more contributor license agreements. See the NOTICE file * distributed with this work for additional information * regarding copyright ownership. The ASF licenses this file * to you under the Apache License, Version 2.0 (the * "License"); you may not use this file except in compliance * with the License. You may obtain a copy of the License at * * http://www.apache.org/licenses/LICENSE-2.0 * * Unless required by applicable law or agreed to in writing, * software distributed under the License is distributed on an * "AS IS
