You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@activemq.apache.org by ktrue <kt...@inxight.com> on 2006/11/21 22:11:49 UTC
Newbie configuration questions
Hi all,
First off: to the developers of ActiveMQ - thanks for all the hard work!
It's a great product!
One of the strengths of ActiveMQ is the array of options for configuration,
the flexibility of topology, and so forth. Unfortunately, with all these
options from which to choose I'm not sure that I'm configuring my system in
the correct -- let alone optimal -- fashion.
My system uses a very generic client/server topology. I have a web
application that acts as a server to N clients that send messages to that
server.
I've configured (via Spring 1.2.x) the server to contain an embedded broker
thusly:
<bean id="jmsBroker"
class="org.apache.activemq.broker.BrokerService"
init-method="start"
destroy-method="stop">
<property name="brokerName" value="adminserver"/>
<property name="persistenceAdapter"><ref
local="persistenceAdapter"/></property>
<property name="useJmx" value="false"/>
<property name="useShutdownHook" value="false"/>
<property name="transportConnectorURIs">
<list>
<value>tcp://localhost:61616</value>
</list>
</property>
</bean>
<bean id="jencks" class="org.jencks.JCAContainer"
depends-on="jmsBroker">
<property name="bootstrapContext">
<bean class="org.jencks.factory.BootstrapContextFactoryBean">
<property name="threadPoolSize"><value>25</value></property>
</bean>
</property>
<property name="resourceAdapter">
<bean id="activeMQResourceAdapter"
class="org.apache.activemq.ra.ActiveMQResourceAdapter">
<property name="serverUrl" value="vm://adminserver"/>
</bean>
</property>
</bean>
Client:
<bean id="jmsConnectionFactory"
class="org.apache.activemq.pool.PooledConnectionFactory"
init-method="start"
destroy-method="stop">
<property name="connectionFactory">
<bean class="org.apache.activemq.ActiveMQConnectionFactory">
<property name="brokerURL"
value="failover:(tcp://${adminserver}:61616)"/>
</bean>
</property>
</bean>
Here are my questions:
1. Is this "correct"? It seems to work as expected, but I'm not sure if
this is the correct way to do it. Specifically,
does this scheme allow for failover when the server goes offline but
eventually comes back up? Is there a
need to use a 'network of brokers' for some reason and embed brokers
in the client?
2. In the above configuration, I have successfully noted that I can
start the clients BUT NOT THE SERVER
and the JMS layer appears to queue up the messages such that when
the server does start, all of the
messages are then sent to and received on the server. This is
fantastic, but, how does that work? I'd like to
know if this is a design feature, how it works, if there are any
parameters, what the limitations are, etc.
3. The previous developers on the project used a network of brokers
topology and had a broker in
each of the clients as well. However, when the client's JMS
connection factory used a failover:(vm://client)
transport for the brokerURL, it never actually worked. When the
server went offline and came back online
it would never reconnect. Given my current understanding (admittedly
shallow), I don't see the need/benefit
of embedding brokers in the client except that (in relation to
question 2), there are configuration options for
persistence of messages. Is there something I'm missing.
Forgive me if I missed a critical point of explanation or am asking silly
questions. I've done a good amount of research but am still lacking a basic
understanding of some of these points.
Thanks!
Kirk
--
View this message in context: http://www.nabble.com/Newbie-configuration-questions-tf2681720.html#a7479997
Sent from the ActiveMQ - User mailing list archive at Nabble.com.
Re: Newbie configuration questions
Posted by Adrian Co <ac...@exist.com>.
Also, network connectors at the moment are uni-directional, which means
that if brokerA has a network connector that connects to brokerB,
brokerA can send messages to brokerB, but brokerB cannot send messages
to brokerA. See https://issues.apache.org/activemq/browse/AMQ-920. In
your config below, the embedded brokers can send messages to the remote
broker, but the remote broker cannot send messages to the embedded brokers.
Adrian Co wrote:
> ktrue wrote:
>> Hi guys,
>>
>>
>> Adrian Co wrote:
>>
>>>>> For me, one of the key use of embedding brokers in the client, is
>>>>> that clients can continue processing stuff even when the remote
>>>>> broker is down. AFAIK, using the failover protocol, will block the
>>>>> sending of a message until the client is able reconnect to the
>>>>> broker. If you use an embedded broker, messages will be persisted
>>>>> automatically, and be sent when the remote broker comes online
>>>>> again, and the actual producer need not worry about it. I don't
>>>>> think theres not much use for a failover:vm://client as using an
>>>>> embedded broker assumes that if a broker goes down, the client in
>>>>> essence is also down.
>>>>>
>>
>> Adrian, I wanted to share with you the previous "network of brokers"
>> configuration that was used in our product that didn't seem to implement
>> failover as expected.
>> Previously the server defined a broker thusly:
>>
>> <beans xmlns="http://activemq.org/config/1.0">
>> <broker brokerName="adminserver" useJmx="false"
>> useShutdownHook="false">
>> <transportConnectors>
>> <transportConnector name="default"
>> uri="tcp://localhost:61616"/>
>> </transportConnectors>
>> <networkConnectors>
>> <networkConnector name="default"
>> uri="static:tcp://localhost:61616"/>
>> </networkConnectors>
>> </broker>
>> </beans>
>>
> I find this part odd. You have a network connector to
> tcp://localhost:61616, and you're exposing the same transport
> connector. Seems that you're connecting to yourself? I'm not sure if
> this is the actual problem, its just odd.
>> The previous configuration of the clients included an embedded broker as
>> well:
>>
>> <bean id="jmsBroker"
>> class="org.apache.activemq.broker.BrokerService"
>> init-method="start"
>> destroy-method="stop">
>> <property name="brokerName" value="cruncheragent"/>
>> <property name="useJmx" value="false"/>
>> <property name="useShutdownHook" value="false"/>
>> <property name="networkConnectorURIs">
>> <list>
>> <value>static:(failover:(tcp://localhost:61616))</value>
>> </list>
>> </property>
>> </bean>
>> <bean id="jmsConnectionFactory"
>> class="org.apache.activemq.pool.PooledConnectionFactory"
>> init-method="start"
>> destroy-method="stop">
>> <property name="connectionFactory">
>> <bean class="org.apache.activemq.ActiveMQConnectionFactory">
>> <property name="brokerURL" value="vm://cruncheragent"/>
>> </bean>
>> </property>
>> </bean>
>> However, what happened when I stopped the server (broker
>> "adminserver"), I
>> get this message in the client:
>>
>> 2006-11-17 16:20:41,588 WARN
>> [org.apache.activemq.network.DemandForwardingBridge] - Unexpected
>> remote
>> command:
>> ShutdownInfo {commandId = 52, responseRequired = false}
>> 2006-11-17 16:20:41,590 WARN
>> [org.apache.activemq.network.DemandForwardingBridge] - Outbound
>> transport to
>> adminserver interrupted ...
>>
>> However, once I start the server, I never see any further messages
>> about the
>> matter and the clients don't appear to reconnect (i.e. I never see
>> messages
>> on the server from the clients again). HOWEVER, if I don't use an
>> embedded
>> broker on the client and use failover:tcp://localhost:61616, the
>> messages
>> are sent to the server when it is once again available.
>>
>> In short, it seems like sticking an embedded broker in between the
>> ConnectionFactory and the server seems to break failover.
>>
>> Additionally, you asked:
>>
>> Could be if you are connecting to other JMS brokers aside from
>> AMQ, but
>> if you are networking
>> ActiveMQ brokers only, I don't think so.
>>
>> Just to rule that out, no, I'm only connecting to ActiveMQ servers.
>>
>> Adrian and Gabriel: thanks for your input and help so far.
>>
>> Thanks!
>> Kirk
>>
>
Re: Newbie configuration questions
Posted by Adrian Co <ac...@exist.com>.
ktrue wrote:
> Hi guys,
>
>
> Adrian Co wrote:
>
>>>> For me, one of the key use of embedding brokers in the client, is
>>>> that clients can continue processing stuff even when the remote
>>>> broker is down. AFAIK, using the failover protocol, will block the
>>>> sending of a message until the client is able reconnect to the
>>>> broker. If you use an embedded broker, messages will be persisted
>>>> automatically, and be sent when the remote broker comes online again,
>>>> and the actual producer need not worry about it. I don't think theres
>>>> not much use for a failover:vm://client as using an embedded broker
>>>> assumes that if a broker goes down, the client in essence is also down.
>>>>
>
> Adrian, I wanted to share with you the previous "network of brokers"
> configuration that was used in our product that didn't seem to implement
> failover as expected.
>
> Previously the server defined a broker thusly:
>
> <beans xmlns="http://activemq.org/config/1.0">
> <broker brokerName="adminserver" useJmx="false"
> useShutdownHook="false">
> <transportConnectors>
> <transportConnector name="default"
> uri="tcp://localhost:61616"/>
> </transportConnectors>
> <networkConnectors>
> <networkConnector name="default"
> uri="static:tcp://localhost:61616"/>
> </networkConnectors>
> </broker>
> </beans>
>
I find this part odd. You have a network connector to
tcp://localhost:61616, and you're exposing the same transport connector.
Seems that you're connecting to yourself? I'm not sure if this is the
actual problem, its just odd.
> The previous configuration of the clients included an embedded broker as
> well:
>
> <bean id="jmsBroker"
> class="org.apache.activemq.broker.BrokerService"
> init-method="start"
> destroy-method="stop">
> <property name="brokerName" value="cruncheragent"/>
> <property name="useJmx" value="false"/>
> <property name="useShutdownHook" value="false"/>
> <property name="networkConnectorURIs">
> <list>
> <value>static:(failover:(tcp://localhost:61616))</value>
> </list>
> </property>
> </bean>
>
> <bean id="jmsConnectionFactory"
> class="org.apache.activemq.pool.PooledConnectionFactory"
> init-method="start"
> destroy-method="stop">
> <property name="connectionFactory">
> <bean class="org.apache.activemq.ActiveMQConnectionFactory">
> <property name="brokerURL" value="vm://cruncheragent"/>
> </bean>
> </property>
> </bean>
>
> However, what happened when I stopped the server (broker "adminserver"), I
> get this message in the client:
>
> 2006-11-17 16:20:41,588 WARN
> [org.apache.activemq.network.DemandForwardingBridge] - Unexpected
> remote command:
> ShutdownInfo {commandId = 52, responseRequired = false}
> 2006-11-17 16:20:41,590 WARN
> [org.apache.activemq.network.DemandForwardingBridge] - Outbound
> transport to
> adminserver interrupted ...
>
> However, once I start the server, I never see any further messages about the
> matter and the clients don't appear to reconnect (i.e. I never see messages
> on the server from the clients again). HOWEVER, if I don't use an embedded
> broker on the client and use failover:tcp://localhost:61616, the messages
> are sent to the server when it is once again available.
>
> In short, it seems like sticking an embedded broker in between the
> ConnectionFactory and the server seems to break failover.
>
> Additionally, you asked:
>
> Could be if you are connecting to other JMS brokers aside from AMQ, but
> if you are networking
> ActiveMQ brokers only, I don't think so.
>
> Just to rule that out, no, I'm only connecting to ActiveMQ servers.
>
> Adrian and Gabriel: thanks for your input and help so far.
>
> Thanks!
> Kirk
>
Re: Newbie configuration questions
Posted by ktrue <kt...@inxight.com>.
Hi guys,
Adrian Co wrote:
>
>>> For me, one of the key use of embedding brokers in the client, is
>>> that clients can continue processing stuff even when the remote
>>> broker is down. AFAIK, using the failover protocol, will block the
>>> sending of a message until the client is able reconnect to the
>>> broker. If you use an embedded broker, messages will be persisted
>>> automatically, and be sent when the remote broker comes online again,
>>> and the actual producer need not worry about it. I don't think theres
>>> not much use for a failover:vm://client as using an embedded broker
>>> assumes that if a broker goes down, the client in essence is also down.
>
Adrian, I wanted to share with you the previous "network of brokers"
configuration that was used in our product that didn't seem to implement
failover as expected.
Previously the server defined a broker thusly:
<beans xmlns="http://activemq.org/config/1.0">
<broker brokerName="adminserver" useJmx="false"
useShutdownHook="false">
<transportConnectors>
<transportConnector name="default"
uri="tcp://localhost:61616"/>
</transportConnectors>
<networkConnectors>
<networkConnector name="default"
uri="static:tcp://localhost:61616"/>
</networkConnectors>
</broker>
</beans>
The previous configuration of the clients included an embedded broker as
well:
<bean id="jmsBroker"
class="org.apache.activemq.broker.BrokerService"
init-method="start"
destroy-method="stop">
<property name="brokerName" value="cruncheragent"/>
<property name="useJmx" value="false"/>
<property name="useShutdownHook" value="false"/>
<property name="networkConnectorURIs">
<list>
<value>static:(failover:(tcp://localhost:61616))</value>
</list>
</property>
</bean>
<bean id="jmsConnectionFactory"
class="org.apache.activemq.pool.PooledConnectionFactory"
init-method="start"
destroy-method="stop">
<property name="connectionFactory">
<bean class="org.apache.activemq.ActiveMQConnectionFactory">
<property name="brokerURL" value="vm://cruncheragent"/>
</bean>
</property>
</bean>
However, what happened when I stopped the server (broker "adminserver"), I
get this message in the client:
2006-11-17 16:20:41,588 WARN
[org.apache.activemq.network.DemandForwardingBridge] - Unexpected
remote command:
ShutdownInfo {commandId = 52, responseRequired = false}
2006-11-17 16:20:41,590 WARN
[org.apache.activemq.network.DemandForwardingBridge] - Outbound
transport to
adminserver interrupted ...
However, once I start the server, I never see any further messages about the
matter and the clients don't appear to reconnect (i.e. I never see messages
on the server from the clients again). HOWEVER, if I don't use an embedded
broker on the client and use failover:tcp://localhost:61616, the messages
are sent to the server when it is once again available.
In short, it seems like sticking an embedded broker in between the
ConnectionFactory and the server seems to break failover.
Additionally, you asked:
Could be if you are connecting to other JMS brokers aside from AMQ, but
if you are networking
ActiveMQ brokers only, I don't think so.
Just to rule that out, no, I'm only connecting to ActiveMQ servers.
Adrian and Gabriel: thanks for your input and help so far.
Thanks!
Kirk
--
View this message in context: http://www.nabble.com/Newbie-configuration-questions-tf2681720.html#a7519069
Sent from the ActiveMQ - User mailing list archive at Nabble.com.
Re: Newbie configuration questions
Posted by Adrian Co <ac...@exist.com>.
gabriel kastenbaum wrote:
> Hi,
>>
>> ktrue wrote:
>>> 3. The previous developers on the project used a network of brokers
>>> topology and had a broker in
>>> each of the clients as well. However, when the client's JMS
>>> connection factory used a failover:(vm://client)
>>> transport for the brokerURL, it never actually worked. When the
>>> server went offline and came back online
>>> it would never reconnect. Given my current understanding
>>> (admittedly
>>> shallow), I don't see the need/benefit
>>> of embedding brokers in the client except that (in relation to
>>> question 2), there are configuration options for
>>> persistence of messages. Is there something I'm missing.
>>> Adrian Co a écrit :
>> For me, one of the key use of embedding brokers in the client, is
>> that clients can continue processing stuff even when the remote
>> broker is down. AFAIK, using the failover protocol, will block the
>> sending of a message until the client is able reconnect to the
>> broker. If you use an embedded broker, messages will be persisted
>> automatically, and be sent when the remote broker comes online again,
>> and the actual producer need not worry about it. I don't think theres
>> not much use for a failover:vm://client as using an embedded broker
>> assumes that if a broker goes down, the client in essence is also down.
>>
>>
> I am also very interested by that type of solution.
> This is the architecture one we are testing now (ActiveMQ version: 4.0.2
> or 4.1). But as far I understood how things work, and within my small
> experience of repeatedly unsuccessfull tries, I never manage to see a
> disconnected broker reconnecting automatically to other ActiveMQ brokers
> in a network of brokers, and then sending messages.
>
> cf. also http://issues.apache.org/activemq/browse/AMQ-895. Related?
Could be if you are connecting to other JMS brokers aside from AMQ, but
if you are networking ActiveMQ brokers only, I don't think so.
>
> Is it true?
> If not, what is the configuration to use to have a network of brokers
> with automatic reconnection of brokers?
Just set the network connectors to failover="true" or
"failover://remotehost:61616". I haven't grokked if there is any diff
between the two, but I think they're just the same. :)
>
> Thanks by advance!
>
>
Re: Newbie configuration questions
Posted by gabriel kastenbaum <gk...@gmail.com>.
Hi,
>
> ktrue wrote:
>> 3. The previous developers on the project used a network of brokers
>> topology and had a broker in
>> each of the clients as well. However, when the client's JMS
>> connection factory used a failover:(vm://client)
>> transport for the brokerURL, it never actually worked. When the
>> server went offline and came back online
>> it would never reconnect. Given my current understanding
>> (admittedly
>> shallow), I don't see the need/benefit
>> of embedding brokers in the client except that (in relation to
>> question 2), there are configuration options for
>> persistence of messages. Is there something I'm missing.
>> Adrian Co a écrit :
> For me, one of the key use of embedding brokers in the client, is that
> clients can continue processing stuff even when the remote broker is
> down. AFAIK, using the failover protocol, will block the sending of a
> message until the client is able reconnect to the broker. If you use
> an embedded broker, messages will be persisted automatically, and be
> sent when the remote broker comes online again, and the actual
> producer need not worry about it. I don't think theres not much use
> for a failover:vm://client as using an embedded broker assumes that if
> a broker goes down, the client in essence is also down.
>
>
I am also very interested by that type of solution.
This is the architecture one we are testing now (ActiveMQ version: 4.0.2
or 4.1). But as far I understood how things work, and within my small
experience of repeatedly unsuccessfull tries, I never manage to see a
disconnected broker reconnecting automatically to other ActiveMQ brokers
in a network of brokers, and then sending messages.
cf. also http://issues.apache.org/activemq/browse/AMQ-895. Related?
Is it true?
If not, what is the configuration to use to have a network of brokers
with automatic reconnection of brokers?
Thanks by advance!
Re: Newbie configuration questions
Posted by gabriel kastenbaum <gk...@gmail.com>.
Hi,
>
> ktrue wrote:
>> 3. The previous developers on the project used a network of brokers
>> topology and had a broker in
>> each of the clients as well. However, when the client's JMS
>> connection factory used a failover:(vm://client)
>> transport for the brokerURL, it never actually worked. When the
>> server went offline and came back online
>> it would never reconnect. Given my current understanding
>> (admittedly
>> shallow), I don't see the need/benefit
>> of embedding brokers in the client except that (in relation to
>> question 2), there are configuration options for
>> persistence of messages. Is there something I'm missing.
>> Adrian Co a écrit :
> For me, one of the key use of embedding brokers in the client, is that
> clients can continue processing stuff even when the remote broker is
> down. AFAIK, using the failover protocol, will block the sending of a
> message until the client is able reconnect to the broker. If you use
> an embedded broker, messages will be persisted automatically, and be
> sent when the remote broker comes online again, and the actual
> producer need not worry about it. I don't think theres not much use
> for a failover:vm://client as using an embedded broker assumes that if
> a broker goes down, the client in essence is also down.
>
>
I am also very interested by that type of solution.
This is the architecture one we are testing now (ActiveMQ version: 4.0.2
or 4.1). But as far I understood how things work, and within my small
experience of repeatedly unsuccessfull tries, I never manage to see a
disconnected broker reconnecting automatically to other ActiveMQ brokers
in a network of brokers, and then sending messages.
cf. also http://issues.apache.org/activemq/browse/AMQ-895. Related?
Is it true?
If not, what is the configuration to use to have a network of brokers
with automatic reconnection of brokers?
Thanks by advance!
Re: Newbie configuration questions
Posted by Adrian Co <ac...@exist.com>.
Hi,
Here's my two cents. See inlined. :)
ktrue wrote:
> Hi all,
>
> First off: to the developers of ActiveMQ - thanks for all the hard work!
> It's a great product!
>
> One of the strengths of ActiveMQ is the array of options for configuration,
> the flexibility of topology, and so forth. Unfortunately, with all these
> options from which to choose I'm not sure that I'm configuring my system in
> the correct -- let alone optimal -- fashion.
>
> My system uses a very generic client/server topology. I have a web
> application that acts as a server to N clients that send messages to that
> server.
>
> I've configured (via Spring 1.2.x) the server to contain an embedded broker
> thusly:
>
> <bean id="jmsBroker"
> class="org.apache.activemq.broker.BrokerService"
> init-method="start"
> destroy-method="stop">
> <property name="brokerName" value="adminserver"/>
> <property name="persistenceAdapter"><ref
> local="persistenceAdapter"/></property>
> <property name="useJmx" value="false"/>
> <property name="useShutdownHook" value="false"/>
> <property name="transportConnectorURIs">
> <list>
> <value>tcp://localhost:61616</value>
> </list>
> </property>
> </bean>
>
> <bean id="jencks" class="org.jencks.JCAContainer"
> depends-on="jmsBroker">
> <property name="bootstrapContext">
> <bean class="org.jencks.factory.BootstrapContextFactoryBean">
> <property name="threadPoolSize"><value>25</value></property>
> </bean>
> </property>
> <property name="resourceAdapter">
> <bean id="activeMQResourceAdapter"
> class="org.apache.activemq.ra.ActiveMQResourceAdapter">
> <property name="serverUrl" value="vm://adminserver"/>
> </bean>
> </property>
> </bean>
>
> Client:
>
> <bean id="jmsConnectionFactory"
> class="org.apache.activemq.pool.PooledConnectionFactory"
> init-method="start"
> destroy-method="stop">
> <property name="connectionFactory">
> <bean class="org.apache.activemq.ActiveMQConnectionFactory">
> <property name="brokerURL"
> value="failover:(tcp://${adminserver}:61616)"/>
> </bean>
> </property>
> </bean>
>
> Here are my questions:
>
> 1. Is this "correct"? It seems to work as expected, but I'm not sure if
> this is the correct way to do it. Specifically,
> does this scheme allow for failover when the server goes offline but
> eventually comes back up? Is there a
> need to use a 'network of brokers' for some reason and embed brokers
> in the client?
>
yes, the clients will keep retrying to connect to the broker because of
the failover protocol.
> 2. In the above configuration, I have successfully noted that I can
> start the clients BUT NOT THE SERVER
> and the JMS layer appears to queue up the messages such that when
> the server does start, all of the
> messages are then sent to and received on the server. This is
> fantastic, but, how does that work? I'd like to
> know if this is a design feature, how it works, if there are any
> parameters, what the limitations are, etc.
>
Basically, using the failover protocol the clients will keep trying to
connect to the broker until it is successful. In the case of not
starting the broker yet, it is similar to the broker crashing, so
clients will keep trying until it is upped. Details and config here:
http://www.activemq.org/site/failover-transport-reference.html
> 3. The previous developers on the project used a network of brokers
> topology and had a broker in
> each of the clients as well. However, when the client's JMS
> connection factory used a failover:(vm://client)
> transport for the brokerURL, it never actually worked. When the
> server went offline and came back online
> it would never reconnect. Given my current understanding (admittedly
> shallow), I don't see the need/benefit
> of embedding brokers in the client except that (in relation to
> question 2), there are configuration options for
> persistence of messages. Is there something I'm missing.
>
For me, one of the key use of embedding brokers in the client, is that
clients can continue processing stuff even when the remote broker is
down. AFAIK, using the failover protocol, will block the sending of a
message until the client is able reconnect to the broker. If you use an
embedded broker, messages will be persisted automatically, and be sent
when the remote broker comes online again, and the actual producer need
not worry about it. I don't think theres not much use for a
failover:vm://client as using an embedded broker assumes that if a
broker goes down, the client in essence is also down.
> Forgive me if I missed a critical point of explanation or am asking silly
> questions. I've done a good amount of research but am still lacking a basic
> understanding of some of these points.
>
> Thanks!
>
> Kirk
>