Broker config

[Naby <us...@abwesend.de>]

Hello.

We are running ActiveMQ RC1 with Java1.5 and the default configuration on an
Linux system now. It is used by about 50 clients with about 100-150
non-durable non-persistent topics at the same time.

Can someone recommend an broker configuration to me?

Thx
--
View this message in context: http://www.nabble.com/Broker-config-t1391314.html#a3739257
Sent from the ActiveMQ - User forum at Nabble.com.

Re: Broker config

[James Strachan <ja...@gmail.com>]

On 4/5/06, Adrian Co <ac...@exist.com> wrote:
> Hi,
>
> To try and answer some of your questions:
>
> Naby wrote:

[snip]]

> >c) How often does it happen that a broker fails/dies forever?
> >
> >
> I can't say really depends on a lot of factors I think. :-)

Agreed. Its probably most common that just sockets go bad so that the
client with try to reconnect again. Brokers failing or being killed is
quite rare but can happen.


> >Let me ask another question.
> >We are running web clients. There is a time lack between the start of these
> >clients and the registration to the topics but we want the clients to get
> >the messages which are published within this time, but not messages
> >published before the start.
> >What do you think is a good technic/configuration to solve this problem?
> >
> >
> I don't know if this would work for you, but AMQ 4.x has a
> TimedSubscriptionRecoveryPolicy, which basically allows you to specify
> how long messages should be cached in memory before being discarded. If
> you use this, you should also make your consumers retroactive.

The subscription recovery policy allows you to go back in time for
non-durable topic subscriptions
http://activemq.org/Subscription+Recovery+Policy

(for durable topic subscriptions clearly this is not really necessary).

It does take the broker a little while to realise a socket is dead and
close down the current subscriptions; there is a chance the client
could reconnect in time; we could maybe do a better job at realising
clients are down and waiting long enough before really discarding the
connection/subscription/messages. Though the subscription recovery
mechanism should act as a catch-all which can deal with clients moving
from one broker to another and still avoiding missing any messages

--

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

Re: Broker config

[Adrian Co <ac...@exist.com>]

Hi,

To try and answer some of your questions:

Naby wrote:

>Thx James.
>I have some questions about it
>a) Is a message published to the failover broker if a producer gets no
>connection to the broker?
>  
>
Yes. As long as the failover connection of the client is able to connect 
to the secondaty broker. What failover does is detect when a connection 
has failed and try to establish a connection with other brokers in the 
failover list. i.e. if you have 
failover:(tcp://brokerA:61616,tcp://brokerB:61616), and a producer 
publishes to brokerA while it is down, the connection will fail and it 
will try to connect to brokerB and send the message there. You don't 
have to do anything special in the client side except specify the 
reconnection options like how many times it should try to connect to any 
brokers in the list or the interval between each reconnection attempt, etc.

>b) How can i check if a broker fails?
>  
>
I haven't tried it yet, but I think you could register a 
TransportListener to your connection to be notified of transport events 
like transportInterrupted, transportResumed, etc. Although I don't think 
its a guarantee that the broker had failed. It could be that the 
connection has failed for some other reason. You could also use JMX in 
AMQ 4.x to monitor the state of the broker.

>c) How often does it happen that a broker fails/dies forever?
>  
>
I can't say really depends on a lot of factors I think. :-)

>Let me ask another question.
>We are running web clients. There is a time lack between the start of these
>clients and the registration to the topics but we want the clients to get
>the messages which are published within this time, but not messages
>published before the start.
>What do you think is a good technic/configuration to solve this problem? 
>  
>
I don't know if this would work for you, but AMQ 4.x has a 
TimedSubscriptionRecoveryPolicy, which basically allows you to specify 
how long messages should be cached in memory before being discarded. If 
you use this, you should also make your consumers retroactive.

Hope any of it helps. :-)

>Naby
>
>
>--
>View this message in context: http://www.nabble.com/Broker-config-t1391314.html#a3749901
>Sent from the ActiveMQ - User forum at Nabble.com.
>
>  
>

Re: Broker config

[Naby <us...@abwesend.de>]

Thx James.
I have some questions about it
a) Is a message published to the failover broker if a producer gets no
connection to the broker?
b) How can i check if a broker fails?
c) How often does it happen that a broker fails/dies forever?

Let me ask another question.
We are running web clients. There is a time lack between the start of these
clients and the registration to the topics but we want the clients to get
the messages which are published within this time, but not messages
published before the start.
What do you think is a good technic/configuration to solve this problem? 

Naby


--
View this message in context: http://www.nabble.com/Broker-config-t1391314.html#a3749901
Sent from the ActiveMQ - User forum at Nabble.com.

Re: Broker config

[James Strachan <ja...@gmail.com>]

On 4/4/06, Naby <us...@abwesend.de> wrote:
>
> Hello.
>
> We are running ActiveMQ RC1 with Java1.5 and the default configuration on an
> Linux system now. It is used by about 50 clients with about 100-150
> non-durable non-persistent topics at the same time.
>
> Can someone recommend an broker configuration to me?

The default configuration should work well for this architecture. If
you explicitly want to disable all persistence, you could set the
persistent flag to false in the <broker> tag. Other than that I think
you're done.

A single broker should be able to deal with the load of 50 clients; if
you really want you could run 2 brokers in a network then let clients
use the failover: protocol to connect to either one so that if one
broker fails, clients will failover to the other one.
http://activemq.org/Networks+of+Brokers

--

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