D'OH!!!
The hyperlink has vanished for the slides, look here:
fusesource.com/collateral/download/74/
On Jan 4, 2011, at 8:51 PM, Dirk Fröhner wrote:
> Hi wezhall,
>
> yes, when you want to have an HA JMS node, you will need to chose the "real"
> architecture: Mast
Hi wezhall,
yes, when you want to have an HA JMS node, you will need to chose the "real"
architecture: Master and slave using a shared persistence layer in two ways:
a) as mutex to determine which process is master and which process is slave and
b) for sharing the storage for the persistent queue
Albrecht,
to infinitely try to obtain the lock on the shared persistence layer is exactly
a slave's job. It does nothing else before that happens. The process that has
the lock automatically is the master, the process that waits for the lock
automatically is the slave. This applies to all addit
ch other.
>>>>>> Destinations are distributed on the participating nodes as far as
>>>>>> they're involved. Clients can connect to any of the nodes to produce
>>>>>> messages. The same applies for consumption, since messages are forwarded
>>>&
main reason for a NWOB
would be to scale horizontally (for queues) or to distribute destinations over
multiple networks. Unless you really have significant traffic, one node can
handle quite a lot of queue messages (several k/s, depending on infrastructure
and persistence).
Hope that helps.
Hi devnull,
did you make sure that your Java consumers do eventually ACK messages (i.e. is
it ensured that onMessage() does always return)? You should also have a look at
the subscription properties on that destination in jconsole.
Glück auf,
Dirk
On Oct 28, 2010, at 12:09 AM, devnull wrote:
se.
> see: https://issues.apache.org/activemq/browse/AMQ-1847
>
> On 11 August 2010 11:39, Dirk Fröhner wrote:
>> Mahlzeit!
>>
>> I experience an unexpected behaviour when playing around with and
>> doing some sanity checks on RedeliveryPolicy. When I have a transact
Mahlzeit!
I experience an unexpected behaviour when playing around with and
doing some sanity checks on RedeliveryPolicy. When I have a transacted
consumer session that does a rollback after receiving a message, I can
observe that the first redelivery happens immediately and only for the
second re
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Afternoon,
when you experience this next time, take thread dumps of the brokers. I
had to deal with this before when we had restarting some
client applications a lot of times in a row with kill -9, but the
following behaviour can also be caused by ot
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Andreas,
did you create a thread dump of the (active) broker process?
Glück auf,
Dirk
Andreas Prüller wrote:
> Hello,
>
>
>
> currently I have an ActiveMQ 5.4-SNAPSHOT running for a test. It is as pure
> master-slave configured.
>
> Last Frida
10 matches
Mail list logo
