deploying Qpid via Cloud Foundry
On the IRC channel last week rgodfrey mentioned that some of you may be deploying Qpid via Cloud Foundry. I am exploring some of those ideas for use at my place of employment and was wondering if I could pick your brain a little bit on what that setup might look like. Please forgive me if my questions sound a bit obvious or naive im a bit new to some of these concepts. Initially I had not considered deploying Qpid via CloudFoundry. I was just planning an integration with our on-prem CF. I need a service broker for Qpid. Have any of you set up Qpid as a service in your CF setup? Did you write the service broker layer? Or is there an open source one already available? I have never written a service broker before so if you have any tips in regards to Qpid and a service broker they would be welcome. What is your pattern for a Qpid service in CF? Do you have a CF service representing a single Queue? Or representing a VirtualHost? or does a new service spin up an independent instance of Qpid? Would it be feasible for a service to represent a Vhost and be associated ~1:1 to a CF "space", making it so a "space" named "project-a-non-prod" would have a VHost named the same? So with the recent addition of a GroupProvider that backed by a CF Service dashboard could somebody explain how that flow works? Does CF provide a URL to manage the service and that URL has an accessToken in it? Or does accessing the web admin redirect over to another url for authorization and then redirect the user back to the web admin? Does/Can this groupProvider be used for system-to-system access? We call those "service accounts" at work. Or is it more appropriate for mainly User access to the web admin area? How are you granting users access to a queue? I assume you are using the HTTP api around RuleBased access control provider? or is that not needed with proper use of the aforementioned GroupProvider? Are you spinning up single instances of Qpid as apps in CF to be used in isolation and for specific purposes? Or do you have many Qpid CF instances forming a large HA network of brokers accessed via Dispatch Routers? Are you using CF TCP Routing or strictly HTTP/WS access or just connecting directly to the host or a Dispatch Router? Thank you so much for taking the time to glance over this and offer any help you can in my understanding. I apologize if it seems that i have not done my homework yet. I will have more throughput in the coming weeks to start playing with it more hands on I was just hoping to get an idea of a good direction to get headed off in, one that already had proven success. Dan '8bagels' Langford UTC-0700
Re: Using QMF to get information about consumers/producers
On 28/02/17 21:10, mottese wrote:
Do you know how I would obtain the incoming links?
Basically you just do a query where the _class_name is 'incoming'
(probably similar to what you do for queues, but with a different type?).
Attached is a simple example that prints a count of the number of (AMQP
1.0 based) sender links by target address.
/*
*
* 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" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
* KIND, either express or implied. See the License for the
* specific language governing permissions and limitations
* under the License.
*
*/
#include
#include
#include
#include
#include
#include
#include
#include
using namespace qpid::messaging;
using namespace qpid::types;
using std::string;
int main(int argc, char** argv)
{
Connection c(argc > 1 ? argv[1] : "localhost", "{protocol:amqp1.0}");
try {
c.open();
Session session = c.createSession();
Receiver r = session.createReceiver("#");
Sender s = session.createSender("qmf.default.direct/broker");
Message request;
request.setReplyTo(r.getAddress());
request.setProperty("x-amqp-0-10.app-id", "qmf2");
request.setProperty("qmf.opcode", "_query_request");
Variant::Map schemaId;
schemaId["_class_name"] = "incoming";
Variant::Map content;
content["_what"] = "OBJECT";
content["_schema_id"] = schemaId;
request.setContentObject(content);
s.send(request);
std::map counts;
Message response = r.fetch();
Variant::List contentIn = response.getContentObject().asList();
for (Variant::List::const_iterator i = contentIn.begin(); i != contentIn.end(); ++i) {
Variant::Map item = i->asMap();
counts[item["_values"].asMap()["target"]]++;
}
for (std::map::const_iterator i = counts.begin(); i != counts.end(); ++i) {
std::cout << i->first << ": " << i->second << std::endl;
}
session.acknowledge();
} catch(const std::exception& error) {
std::cout << "ERROR: " << error.what() << std::endl;
}
c.close();
return 0;
}
-
To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org
For additional commands, e-mail: users-h...@qpid.apache.org
Re: Using QMF to get information about consumers/producers
Do you know how I would obtain the incoming links? I'm trying to find out how, but I can't find very much doc on QMF. -- View this message in context: http://qpid.2158936.n2.nabble.com/Using-QMF-to-get-information-about-consumers-producers-tp7659741p7659748.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: Using QMF to get information about consumers/producers
On 28/02/17 20:31, mottese wrote: Thanks for the quick reply. Incoming links sounds like what I am looking for. I am using AMQP 1.0, so that's not a problem. Ok, good. My previous reply was a little incorrect. You can't actually retrieve the incoming links only for a given target. You would need to retrieve all the incoming links then filter yourself on the target. - To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org For additional commands, e-mail: users-h...@qpid.apache.org
Re: Using QMF to get information about consumers/producers
Thanks for the quick reply. Incoming links sounds like what I am looking for. I am using AMQP 1.0, so that's not a problem. -- View this message in context: http://qpid.2158936.n2.nabble.com/Using-QMF-to-get-information-about-consumers-producers-tp7659741p7659745.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: Using QMF to get information about consumers/producers
On 28/02/17 18:58, mottese wrote:
Hi, I'm using the Qpid 1.36 C++ client and I'm trying to use QMF to get
information about how many producers/consumers a queue has. Currently, I can
get how many consumers a queue has by using this request:
request.setReplyTo(receiver.getAddress());
request.setProperty("x-amqp-0-10.app-id", "qmf2");
request.setProperty("qmf.opcode", "_query_request");
Variant::Map schemaId, content;
schemaId["_class_name"] = "queue";
schemaId["_object_name"] = "org.apache.qpid.broker:queue:" + queueName;
content["_what"] = "OBJECT";
content["_object_id"] = schemaId;
request.setContentObject(content);
And then doing this to get the number of consumers:
Variant::List list = response.getContentObject().asList();
Variant::Map item = list.begin()->asMap();
Variant::Map values = item["_values"].asMap();
int consumers = values["consumerCount"];
How can I modify this to get the number of producers? I tried subbing
consumerCount for producerCount but then values["producerCount"] returned a
void, even though in my test I know I had a sender set up.
AMQP 0-10 had no concept of producers, so there isn't a general producer
count. AMQP 1.0 does have sending links and you can get the list of
'incoming' links to a given queue (but these will only exist if you are
using AMQP 1.0).
-
To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org
For additional commands, e-mail: users-h...@qpid.apache.org
Re: [Qpid Dispatch - 0.7.0] Random failure on unit test "system_tests_link_routes" on Linux
Hi Adel, Thanks for sending the trace. I realized that what I actually wanted to see is the log files of all routers so I can get a complete view of the traffic between the routers. Can you please zip up the contents of the /build/system_test.dir/system_tests_link_routes/LinkRouteTest/setUpClass folder and send it? Before you zip up the contents of that folder, please delete all the contents of the folder and then run only the relevant test like this - /usr/bin/python "/build/tests/run.py" "-m" "unittest" "-v" "system_tests_link_routes.LinkRouteTest.test_www_drain_support_all_messages" (this way, the log files will only have the trace from the relevant test) Thanks much. - Original Message - > From: "Adel Boutros" > To: users@qpid.apache.org > Sent: Tuesday, February 28, 2017 1:08:53 PM > Subject: Re: [Qpid Dispatch - 0.7.0] Random failure on unit test > "system_tests_link_routes" on Linux > > > > You will find attached the result of the below command. > > > > > Adel > > From: Ganesh Murthy > Sent: Tuesday, February 28, 2017 6:51:42 PM > To: users@qpid.apache.org > Subject: Re: [Qpid Dispatch - 0.7.0] Random failure on unit test > "system_tests_link_routes" on Linux > Hi Adel, > Can you please run that specific unit test with PN_TRACE_FRM=1 and send the > output. This is how you run the specific test - > > PN_TRACE_FRM=1 /usr/bin/python "/build/tests/run.py" > "-m" "unittest" "-v" > "system_tests_link_routes.LinkRouteTest.test_www_drain_support_all_messages" > > Thanks. > > - Original Message - > > From: "Adel Boutros" > > To: users@qpid.apache.org > > Sent: Tuesday, February 28, 2017 10:20:42 AM > > Subject: Re: [Qpid Dispatch - 0.7.0] Random failure on unit test > > "system_tests_link_routes" on Linux > > > > Hi Ganesh, > > > > > > Yes, I had checked your fix but it doesn't seem to work here. Indeed, the > > test is still failing even when timeout is increased to 100. > > > > > > It seems the drain is always only receiving 8 messages out of 10. I didn't > > check it on the trunk however to see if it is fixed. > > > > > > Regards, > > > > Adel > > > > > > From: Ganesh Murthy > > Sent: Tuesday, February 28, 2017 3:58:37 PM > > To: users@qpid.apache.org > > Subject: Re: [Qpid Dispatch - 0.7.0] Random failure on unit test > > "system_tests_link_routes" on Linux > > > > Hi Adel, > > We did notice the same problem you are seeing and we did end up increasing > > the timeout from 5 to 10 (although on a different test) as seen in this > > commit on master branch - > > > > https://github.com/apache/qpid-dispatch/commit/5e6b2e65b2ea9614d7619711961d38aceefb49d4 > > > > Is it correct that even when you increased the timeout to 100, the test > > still > > fails randomly? > > > > Thanks. > > > > - Original Message - > > > From: "Adel Boutros" > > > To: users@qpid.apache.org > > > Sent: Tuesday, February 28, 2017 9:00:36 AM > > > Subject: Re: [Qpid Dispatch - 0.7.0] Random failure on unit test > > > "system_tests_link_routes" on Linux > > > > > > I increased the timeout from 5 to 100 and the test which now takes 110 > > > seconds instead of 10 seconds is still failing. After re-checking, the > > > error > > > message is actually the same on each failure. I think there is an issue > > > here. > > > > > > > > > My patch: > > > > > > > > > diff --git a/tests/system_tests_drain_support.py > > > b/tests/system_tests_drain_support.py > > > index e4bd2bc..9a4a86f 100644 > > > --- a/tests/system_tests_drain_support.py > > > +++ b/tests/system_tests_drain_support.py > > > @@ -46,7 +46,7 @@ class DrainMessagesHandler(MessagingHandler): > > > self.conn.close() > > > > > > def on_start(self, event): > > > - self.timer = event.reactor.schedule(5, Timeout(self)) > > > + self.timer = event.reactor.schedule(100, Timeout(self)) > > > self.conn = event.container.connect(self.address) > > > > > > # Create a sender and a receiver. They are both listening on the > > > same address > > > > > > > > > == > > > > > > Error > > > > > > === > > > > > > > > > 13: FAIL: test_www_drain_support_all_messages > > > (system_tests_link_routes.LinkRouteTest) > > > 13: > > > -- > > > 13: Traceback (most recent call last): > > > 13: File "/qpid-dispatch-0.7.0/tests/system_tests_link_routes.py", line > > > 489, in test_www_drain_support_all_messages > > > 13: self.assertEqual(None, drain_support.error) > > > 13: AssertionError: None != 'Timeout Expired: sent: 10 rcvd: 8' > > > 13: > > > 13: > > > -- > > > 13: Ran 15 tests in 109.933s > > > 13: > > > 13: FAILED (failures=1) > > > 1/1 Test #13: system_tests_link_routes .***Failed 110.16 sec > > > > > > Regards, > > > > > > Adel > > > > > > > > > From: Adel Boutros > > > Sent: Tuesday, F
Using QMF to get information about consumers/producers
Hi, I'm using the Qpid 1.36 C++ client and I'm trying to use QMF to get
information about how many producers/consumers a queue has. Currently, I can
get how many consumers a queue has by using this request:
request.setReplyTo(receiver.getAddress());
request.setProperty("x-amqp-0-10.app-id", "qmf2");
request.setProperty("qmf.opcode", "_query_request");
Variant::Map schemaId, content;
schemaId["_class_name"] = "queue";
schemaId["_object_name"] = "org.apache.qpid.broker:queue:" + queueName;
content["_what"] = "OBJECT";
content["_object_id"] = schemaId;
request.setContentObject(content);
And then doing this to get the number of consumers:
Variant::List list = response.getContentObject().asList();
Variant::Map item = list.begin()->asMap();
Variant::Map values = item["_values"].asMap();
int consumers = values["consumerCount"];
How can I modify this to get the number of producers? I tried subbing
consumerCount for producerCount but then values["producerCount"] returned a
void, even though in my test I know I had a sender set up.
Thanks
--
View this message in context:
http://qpid.2158936.n2.nabble.com/Using-QMF-to-get-information-about-consumers-producers-tp7659741.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 Dispatch - 0.7.0] Random failure on unit test "system_tests_link_routes" on Linux
You will find attached the result of the below command. Adel From: Ganesh Murthy Sent: Tuesday, February 28, 2017 6:51:42 PM To: users@qpid.apache.org Subject: Re: [Qpid Dispatch - 0.7.0] Random failure on unit test "system_tests_link_routes" on Linux Hi Adel, Can you please run that specific unit test with PN_TRACE_FRM=1 and send the output. This is how you run the specific test - PN_TRACE_FRM=1 /usr/bin/python "/build/tests/run.py" "-m" "unittest" "-v" "system_tests_link_routes.LinkRouteTest.test_www_drain_support_all_messages" Thanks. - Original Message - > From: "Adel Boutros" > To: users@qpid.apache.org > Sent: Tuesday, February 28, 2017 10:20:42 AM > Subject: Re: [Qpid Dispatch - 0.7.0] Random failure on unit test > "system_tests_link_routes" on Linux > > Hi Ganesh, > > > Yes, I had checked your fix but it doesn't seem to work here. Indeed, the > test is still failing even when timeout is increased to 100. > > > It seems the drain is always only receiving 8 messages out of 10. I didn't > check it on the trunk however to see if it is fixed. > > > Regards, > > Adel > > > From: Ganesh Murthy > Sent: Tuesday, February 28, 2017 3:58:37 PM > To: users@qpid.apache.org > Subject: Re: [Qpid Dispatch - 0.7.0] Random failure on unit test > "system_tests_link_routes" on Linux > > Hi Adel, >We did notice the same problem you are seeing and we did end up increasing >the timeout from 5 to 10 (although on a different test) as seen in this >commit on master branch - > > https://github.com/apache/qpid-dispatch/commit/5e6b2e65b2ea9614d7619711961d38aceefb49d4 > > Is it correct that even when you increased the timeout to 100, the test still > fails randomly? > > Thanks. > > - Original Message - > > From: "Adel Boutros" > > To: users@qpid.apache.org > > Sent: Tuesday, February 28, 2017 9:00:36 AM > > Subject: Re: [Qpid Dispatch - 0.7.0] Random failure on unit test > > "system_tests_link_routes" on Linux > > > > I increased the timeout from 5 to 100 and the test which now takes 110 > > seconds instead of 10 seconds is still failing. After re-checking, the > > error > > message is actually the same on each failure. I think there is an issue > > here. > > > > > > My patch: > > > > > > diff --git a/tests/system_tests_drain_support.py > > b/tests/system_tests_drain_support.py > > index e4bd2bc..9a4a86f 100644 > > --- a/tests/system_tests_drain_support.py > > +++ b/tests/system_tests_drain_support.py > > @@ -46,7 +46,7 @@ class DrainMessagesHandler(MessagingHandler): > > self.conn.close() > > > > def on_start(self, event): > > -self.timer = event.reactor.schedule(5, Timeout(self)) > > +self.timer = event.reactor.schedule(100, Timeout(self)) > > self.conn = event.container.connect(self.address) > > > > # Create a sender and a receiver. They are both listening on the > > same address > > > > > > == > > > > Error > > > > === > > > > > > 13: FAIL: test_www_drain_support_all_messages > > (system_tests_link_routes.LinkRouteTest) > > 13: -- > > 13: Traceback (most recent call last): > > 13: File "/qpid-dispatch-0.7.0/tests/system_tests_link_routes.py", line > > 489, in test_www_drain_support_all_messages > > 13: self.assertEqual(None, drain_support.error) > > 13: AssertionError: None != 'Timeout Expired: sent: 10 rcvd: 8' > > 13: > > 13: -- > > 13: Ran 15 tests in 109.933s > > 13: > > 13: FAILED (failures=1) > > 1/1 Test #13: system_tests_link_routes .***Failed 110.16 sec > > > > Regards, > > > > Adel > > > > > > From: Adel Boutros > > Sent: Tuesday, February 28, 2017 2:47:16 PM > > To: users@qpid.apache.org > > Subject: [Qpid Dispatch - 0.7.0] Random failure on unit test > > "system_tests_link_routes" on Linux > > > > Hello, > > > > > > I noticed a random issue with the Dispatch Router 0.7.0 which has a random > > failure in the test "system_tests_link_routes". > > > > I launch the same test 10 times, it fails randomly (Failure occurs at the > > 4th > > or 5th run) but always with a similar error. It seems the timeout of 5 > > milliseconds is not enough especially on slow machines. > > > > > > I had submitted a patch for a similar task > > (https://issues.apache.org/jira/browse/DISPATCH-627) > > > > > > Can you please confirm? > > > > > > Regards, > > > > Adel > > > > > > 13: == > > 13: FAIL: test_www_drain_support_all_messages > > (system_tests_link_routes.LinkRouteTest) > > 13: -- > > 13: Traceback (most recent call last): > > 13: File "/qpid-dispatch-0.7.0/tests/system_tests_link_routes.py", line > > 489, in test_ww
Re: [Qpid Dispatch - 0.7.0] Random failure on unit test "system_tests_link_routes" on Linux
Hi Adel, Can you please run that specific unit test with PN_TRACE_FRM=1 and send the output. This is how you run the specific test - PN_TRACE_FRM=1 /usr/bin/python "/build/tests/run.py" "-m" "unittest" "-v" "system_tests_link_routes.LinkRouteTest.test_www_drain_support_all_messages" Thanks. - Original Message - > From: "Adel Boutros" > To: users@qpid.apache.org > Sent: Tuesday, February 28, 2017 10:20:42 AM > Subject: Re: [Qpid Dispatch - 0.7.0] Random failure on unit test > "system_tests_link_routes" on Linux > > Hi Ganesh, > > > Yes, I had checked your fix but it doesn't seem to work here. Indeed, the > test is still failing even when timeout is increased to 100. > > > It seems the drain is always only receiving 8 messages out of 10. I didn't > check it on the trunk however to see if it is fixed. > > > Regards, > > Adel > > > From: Ganesh Murthy > Sent: Tuesday, February 28, 2017 3:58:37 PM > To: users@qpid.apache.org > Subject: Re: [Qpid Dispatch - 0.7.0] Random failure on unit test > "system_tests_link_routes" on Linux > > Hi Adel, >We did notice the same problem you are seeing and we did end up increasing >the timeout from 5 to 10 (although on a different test) as seen in this >commit on master branch - > > https://github.com/apache/qpid-dispatch/commit/5e6b2e65b2ea9614d7619711961d38aceefb49d4 > > Is it correct that even when you increased the timeout to 100, the test still > fails randomly? > > Thanks. > > - Original Message - > > From: "Adel Boutros" > > To: users@qpid.apache.org > > Sent: Tuesday, February 28, 2017 9:00:36 AM > > Subject: Re: [Qpid Dispatch - 0.7.0] Random failure on unit test > > "system_tests_link_routes" on Linux > > > > I increased the timeout from 5 to 100 and the test which now takes 110 > > seconds instead of 10 seconds is still failing. After re-checking, the > > error > > message is actually the same on each failure. I think there is an issue > > here. > > > > > > My patch: > > > > > > diff --git a/tests/system_tests_drain_support.py > > b/tests/system_tests_drain_support.py > > index e4bd2bc..9a4a86f 100644 > > --- a/tests/system_tests_drain_support.py > > +++ b/tests/system_tests_drain_support.py > > @@ -46,7 +46,7 @@ class DrainMessagesHandler(MessagingHandler): > > self.conn.close() > > > > def on_start(self, event): > > -self.timer = event.reactor.schedule(5, Timeout(self)) > > +self.timer = event.reactor.schedule(100, Timeout(self)) > > self.conn = event.container.connect(self.address) > > > > # Create a sender and a receiver. They are both listening on the > > same address > > > > > > == > > > > Error > > > > === > > > > > > 13: FAIL: test_www_drain_support_all_messages > > (system_tests_link_routes.LinkRouteTest) > > 13: -- > > 13: Traceback (most recent call last): > > 13: File "/qpid-dispatch-0.7.0/tests/system_tests_link_routes.py", line > > 489, in test_www_drain_support_all_messages > > 13: self.assertEqual(None, drain_support.error) > > 13: AssertionError: None != 'Timeout Expired: sent: 10 rcvd: 8' > > 13: > > 13: -- > > 13: Ran 15 tests in 109.933s > > 13: > > 13: FAILED (failures=1) > > 1/1 Test #13: system_tests_link_routes .***Failed 110.16 sec > > > > Regards, > > > > Adel > > > > > > From: Adel Boutros > > Sent: Tuesday, February 28, 2017 2:47:16 PM > > To: users@qpid.apache.org > > Subject: [Qpid Dispatch - 0.7.0] Random failure on unit test > > "system_tests_link_routes" on Linux > > > > Hello, > > > > > > I noticed a random issue with the Dispatch Router 0.7.0 which has a random > > failure in the test "system_tests_link_routes". > > > > I launch the same test 10 times, it fails randomly (Failure occurs at the > > 4th > > or 5th run) but always with a similar error. It seems the timeout of 5 > > milliseconds is not enough especially on slow machines. > > > > > > I had submitted a patch for a similar task > > (https://issues.apache.org/jira/browse/DISPATCH-627) > > > > > > Can you please confirm? > > > > > > Regards, > > > > Adel > > > > > > 13: == > > 13: FAIL: test_www_drain_support_all_messages > > (system_tests_link_routes.LinkRouteTest) > > 13: -- > > 13: Traceback (most recent call last): > > 13: File "/qpid-dispatch-0.7.0/tests/system_tests_link_routes.py", line > > 489, in test_www_drain_support_all_messages > > 13: self.assertEqual(None, drain_support.error) > > 13: AssertionError: None != 'Timeout Expired: sent: 10 rcvd: 8' > > > > > > > > - > To unsubscribe, e-mail: users-unsu
Re: Performance degradation with Qpid JMS Client 0.20.0
On 02/28/2017 08:10 AM, Oleksandr Rudyy wrote: Hi all, After upgrading Qpid JMS Client from version 0.11.0 to version 0.20.0 our performance test results dropped approximately on 20-25% in the performance tests testing transaction performance with trunk version of Qpid Java Broker. Changing client back to v0.11.0 and re-running the tests yields me the same results as before the upgrade. What changes on the client could be the reason for a performance drop? There was a great deal of change in the client to implement the extra bits needed to meet the JMS 2.0 specification requirements along with other changes to handle of the more interesting edge cases around JMS usages so it'd be hard to just pull out one change as the culprit without more research. I'm not that surprised that there were some impacts. What would be helpful would be to pull out one affected test case where you see this drop in performance into a standalone test so we could run it in the Qpid JMS test suite and do some digging. The performance test creates 10 publishing connections and 10 consuming connections. They produce/consume every message in separate transactions. The consumer is synchronous. Each pair of producer and consumer uses its own queue. Kind Regards, Alex - To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org For additional commands, e-mail: users-h...@qpid.apache.org -- Tim Bish twitter: @tabish121 blog: http://timbish.blogspot.com/ - To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org For additional commands, e-mail: users-h...@qpid.apache.org
Re: [Qpid Dispatch - 0.7.0] Random failure on unit test "system_tests_link_routes" on Linux
Hi Ganesh, Yes, I had checked your fix but it doesn't seem to work here. Indeed, the test is still failing even when timeout is increased to 100. It seems the drain is always only receiving 8 messages out of 10. I didn't check it on the trunk however to see if it is fixed. Regards, Adel From: Ganesh Murthy Sent: Tuesday, February 28, 2017 3:58:37 PM To: users@qpid.apache.org Subject: Re: [Qpid Dispatch - 0.7.0] Random failure on unit test "system_tests_link_routes" on Linux Hi Adel, We did notice the same problem you are seeing and we did end up increasing the timeout from 5 to 10 (although on a different test) as seen in this commit on master branch - https://github.com/apache/qpid-dispatch/commit/5e6b2e65b2ea9614d7619711961d38aceefb49d4 Is it correct that even when you increased the timeout to 100, the test still fails randomly? Thanks. - Original Message - > From: "Adel Boutros" > To: users@qpid.apache.org > Sent: Tuesday, February 28, 2017 9:00:36 AM > Subject: Re: [Qpid Dispatch - 0.7.0] Random failure on unit test > "system_tests_link_routes" on Linux > > I increased the timeout from 5 to 100 and the test which now takes 110 > seconds instead of 10 seconds is still failing. After re-checking, the error > message is actually the same on each failure. I think there is an issue > here. > > > My patch: > > > diff --git a/tests/system_tests_drain_support.py > b/tests/system_tests_drain_support.py > index e4bd2bc..9a4a86f 100644 > --- a/tests/system_tests_drain_support.py > +++ b/tests/system_tests_drain_support.py > @@ -46,7 +46,7 @@ class DrainMessagesHandler(MessagingHandler): > self.conn.close() > > def on_start(self, event): > -self.timer = event.reactor.schedule(5, Timeout(self)) > +self.timer = event.reactor.schedule(100, Timeout(self)) > self.conn = event.container.connect(self.address) > > # Create a sender and a receiver. They are both listening on the > same address > > > == > > Error > > === > > > 13: FAIL: test_www_drain_support_all_messages > (system_tests_link_routes.LinkRouteTest) > 13: -- > 13: Traceback (most recent call last): > 13: File "/qpid-dispatch-0.7.0/tests/system_tests_link_routes.py", line > 489, in test_www_drain_support_all_messages > 13: self.assertEqual(None, drain_support.error) > 13: AssertionError: None != 'Timeout Expired: sent: 10 rcvd: 8' > 13: > 13: -- > 13: Ran 15 tests in 109.933s > 13: > 13: FAILED (failures=1) > 1/1 Test #13: system_tests_link_routes .***Failed 110.16 sec > > Regards, > > Adel > > > From: Adel Boutros > Sent: Tuesday, February 28, 2017 2:47:16 PM > To: users@qpid.apache.org > Subject: [Qpid Dispatch - 0.7.0] Random failure on unit test > "system_tests_link_routes" on Linux > > Hello, > > > I noticed a random issue with the Dispatch Router 0.7.0 which has a random > failure in the test "system_tests_link_routes". > > I launch the same test 10 times, it fails randomly (Failure occurs at the 4th > or 5th run) but always with a similar error. It seems the timeout of 5 > milliseconds is not enough especially on slow machines. > > > I had submitted a patch for a similar task > (https://issues.apache.org/jira/browse/DISPATCH-627) > > > Can you please confirm? > > > Regards, > > Adel > > > 13: == > 13: FAIL: test_www_drain_support_all_messages > (system_tests_link_routes.LinkRouteTest) > 13: -- > 13: Traceback (most recent call last): > 13: File "/qpid-dispatch-0.7.0/tests/system_tests_link_routes.py", line > 489, in test_www_drain_support_all_messages > 13: self.assertEqual(None, drain_support.error) > 13: AssertionError: None != 'Timeout Expired: sent: 10 rcvd: 8' > > > - To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org For additional commands, e-mail: users-h...@qpid.apache.org
Re: [Qpid Dispatch - 0.7.0] Random failure on unit test "system_tests_link_routes" on Linux
Hi Adel, We did notice the same problem you are seeing and we did end up increasing the timeout from 5 to 10 (although on a different test) as seen in this commit on master branch - https://github.com/apache/qpid-dispatch/commit/5e6b2e65b2ea9614d7619711961d38aceefb49d4 Is it correct that even when you increased the timeout to 100, the test still fails randomly? Thanks. - Original Message - > From: "Adel Boutros" > To: users@qpid.apache.org > Sent: Tuesday, February 28, 2017 9:00:36 AM > Subject: Re: [Qpid Dispatch - 0.7.0] Random failure on unit test > "system_tests_link_routes" on Linux > > I increased the timeout from 5 to 100 and the test which now takes 110 > seconds instead of 10 seconds is still failing. After re-checking, the error > message is actually the same on each failure. I think there is an issue > here. > > > My patch: > > > diff --git a/tests/system_tests_drain_support.py > b/tests/system_tests_drain_support.py > index e4bd2bc..9a4a86f 100644 > --- a/tests/system_tests_drain_support.py > +++ b/tests/system_tests_drain_support.py > @@ -46,7 +46,7 @@ class DrainMessagesHandler(MessagingHandler): > self.conn.close() > > def on_start(self, event): > -self.timer = event.reactor.schedule(5, Timeout(self)) > +self.timer = event.reactor.schedule(100, Timeout(self)) > self.conn = event.container.connect(self.address) > > # Create a sender and a receiver. They are both listening on the > same address > > > == > > Error > > === > > > 13: FAIL: test_www_drain_support_all_messages > (system_tests_link_routes.LinkRouteTest) > 13: -- > 13: Traceback (most recent call last): > 13: File "/qpid-dispatch-0.7.0/tests/system_tests_link_routes.py", line > 489, in test_www_drain_support_all_messages > 13: self.assertEqual(None, drain_support.error) > 13: AssertionError: None != 'Timeout Expired: sent: 10 rcvd: 8' > 13: > 13: -- > 13: Ran 15 tests in 109.933s > 13: > 13: FAILED (failures=1) > 1/1 Test #13: system_tests_link_routes .***Failed 110.16 sec > > Regards, > > Adel > > > From: Adel Boutros > Sent: Tuesday, February 28, 2017 2:47:16 PM > To: users@qpid.apache.org > Subject: [Qpid Dispatch - 0.7.0] Random failure on unit test > "system_tests_link_routes" on Linux > > Hello, > > > I noticed a random issue with the Dispatch Router 0.7.0 which has a random > failure in the test "system_tests_link_routes". > > I launch the same test 10 times, it fails randomly (Failure occurs at the 4th > or 5th run) but always with a similar error. It seems the timeout of 5 > milliseconds is not enough especially on slow machines. > > > I had submitted a patch for a similar task > (https://issues.apache.org/jira/browse/DISPATCH-627) > > > Can you please confirm? > > > Regards, > > Adel > > > 13: == > 13: FAIL: test_www_drain_support_all_messages > (system_tests_link_routes.LinkRouteTest) > 13: -- > 13: Traceback (most recent call last): > 13: File "/qpid-dispatch-0.7.0/tests/system_tests_link_routes.py", line > 489, in test_www_drain_support_all_messages > 13: self.assertEqual(None, drain_support.error) > 13: AssertionError: None != 'Timeout Expired: sent: 10 rcvd: 8' > > > - To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org For additional commands, e-mail: users-h...@qpid.apache.org
Re: Patch + jira vs pull request
Thank you Ganesh for the explanation! Regards, Adel From: Ganesh Murthy Sent: Tuesday, February 28, 2017 3:31:57 PM To: users@qpid.apache.org Subject: Re: Patch + jira vs pull request A few days back, I had emailed Travis support and asked them why the builds were taking too long to start. This is what they said - "I've been taking a look at the logs and it appears that at the time when your build #199359621 was triggered, the Apache organization was running at capacity, and this delayed the start time of the jobs. At the moment, I see that the organization is running at capacity too and it has some backlog of pending jobs waiting to start. To help with this high activity peak, I've boosted Apache's capacity from 30 to 50 concurrent jobs for the next 4 hours." So, when you submitted the pull request, it simply looks like Travis was running at full capacity for Apache. It should come thru as soon as the backlog is cleared. Thanks. - Original Message - > From: "Adel Boutros" > To: users@qpid.apache.org > Sent: Tuesday, February 28, 2017 9:10:26 AM > Subject: Re: Patch + jira vs pull request > > Hello, > > > I was testing this morning the pull request mechanism. I was able to perform > the pull request however it seems Travis has not built it yet. > > Is there a way to know what's blocking it? > (https://travis-ci.org/apache/qpid-dispatch/builds/206144819) > > > Regards, > > Adel > > > From: Robbie Gemmell > Sent: Monday, February 6, 2017 4:08:13 PM > To: users@qpid.apache.org > Subject: Re: Patch + jira vs pull request > > As an aside, for anyone else wanting to do this type of thing, I used > this to add a remote called 'github' to my existing checkout and make > the PRs available at ref github/pr/: > > git remote add github https://github.com/apache/qpid-java.git > git config --local --add remote.github.fetch > '+refs/pull/*/head:refs/remotes/github/pr/*' > git fetch --all > > To use a different name for the remote, find/replace instances of > github other than in the mirror URL with your chosen remote name. To > use another repo, change the name in the URL. > > Robbie > > On 31 January 2017 at 12:26, Robbie Gemmell wrote: > > This is now enabled, see > > https://issues.apache.org/jira/browse/QPID-7650 and > > https://github.com/apache/qpid-java/pull/5 as example. > > > > Note that the mails to the dev@ list were still not seen, as something > > seems to be wrong with the list, or at least JIRA. No mails from JIRA > > are arriving, even though I have been receiving the matching/duplicate > > mails sent directly to me. Raised as > > https://issues.apache.org/jira/browse/INFRA-13432 after chatting to > > infra, likely related to the very recent JIRA upgrade. I'll give the > > PR thing another check once its clearer what the issues are. > > > > Also, while the process of closing the PR worked fine, it did take a > > good 20+mins for the commit to make it to the github mirror (via the > > asf git mirror, via svn) and close it, as opposed to the near instant > > updates normally seen when using the git repositories. > > > > Robbie > > > > On 30 January 2017 at 13:19, Robbie Gemmell > > wrote: > >> Saying that made me look, and it seems like the GitHub integration is > >> indeed not enabled on the apache/qpid-java mirror. There are a few old > >> open Pull Requests and one test PR open+closed (nice account Lorenz > >> :P), none of which have been visible on the list. I raised > >> https://issues.apache.org/jira/browse/INFRA-13422 to get the GitHub > >> mails/JIRA comments integration enabled for the repo. > >> > >> Robbie > >> > >> On 30 January 2017 at 12:28, Robbie Gemmell > >> wrote: > >>> JIRA+PR or JIRA+patch, either approach is fine and works out largely > >>> the same for us in the end (almost identical if you really want, since > >>> you can get a patch by adding .patch to github pr/diff/commit URLs). > >>> > >>> Assuming the 'GitHub integration' stuff is enabled (and if it isn't, > >>> that would be an oversight) on the particular GitHub mirror in > >>> question, raising a PR generates a mail to the dev@ mailing list, and > >>> if the JIRA key is in the PR title (e.g "QPID-1234:short description") > >>> then a comment will also be placed on the JIRA for the open/close and > >>> any PR comments. The JIRA key should also be included in the commit so > >>> that once merged the JIRA is updated with details of the actual commit > >>> (see existing commits/JIRAs). We cant click the typical 'merge pr' > >>> button on GitHub at this time, as the mirrors are read only, but we > >>> can add the mirrors as remotes for our existing checkouts and > >>> merge+push PR commits to the source repo which then get mirrored > >>> similarly. PRs are marked merged automatically if their commit history > >>> became the unmodified head at the time of merge, but more safely can > >>> be closed out by a commit (either the specific o
Re: Patch + jira vs pull request
A few days back, I had emailed Travis support and asked them why the builds were taking too long to start. This is what they said - "I've been taking a look at the logs and it appears that at the time when your build #199359621 was triggered, the Apache organization was running at capacity, and this delayed the start time of the jobs. At the moment, I see that the organization is running at capacity too and it has some backlog of pending jobs waiting to start. To help with this high activity peak, I've boosted Apache's capacity from 30 to 50 concurrent jobs for the next 4 hours." So, when you submitted the pull request, it simply looks like Travis was running at full capacity for Apache. It should come thru as soon as the backlog is cleared. Thanks. - Original Message - > From: "Adel Boutros" > To: users@qpid.apache.org > Sent: Tuesday, February 28, 2017 9:10:26 AM > Subject: Re: Patch + jira vs pull request > > Hello, > > > I was testing this morning the pull request mechanism. I was able to perform > the pull request however it seems Travis has not built it yet. > > Is there a way to know what's blocking it? > (https://travis-ci.org/apache/qpid-dispatch/builds/206144819) > > > Regards, > > Adel > > > From: Robbie Gemmell > Sent: Monday, February 6, 2017 4:08:13 PM > To: users@qpid.apache.org > Subject: Re: Patch + jira vs pull request > > As an aside, for anyone else wanting to do this type of thing, I used > this to add a remote called 'github' to my existing checkout and make > the PRs available at ref github/pr/: > > git remote add github https://github.com/apache/qpid-java.git > git config --local --add remote.github.fetch > '+refs/pull/*/head:refs/remotes/github/pr/*' > git fetch --all > > To use a different name for the remote, find/replace instances of > github other than in the mirror URL with your chosen remote name. To > use another repo, change the name in the URL. > > Robbie > > On 31 January 2017 at 12:26, Robbie Gemmell wrote: > > This is now enabled, see > > https://issues.apache.org/jira/browse/QPID-7650 and > > https://github.com/apache/qpid-java/pull/5 as example. > > > > Note that the mails to the dev@ list were still not seen, as something > > seems to be wrong with the list, or at least JIRA. No mails from JIRA > > are arriving, even though I have been receiving the matching/duplicate > > mails sent directly to me. Raised as > > https://issues.apache.org/jira/browse/INFRA-13432 after chatting to > > infra, likely related to the very recent JIRA upgrade. I'll give the > > PR thing another check once its clearer what the issues are. > > > > Also, while the process of closing the PR worked fine, it did take a > > good 20+mins for the commit to make it to the github mirror (via the > > asf git mirror, via svn) and close it, as opposed to the near instant > > updates normally seen when using the git repositories. > > > > Robbie > > > > On 30 January 2017 at 13:19, Robbie Gemmell > > wrote: > >> Saying that made me look, and it seems like the GitHub integration is > >> indeed not enabled on the apache/qpid-java mirror. There are a few old > >> open Pull Requests and one test PR open+closed (nice account Lorenz > >> :P), none of which have been visible on the list. I raised > >> https://issues.apache.org/jira/browse/INFRA-13422 to get the GitHub > >> mails/JIRA comments integration enabled for the repo. > >> > >> Robbie > >> > >> On 30 January 2017 at 12:28, Robbie Gemmell > >> wrote: > >>> JIRA+PR or JIRA+patch, either approach is fine and works out largely > >>> the same for us in the end (almost identical if you really want, since > >>> you can get a patch by adding .patch to github pr/diff/commit URLs). > >>> > >>> Assuming the 'GitHub integration' stuff is enabled (and if it isn't, > >>> that would be an oversight) on the particular GitHub mirror in > >>> question, raising a PR generates a mail to the dev@ mailing list, and > >>> if the JIRA key is in the PR title (e.g "QPID-1234:short description") > >>> then a comment will also be placed on the JIRA for the open/close and > >>> any PR comments. The JIRA key should also be included in the commit so > >>> that once merged the JIRA is updated with details of the actual commit > >>> (see existing commits/JIRAs). We cant click the typical 'merge pr' > >>> button on GitHub at this time, as the mirrors are read only, but we > >>> can add the mirrors as remotes for our existing checkouts and > >>> merge+push PR commits to the source repo which then get mirrored > >>> similarly. PRs are marked merged automatically if their commit history > >>> became the unmodified head at the time of merge, but more safely can > >>> be closed out by a commit (either the specific one with the changes, > >>> or a merge commit introducing the original, or just an empty commit) > >>> containing a "This closes #" message somewhere in their log. The > >>> PR process for the ASF's GitHub mir
Re: Patch + jira vs pull request
Hello, I was testing this morning the pull request mechanism. I was able to perform the pull request however it seems Travis has not built it yet. Is there a way to know what's blocking it? (https://travis-ci.org/apache/qpid-dispatch/builds/206144819) Regards, Adel From: Robbie Gemmell Sent: Monday, February 6, 2017 4:08:13 PM To: users@qpid.apache.org Subject: Re: Patch + jira vs pull request As an aside, for anyone else wanting to do this type of thing, I used this to add a remote called 'github' to my existing checkout and make the PRs available at ref github/pr/: git remote add github https://github.com/apache/qpid-java.git git config --local --add remote.github.fetch '+refs/pull/*/head:refs/remotes/github/pr/*' git fetch --all To use a different name for the remote, find/replace instances of github other than in the mirror URL with your chosen remote name. To use another repo, change the name in the URL. Robbie On 31 January 2017 at 12:26, Robbie Gemmell wrote: > This is now enabled, see > https://issues.apache.org/jira/browse/QPID-7650 and > https://github.com/apache/qpid-java/pull/5 as example. > > Note that the mails to the dev@ list were still not seen, as something > seems to be wrong with the list, or at least JIRA. No mails from JIRA > are arriving, even though I have been receiving the matching/duplicate > mails sent directly to me. Raised as > https://issues.apache.org/jira/browse/INFRA-13432 after chatting to > infra, likely related to the very recent JIRA upgrade. I'll give the > PR thing another check once its clearer what the issues are. > > Also, while the process of closing the PR worked fine, it did take a > good 20+mins for the commit to make it to the github mirror (via the > asf git mirror, via svn) and close it, as opposed to the near instant > updates normally seen when using the git repositories. > > Robbie > > On 30 January 2017 at 13:19, Robbie Gemmell wrote: >> Saying that made me look, and it seems like the GitHub integration is >> indeed not enabled on the apache/qpid-java mirror. There are a few old >> open Pull Requests and one test PR open+closed (nice account Lorenz >> :P), none of which have been visible on the list. I raised >> https://issues.apache.org/jira/browse/INFRA-13422 to get the GitHub >> mails/JIRA comments integration enabled for the repo. >> >> Robbie >> >> On 30 January 2017 at 12:28, Robbie Gemmell wrote: >>> JIRA+PR or JIRA+patch, either approach is fine and works out largely >>> the same for us in the end (almost identical if you really want, since >>> you can get a patch by adding .patch to github pr/diff/commit URLs). >>> >>> Assuming the 'GitHub integration' stuff is enabled (and if it isn't, >>> that would be an oversight) on the particular GitHub mirror in >>> question, raising a PR generates a mail to the dev@ mailing list, and >>> if the JIRA key is in the PR title (e.g "QPID-1234:short description") >>> then a comment will also be placed on the JIRA for the open/close and >>> any PR comments. The JIRA key should also be included in the commit so >>> that once merged the JIRA is updated with details of the actual commit >>> (see existing commits/JIRAs). We cant click the typical 'merge pr' >>> button on GitHub at this time, as the mirrors are read only, but we >>> can add the mirrors as remotes for our existing checkouts and >>> merge+push PR commits to the source repo which then get mirrored >>> similarly. PRs are marked merged automatically if their commit history >>> became the unmodified head at the time of merge, but more safely can >>> be closed out by a commit (either the specific one with the changes, >>> or a merge commit introducing the original, or just an empty commit) >>> containing a "This closes #" message somewhere in their log. The >>> PR process for the ASF's GitHub mirrors works essentially the same for >>> the svn based repos as it does for the Git based repos (asuming you >>> are actually using git-svn, which I believe many/most folks are?). >>> >>> Robbie >>> >>> On 30 January 2017 at 11:51, Lorenz Quack wrote: I think it is different for different components of Qpid. The Qpid broker for Java for example has not migrated its main repository to git. Also the GitHub mirror is treated as read-only. And it is quite possible that pull request might go unnoticed. So, for the Qpid broker for Java component I would recommend for the time being to use JIRA/patches/email. Kind regards, Lorenz On 30/01/17 10:56, Chris Richardson wrote: > > I have been wondering about this too and would definitely give a +1 to the > pull request approach if it's an option. > > /C > > > On 28 January 2017 at 08:51, Adel Boutros wrote: > >> Hello, >> >> For some time we have been submitting jira issues with patches for >> problems we have detected. However, it is also possible
Re: [Qpid Dispatch - 0.7.0] Random failure on unit test "system_tests_link_routes" on Linux
I increased the timeout from 5 to 100 and the test which now takes 110 seconds instead of 10 seconds is still failing. After re-checking, the error message is actually the same on each failure. I think there is an issue here. My patch: diff --git a/tests/system_tests_drain_support.py b/tests/system_tests_drain_support.py index e4bd2bc..9a4a86f 100644 --- a/tests/system_tests_drain_support.py +++ b/tests/system_tests_drain_support.py @@ -46,7 +46,7 @@ class DrainMessagesHandler(MessagingHandler): self.conn.close() def on_start(self, event): -self.timer = event.reactor.schedule(5, Timeout(self)) +self.timer = event.reactor.schedule(100, Timeout(self)) self.conn = event.container.connect(self.address) # Create a sender and a receiver. They are both listening on the same address == Error === 13: FAIL: test_www_drain_support_all_messages (system_tests_link_routes.LinkRouteTest) 13: -- 13: Traceback (most recent call last): 13: File "/qpid-dispatch-0.7.0/tests/system_tests_link_routes.py", line 489, in test_www_drain_support_all_messages 13: self.assertEqual(None, drain_support.error) 13: AssertionError: None != 'Timeout Expired: sent: 10 rcvd: 8' 13: 13: -- 13: Ran 15 tests in 109.933s 13: 13: FAILED (failures=1) 1/1 Test #13: system_tests_link_routes .***Failed 110.16 sec Regards, Adel From: Adel Boutros Sent: Tuesday, February 28, 2017 2:47:16 PM To: users@qpid.apache.org Subject: [Qpid Dispatch - 0.7.0] Random failure on unit test "system_tests_link_routes" on Linux Hello, I noticed a random issue with the Dispatch Router 0.7.0 which has a random failure in the test "system_tests_link_routes". I launch the same test 10 times, it fails randomly (Failure occurs at the 4th or 5th run) but always with a similar error. It seems the timeout of 5 milliseconds is not enough especially on slow machines. I had submitted a patch for a similar task (https://issues.apache.org/jira/browse/DISPATCH-627) Can you please confirm? Regards, Adel 13: == 13: FAIL: test_www_drain_support_all_messages (system_tests_link_routes.LinkRouteTest) 13: -- 13: Traceback (most recent call last): 13: File "/qpid-dispatch-0.7.0/tests/system_tests_link_routes.py", line 489, in test_www_drain_support_all_messages 13: self.assertEqual(None, drain_support.error) 13: AssertionError: None != 'Timeout Expired: sent: 10 rcvd: 8'
[Qpid Dispatch - 0.7.0] Random failure on unit test "system_tests_link_routes" on Linux
Hello, I noticed a random issue with the Dispatch Router 0.7.0 which has a random failure in the test "system_tests_link_routes". I launch the same test 10 times, it fails randomly (Failure occurs at the 4th or 5th run) but always with a similar error. It seems the timeout of 5 milliseconds is not enough especially on slow machines. I had submitted a patch for a similar task (https://issues.apache.org/jira/browse/DISPATCH-627) Can you please confirm? Regards, Adel 13: == 13: FAIL: test_www_drain_support_all_messages (system_tests_link_routes.LinkRouteTest) 13: -- 13: Traceback (most recent call last): 13: File "/qpid-dispatch-0.7.0/tests/system_tests_link_routes.py", line 489, in test_www_drain_support_all_messages 13: self.assertEqual(None, drain_support.error) 13: AssertionError: None != 'Timeout Expired: sent: 10 rcvd: 8'
Performance degradation with Qpid JMS Client 0.20.0
Hi all, After upgrading Qpid JMS Client from version 0.11.0 to version 0.20.0 our performance test results dropped approximately on 20-25% in the performance tests testing transaction performance with trunk version of Qpid Java Broker. Changing client back to v0.11.0 and re-running the tests yields me the same results as before the upgrade. What changes on the client could be the reason for a performance drop? The performance test creates 10 publishing connections and 10 consuming connections. They produce/consume every message in separate transactions. The consumer is synchronous. Each pair of producer and consumer uses its own queue. Kind Regards, Alex - To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org For additional commands, e-mail: users-h...@qpid.apache.org
Re: [Qpid Dispatch] Manage Dispatch router from Qpid Jms
Great, thanks Ganesh.
Robbie
On 27 February 2017 at 22:19, Ganesh Murthy wrote:
> Hi Robbie,
>
> - Original Message -
>> From: "Robbie Gemmell"
>> To: users@qpid.apache.org
>> Sent: Friday, February 24, 2017 11:43:05 AM
>> Subject: Re: [Qpid Dispatch] Manage Dispatch router from Qpid Jms
>>
>> I tried this (modified to use a temporary queue) and also modified the
>> Qpid JMS HelloWorld example to use a temporary queue, and ran both
>> against the router successfully multiple times, using the jms client
>> from master, dispatch from master, and proton from master.
>>
>> The only odd thing was that Dispatch printed out two copies of notices
>> about the connection closing without the links being explicitly
>> detached, which is what the examples do and not something I would
>> consider unusual. I wouldnt really expect to see these notices, but if
>> so then only one copy.
>>
>> Fri Feb 24 16:33:21 2017 CONTAINER (notice) Aborting link
>> 'qpid-jms:sender:ID:c7e7de5c-462b-4b0e-8ad5-2a005008c648:1:1:1:$management'
>> due to parent connection end
>> Fri Feb 24 16:33:21 2017 CONTAINER (notice) Aborting link
>> 'qpid-jms:temp-queue-creator:ID:c7e7de5c-462b-4b0e-8ad5-2a005008c648:1:1'
>> due to parent connection end
>> Fri Feb 24 16:33:21 2017 CONTAINER (notice) Aborting link
>> 'qpid-jms:receiver:ID:c7e7de5c-462b-4b0e-8ad5-2a005008c648:1:1:1:amqp:/_$temp.Cjf7UnrnQX4Ow9Z'
>> due to parent connection end
>> Fri Feb 24 16:33:21 2017 CONTAINER (notice) Aborting link
>> 'qpid-jms:sender:ID:c7e7de5c-462b-4b0e-8ad5-2a005008c648:1:1:1:$management'
>> due to parent connection end
>> Fri Feb 24 16:33:21 2017 CONTAINER (notice) Aborting link
>> 'qpid-jms:temp-queue-creator:ID:c7e7de5c-462b-4b0e-8ad5-2a005008c648:1:1'
>> due to parent connection end
>> Fri Feb 24 16:33:21 2017 CONTAINER (notice) Aborting link
>> 'qpid-jms:receiver:ID:c7e7de5c-462b-4b0e-8ad5-2a005008c648:1:1:1:amqp:/_$temp.Cjf7UnrnQX4Ow9Z'
>> due to parent connection end
>>
>
> These log messages should not appear in the case of running the Qpid JMS
> Hello World examples. These are supposed to appear only
> when a socket close is received. I have entered a JIRA for this -
> https://issues.apache.org/jira/browse/DISPATCH-643
>
> I have fixed this issue on master branch.
>
> Thanks much.
>
>> As an aside, the typical TemporaryQueue usage would be just to use the
>> destination object directly, i.e the below, not ask its name and
>> create another destination with that name. I tried both ways just to
>> check it wasnt related though and they both worked the same.
>> TemporaryQueue temporaryQueue = managementSession.createTemporaryQueue();
>> managementConsumer = managementSession.createConsumer(temporaryQueue);
>>
>>
>> On 22 February 2017 at 11:33, Adel Boutros wrote:
>> > Hello guys,
>> >
>> >
>> > My basic JMS API is almost ready. I will share it with you soon to have
>> > your feedback.
>> >
>> >
>> > However, I tried one last thing by getting a random queue name and using it
>> > as management reply queue to allow multiple configuration sessions
>> > simultaneously but it didn't work.
>> >
>> >
>> > //This doesn't work and crashes the dispatch router
>> >
>> > TemporaryQueue temporaryQueue = managementSession.createTemporaryQueue();
>> > replyToQueue =
>> > managementSession.createQueue(temporaryQueue.getQueueName());
>> > managementConsumer = managementSession.createConsumer(replyToQueue);
>> >
>> > //This is the only thing working
>> > replyToQueue = managementSession.createQueue("HARD_CODED_REPLY_QUEUE");
>> > managementConsumer = managementSession.createConsumer(replyToQueue);
>> >
>> >
>> > Can I have your input on the above?
>> >
>> > Regards,
>> > Adel
>> >
>> >
>> >
>> > From: Rob Godfrey
>> > Sent: Wednesday, February 15, 2017 4:46:59 PM
>> > To: users@qpid.apache.org
>> > Subject: Re: [Qpid Dispatch] Manage Dispatch router from Qpid Jms
>> >
>> > On 15 February 2017 at 16:07, Robbie Gemmell
>> > wrote:
>> >
>> >> On 15 February 2017 at 14:15, Adel Boutros wrote:
>> >> > Hello guys,
>> >> >
>> >> >
>> >> > Based on the discussion, we are currently writing a Java API based on
>> >> JMS to configure the dispatch router. I have so far managed to do the
>> >> following:
>> >> >
>> >> > * Create, Read, Delete addresses
>> >> >
>> >> > * Create, Read, Delete connectors
>> >> >
>> >> >
>> >> > Config:
>> >> >
>> >> > Dispatch Router 0.7.0
>> >> >
>> >> > JMS 0.11.1
>> >> >
>> >> >
>> >> > And I have noticed some problems and differences:
>> >> >
>> >> >
>> >> > 1) It seems some calls return ObjectMessage and some TextMessage (This
>> >> is on the side of the consumer in the replyTo)
>> >> >
>> >> > For example, creating twice the same queue will fail but the second call
>> >> will return a JmsTextMessage with an empty body and status code 400
>> >> >
>> >>
>> >> The client treats messages with an amqp-value sectioning containing
>> >> null/nothing as a TextMessage with null value if they arent annotated
