Return-Path: 
 <activemq-users-return-5855-apmail-geronimo-activemq-users-archive=geronimo.apache.org@geronimo.apache.org>
Delivered-To: apmail-geronimo-activemq-users-archive@www.apache.org
Received: (qmail 99809 invoked from network); 21 Nov 2006 22:38:52 -0000
Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2)
  by minotaur.apache.org with SMTP; 21 Nov 2006 22:38:52 -0000
Received: (qmail 63221 invoked by uid 500); 21 Nov 2006 22:39:01 -0000
Delivered-To: apmail-geronimo-activemq-users-archive@geronimo.apache.org
Received: (qmail 63198 invoked by uid 500); 21 Nov 2006 22:39:01 -0000
Mailing-List: contact activemq-users-help@geronimo.apache.org; run by ezmlm
Precedence: bulk
List-Help: <mailto:activemq-users-help@geronimo.apache.org>
List-Unsubscribe: <mailto:activemq-users-unsubscribe@geronimo.apache.org>
List-Post: <mailto:activemq-users@geronimo.apache.org>
List-Id: <activemq-users.geronimo.apache.org>
Reply-To: activemq-users@geronimo.apache.org
Delivered-To: mailing list activemq-users@geronimo.apache.org
Received: (qmail 63185 invoked by uid 99); 21 Nov 2006 22:39:01 -0000
Received: from herse.apache.org (HELO herse.apache.org) (140.211.11.133)
    by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 21 Nov 2006 14:39:01 -0800
X-ASF-Spam-Status: No, hits=0.0 required=10.0
	tests=
X-Spam-Check-By: apache.org
Received-SPF: pass (herse.apache.org: local policy)
Received: from [209.235.254.11] (HELO exodus.exist.com) (209.235.254.11)
    by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 21 Nov 2006 14:38:48 -0800
Received: from [192.168.200.164] ([205.147.11.148])
	(authenticated bits=0)
	by exodus.exist.com (8.13.1/8.13.1) with ESMTP id kALMcLOC016763
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO)
	for <activemq-users@geronimo.apache.org>; Tue, 21 Nov 2006 17:38:22 -0500
Message-ID: <45637FDE.6050302@exist.com>
Date: Wed, 22 Nov 2006 06:38:22 +0800
From: Adrian Co <aco@exist.com>
User-Agent: Thunderbird 1.5.0.8 (Windows/20061025)
MIME-Version: 1.0
To: activemq-users@geronimo.apache.org
Subject: Re: Newbie configuration questions
References: <7479997.post@talk.nabble.com>
In-Reply-To: <7479997.post@talk.nabble.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Virus-Checked: Checked by ClamAV on apache.org

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
>