You mean, if we use the same Shared file system for all brokers and common
DB (following config for all brokers)
<persistenceAdapter>
<journaledJDBC dataDirectory="/sharedFileSystem/broker"
dataSource="#db2l-ds" />
</persistenceAdapter>
then the master and slave(s) use the same sharedFileSystem for Journal. Is
it correct?
If so, is the above config fine for Failover in clustering environment or
Do you still say this is NOT appropriate for Failover.
THANK YOU.
Gary Tully wrote:
>
> Shared file system master slave is fine.
> The problem is with "journal + jdbc" as the journal part of that is local
> to
> a broker instance.
>
>
> On 29 April 2010 17:02, KRISHNAS <krishna_see...@hotmail.com> wrote:
>
>>
>> Activemq recommends 'Shared file System Master Slave' as one of the HA
>> approaches for failover in clustering environment.
>>
>> http://activemq.apache.org/shared-file-system-master-slave.html
>> http://activemq.apache.org/shared-file-system-master-slave.html
>>
>>
>> But you say it is not appropriate. Do you see any cons of it?
>>
>> Thank you for replies.
>>
>>
>> Gary Tully wrote:
>> >
>> > For fail over, the batching nature of the journal is not appropriate,
>> you
>> > need to send messages directly to the store, either jdbc or file based.
>> >
>> > On 29 April 2010 02:51, KRISHNAS <krishna_see...@hotmail.com> wrote:
>> >
>> >>
>> >>
>> >> Thanks lot for your reply Gary,
>> >>
>> >> We have also looked at the 'jdbc statemetns', unfortunately as per
>> DB2,
>> >> any
>> >> statement on the lock table - could cause error, so jdbc statements
>> may
>> >> not
>> >> help (Still we are investigating though)
>> >>
>> >> So we have to use either specific data source for the locking or we
>> may
>> >> end
>> >> up writing our own file system based locker class. If so, we will
>> >> contribute
>> >> it.
>> >>
>> >> We are also looking at the 'Shared file System Master Slave' approach
>> -
>> >> which uses the Journal + datasource using <journaledJDBC ... >. There
>> it
>> >> uses the File system for locking and permanent DB for persistency.
>> >>
>> >> But, as per Journal architecture, it may not store all the messages in
>> >> the
>> >> DB (it only persists the left over messages at checkpoint point). But
>> we
>> >> want ALL the messages received by the broker should persist in the
>> >> permanent DB.
>> >>
>> >> So is there any way to force the Journal to persist all messages in
>> the
>> >> permanent DB (probably by ignoring the check point) or any other
>> >> approach?
>> >>
>> >> Thank you,
>> >> Krishna.
>> >>
>> >>
>> >> --
>> >> View this message in context:
>> >>
>> http://old.nabble.com/How-to-use-the-File-System-for-locking-purpose-and-use-the-DB-for-Message-Persistency-only--tp28391833p28395879.html
>> >> Sent from the ActiveMQ - User mailing list archive at Nabble.com.
>> >>
>> >>
>> >
>> >
>> > --
>> > http://blog.garytully.com
>> >
>> > Open Source Integration
>> > http://fusesource.com
>> >
>> >
>> http://activemq.apache.org/shared-file-system-master-slave.html
>> http://activemq.apache.org/shared-file-system-master-slave.html
>> --
>> View this message in context:
>> http://old.nabble.com/How-to-use-the-File-System-for-locking-purpose-and-use-the-DB-for-Message-Persistency-only--tp28391833p28402548.html
>> Sent from the ActiveMQ - User mailing list archive at Nabble.com.
>>
>>
>
>
> --
> http://blog.garytully.com
>
> Open Source Integration
> http://fusesource.com
>
>
--
View this message in context:
http://old.nabble.com/How-to-use-the-File-System-for-locking-purpose-and-use-the-DB-for-Message-Persistency-only--tp28391833p28403590.html
Sent from the ActiveMQ - User mailing list archive at Nabble.com.
