That part of the config startup is a little convoluted :-)
When I get a free moment I really want to write a better API for starting
up embedded brokers that doesn't require any files to be written/read...
However it's 3am here now... so probably not tonight :-)
No idea what's causing your issues
Rob, you are a genius!
In the past I got it to work once and then never again and I couldn't
figure out why. the config file is updated after the first run. I'll
work some maven magic to have a master config, then copy it to the
working one before building. That should get me going. Thanks again
f
So, what about the virtual host configuration? After the first start
there'll be a /default/config/default.json file written... Are
you blowing this away each time? If you are then you'll need to change
your system.config so that it always populates the initial virtual host
configuration... e.g. c
here's the classpath
[INFO] +- javax.jms:jms:jar:1.1:compile
[INFO] +- org.apache.qpid:qpid-client:jar:6.0.0:compile
[INFO] | +- org.apache.qpid:qpid-common:jar:6.0.0:compile
[INFO] | \- org.slf4j:slf4j-api:jar:1.7.7:compile
[INFO] +- org.apache.qpid:qpid-broker:jar:6.0.0:test
[INFO] | +- ch.q
here's the config. looks ok to me. strange since it works ok with the
distro. i'm thinking its a classpath issue
{
"id" : "1b8cbf11-972d-48f5-a6d5-eb9ed2b2d781",
"name" : "${broker.name}",
"modelVersion" : "6.0",
"authenticationproviders" : [ {
"id" : "6d9f1d6d-d0df-4f2c-a068-d8ac413dc
Can you post the config here? "Unknown virtualhost" might indicate
improperly configured virtual host aliases... or it may be some other issue
Correctly configured virtualhostaliases would look something like this:
"ports" : [ {
"id" : "3b415494-4c58-4fe1-a972-fea7f84b0c74",
"name" : "A
+1 release 0.12.0 RC bits as 0.12.0 GA
tested on Centos7:
- unit test and install
- verified pyngus 2.0.3 unit tests and examples pass
- verified mainline oslo.messaging functional tests pass
- verified mainline rsyslog amqp1 plugin functions
- Original Message -
> From: "Justin Ros
Hi Gordon,
Now I know the behavioral change was due to whether the route config was
done at the source or destination.
My previous results were achieved using the following to configure B1 and
B2.
qpid-route -v -d queue add $broker $Bs $EX $QUEUE
qpid-route -s -v -d queue add $Bd $
qpid-route commands were all successful (no errors at all), and "route map"
is showing correct connections, like the below:
B1 - Static Routes:
B1:5673(queue=TestQueue) => Bd:5673(ex=TestExchange)
B1:5673(ex=TestExchange) <= Bs:5673(queue=TestQueue)
B2 - Static Routes:
B2:5673(queue=TestQue
On 02/03/2016 04:26 PM, jjw tectec wrote:
I followed your suggestion and ran "qpid-stat -q" "qpid-stat -e" on the 4
brokers. The below data match the observation: Only B1 was seeing all the
100 messages that were generated. Qpid-stat results were the same whether
"ack" option was used or not.
Thank you Gordon. I had played a little with dispatch routers some time
ago. I'll see how I can make use of it, along with the brokers, to achieve
the desired behavior.
I followed your suggestion and ran "qpid-stat -q" "qpid-stat -e" on the 4
brokers. The below data match the observation: Only B1
The artifacts proposed for release:
https://dist.apache.org/repos/dist/dev/qpid/proton/0.12.0-rc/
Please indicate your vote below. If you favor releasing the 0.12.0 RC bits
as 0.12.0 GA, vote +1. If you have reason to think the RC is not ready for
release, vote -1.
Thanks,
Justin
On Wed, Feb 3, 2016 at 5:47 AM, Justin Ross wrote:
> I will wait until Monday the 8th to start the vote, in case we discover
> any important problems and need to plan another RC.
>
Robbie suggested I may as well start the vote now. Incoming.
The release candidate is now available:
https://dist.apache.org/repos/dist/dev/qpid/proton/0.12.0-rc/
Maven staging repo:
https://repository.apache.org/content/repositories/orgapacheqpid-1061
Test output on Fedora 23 x86-64:
http://people.apache.org/~jross/qpid-releases/quirk-proto
Again, with the thread of an embedded qpid server in a unit test...
I can get the test case (connect to amqp and wait for a reply) to run
fine with qpid running from the distro. When running the server in the
unit test, I'm now running into the follow error.
Connecting to amqp://guest:guest@/defa
Last I was aware of things, the broker looked at the qpid.work_dir
config property (see mention in my original mail), then if that isn't
set populates it by looking at the QPID_WORK system property, then if
that isn't set falls back to a 'work' subdir in the users home dir.
The folks who have worke
16 matches
Mail list logo
