Mailing-List: contact users-help@activemq.apache.org; run by ezmlm
Precedence: bulk
Reply-To: users@activemq.apache.org
Received-SPF: pass (herse.apache.org: domain of james.strachan@gmail.com
 designates 64.233.182.186 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=beta;
        h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references;
        b=rL/KSVGSkrkF+OG5fzDg+xmM5R8wxshzltrV7uOK2zDqHvH2IUn1EXfkWDQz538Ry/R896l4aHgwncrcuyZXZgvAjivWq4uf98UwSB/4ApJiSGt7Rc7jZR/9qU7d8IcSU6gI6C8vih2KPV24IvycVKL3oWuTEzZdFQiXno70l2c=
Message-ID: <ec6e67fd0703051107l39e6b4d9g13aba2d0193685c@mail.gmail.com>
Date: Mon, 5 Mar 2007 19:07:36 +0000
From: "James Strachan" <james.strachan@gmail.com>
To: users@activemq.apache.org
Subject: Re: Evaluating Embedded ActiveMQ - questions
In-Reply-To: <9317788.post@talk.nabble.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
References: <9317788.post@talk.nabble.com>

On 3/5/07, rbector <bector.online@gmail.com> wrote:
>
> Hello
>    I am currently evaluating the feasibility of using ActiveMQ for our
> system (which is a bunch of applications who want to interact using JMS).  I
> had a few questions which I thought some of you may have answers to:
>
> 1) We'd prefer to use the embedded version of the broker. All communicating
> applications would use the embedded broker so there would be no *server*
> running. I've read that this Topology is supported by ActiveMQ. What are the
> downsides of using this topology ? The upsides to me are - higher
> performance because of one less hop and less maintenance. Comments ?

The main downside is managing persistent state. Using embedded brokers
means each process has a bunch of persistent files and/or database. If
you've tons of processes this becomes unwiedly soon, so running
separate brokers is often easier.


> 2) I would like to have the ability to create topics such that messages on
> them are never deleted. Essentially, any consumer could attach to the topic
> any point in time (even 30 days after the topic was created) and receive
> older messages (Ideally - it should have the choice to start receiving
> messages from a certain point in time in the past or from a certain ID). The
> idea behind this approach is that consumers are more decoupled. They could
> process some messages, checkpoint them internally and go away and come back
> later.  I would like to try to understand if this is directly or indirectly
> supported in ActiveMQ (or other JAVA based messaging systems that people
> know of)

Its generally not supported by JMS but we've some extensions you can
use to do this kind of thing...

http://activemq.apache.org/subscription-recovery-policy.html


> 3) If there are n consumers interested in a certain topic, some of the
> consumers may be away when messages on that topic are published. Whats the
> behavior of ActiveMQ in such a scenario ?  Is the subscription information
> maintained on a persistent basis (we'd like it to be).  (This is also in the
> context of embedded broker - the broker is embedded inside the
> producers/consumers)

It depends if you are using a durable topic consumer or not. If you
are, then yes it is. Otherwise no :).


-- 

James
-------
http://radio.weblogs.com/0112098/