Ahh, there it is
Caused by: java.net.BindException: Address already in use
On Sun, Jan 31, 2016 at 6:47 PM, Rob Godfrey wrote:
> Nope - "no uncaught exception handler set" means exactly what it says :-)
> There's a JIRA for this https://issues.apache.org/jira/browse/QPID-6950 which
> is fixed on
Nope - "no uncaught exception handler set" means exactly what it says :-)
There's a JIRA for this https://issues.apache.org/jira/browse/QPID-6950 which
is fixed on trunk and the 6.0.x branch.
If you set the default uncaught exception handler (
https://docs.oracle.com/javase/7/docs/api/java/lang/Th
Thanks Rob! Appreciate the help
Unfortunately, after setting the property, it didn't make any
difference. Still trying to start on 8080.
Any clues? Is there a way to disable the management website?
This the last excepting printed to stdout. I'm pretty sure that "no
uncaught exception handler set
You're not starting in management mode (and you probably don't want to :-)
), so setting the management port overrides is not really what you want.
Making the Broker easier to embed and start programmatically for unit
tests, etc... is on my personal roadmap (I even have some work somewhere on
my l
I sent out the email more than 3 days ago, but it's still not appearing in
the mailing list. Has it been deleted from the archive?
On Thu, Jan 28, 2016 at 1:02 PM, jjw tectec wrote:
> I've set up a simple 4-broker system, where between Bs (source broker) and
> Bd (destination broker) are two mid
I've made some progress using 6.0.0.
org.apache.qpid.server.Broker broker = new Broker();
BrokerOptions options = new BrokerOptions();
options.setManagementModeHttpPortOverride(9090);
options.setManagementModeJmxPortOverride(9099);
options.setManagementMode(
I'm working on a project that needs to fire up a qpid java broker,
send some messages, wait for replies, then shutdown, in the context of
a java unit test in maven. I saw that this used to be possible on SO
at one point. Anyhow, is there any examples on how to do this? Perhaps
I could reuse one of
Hi, Keith. Thanks for finding that failure. I've committed a fix.
http://svn.apache.org/viewvc/qpid/site/python/generate.py?r1=1727820&r2=1727819&pathrev=1727820
On the other question, I think that may be fair behavior for the gen-*
scripts.
In this specific instance, it's the removes in gen_
Hi Justin,
I gave the change a test drive. It looks like a useful improvement.
I did notice a couple of problems when trying to render trunk, which I
don't think are related to the change.
1) Running "make clean gen-cpp-release RELEASE=trunk" dies with the
following message.
gen-cpp-release-ap
