I should mention that the reason I was using this script was because there
were no activemq scripts in either of the linux directories. But since I
noticed this bug: https://issues.apache.org/activemq/browse/AMQ-1728
https://issues.apache.org/activemq/browse/AMQ-1728
I have just copied the scri
I should have added this to my boker config above:
Setting the connectionPort to 1099 allows stop to work, but prevents us from
having multiple brokers on the same machine.
--
View this message in context:
http://www.nabble.com/activemq-admin-error-during-stop-tp17218304s2354p172
Actually, I have overridden my port to use JMX on 1199. If I set the value
back to the default of 1099, stop works. Could this shutdown value be hard
coded?
Hiram Chirino wrote:
>
> could you run netstat -a and make sure that port 1099 is open. That's
> the JMX management port that the broker
I am encountering the same problem. Even if I use the default port of 61616,
I get the exact same exceptions. I am trying to upgrade from a snapshot 5.0
from January. We need the ability to shutdown ActiveMQ from a script.
Here is my configuration:
http://activemq.org/config/1.0";
d
I just checked our logs, and I am seeing the same message about the Master
not being able to connect to the slave. I will be removing the Network of
Brokers setting form our config. We are using queues, not topics.
Thanks for pointing out the Network of Brokers issue! I forgot to check the
logs
Yes, the /data is my shared directory. Persistence can be set up either way
according to the config examples I have seen.
I used the network of brokers to keep the slaves up to date when I was
originally having problems with the behavior of the slaves. I am not sure
if having this configured is
Shared File System Master Slave does work for us. I have attached a sample
of our config for one of the brokers below.
http://activemq.org/config/1.0";
deleteAllMessagesOnStartup="true" dataDirectory="/data" persistent="true">
i hope this help
After further investigation, it turns out there was a configuration issue,
which could have been avoided with clearer documentation. (it might have
helped if i had included my configuration as well!) We had set the value
for broker name differently in our two running instances of ActiveMQ. Doing
We are currently experiencing a problem where are consumers are not always
being released when we shutdown our consumers. This seems to happen less
than half the time, but does force us to restart at least one of the 2
ActiveMQ servers that we have in our Shared File System Master Slave
cluster.