Re: Shared File System Master Slave
Yes, that information is applicable and gives a good overview of the internals of KahaDB. Tim On Mon, Apr 9, 2018, 1:29 AM norinos wrote: > I found the following site. Is this helpful for me? > > http://www.idevnews.com/images/emailers/110127_ProgressFUSE/WhitePapers/ActiveMQinActionCH05.pdf > > -- > Sent from: > http://activemq.2283324.n4.nabble.com/ActiveMQ-User-f2341805.html >
Re: Shared File System Master Slave
Hi Tim ! thanks a lot. > The documentation you linked to is for the AMQ message store, not the > KahaDB message store. So if you're using KahaDB as you say, then the page > you linked to is irrelevant. I finally understood that AMQ and KahaDB are different. > KahaDB behaves as I described. You only risk losing messages that have not > yet been accepted (i.e. you don't risk losing anything). If I recall > correctly, the only thing that's flushed to disk periodically is the > index, > and that can be rebuilt from the raw journal files so there's no risk of > data loss, just a slower broker startup. I feel relieved that it seems there is no risk. I found the following site. Is this helpful for me? http://www.idevnews.com/images/emailers/110127_ProgressFUSE/WhitePapers/ActiveMQinActionCH05.pdf -- Sent from: http://activemq.2283324.n4.nabble.com/ActiveMQ-User-f2341805.html
Re: Shared File System Master Slave
The documentation you linked to is for the AMQ message store, not the KahaDB message store. So if you're using KahaDB as you say, then the page you linked to is irrelevant. KahaDB behaves as I described. You only risk losing messages that have not yet been accepted (i.e. you don't risk losing anything). If I recall correctly, the only thing that's flushed to disk periodically is the index, and that can be rebuilt from the raw journal files so there's no risk of data loss, just a slower broker startup. Tim On Sun, Apr 8, 2018, 10:06 PM norinos wrote: > As you say, I'm using KahaDB. > > > You asked whether subscriptions would be on the new master, and the > answer > > depends on whether the subscription was durable. If it was a durable > > subscription, the subscription information is persisted and the > > subscription will be in the same state on the new master, even if the > > client doesn't immediately reconnect. If the subscription is not durable, > > then it will be recreated when the client reconnects to the new master, > so > > any messages that were unconsumed at the time the original master went > > down > > and any messages sent before the client reconnects will be lost for that > > subscriber. > > I'm using durable subscription. > So, I understand that clients can receive the message without problems > when switching from master to slave. > > > Please tell me a little more. > > ActiveMQ insert cache index into the reference store for performance at > checkpoint interval. > > If master goes down, it seems that chache index can not insert. > So reference store is not up-to-date. > > In this case, if I startup up ActiveMQ, Is the reference store updated at > the start-up phase? > > > > > -- > Sent from: > http://activemq.2283324.n4.nabble.com/ActiveMQ-User-f2341805.html >
Re: Shared File System Master Slave
As you say, I'm using KahaDB. > You asked whether subscriptions would be on the new master, and the answer > depends on whether the subscription was durable. If it was a durable > subscription, the subscription information is persisted and the > subscription will be in the same state on the new master, even if the > client doesn't immediately reconnect. If the subscription is not durable, > then it will be recreated when the client reconnects to the new master, so > any messages that were unconsumed at the time the original master went > down > and any messages sent before the client reconnects will be lost for that > subscriber. I'm using durable subscription. So, I understand that clients can receive the message without problems when switching from master to slave. Please tell me a little more. ActiveMQ insert cache index into the reference store for performance at checkpoint interval. If master goes down, it seems that chache index can not insert. So reference store is not up-to-date. In this case, if I startup up ActiveMQ, Is the reference store updated at the start-up phase? -- Sent from: http://activemq.2283324.n4.nabble.com/ActiveMQ-User-f2341805.html
Re: Shared File System Master Slave
The AMQ store is not widely used these days. You'll probably be using the KahaDB store: activemq.apache.org/kahadb.html As you said, if there is any content that has not been flushed to disk, it will be lost when the master goes down. However, unless you've manually set enableJournalDiskSyncs to false, you're not going to lose any messages whose receipt has been confirmed by the broker. (Any messages lost will be messages the broker has not yet confirmed receipt of.) When the slave broker attempts to become active, it will read the data files and begin serving clients. You asked whether subscriptions would be on the new master, and the answer depends on whether the subscription was durable. If it was a durable subscription, the subscription information is persisted and the subscription will be in the same state on the new master, even if the client doesn't immediately reconnect. If the subscription is not durable, then it will be recreated when the client reconnects to the new master, so any messages that were unconsumed at the time the original master went down and any messages sent before the client reconnects will be lost for that subscriber. Tim On Fri, Apr 6, 2018, 1:54 AM norinos wrote: > I am planning to use Shared File System Master Slave.(I use AcitveMQ > 5.13.1) > http://activemq.apache.org/shared-file-system-master-slave.html > > With this system, even though master(#1)'s process goes down due to > trouble, > I think that ActiveMQ can be continuously used in slave(#2) process. > > I have a question. > > http://activemq.apache.org/amq-message-store.html > > According to the above documentation, MQ's memory cache periodically > inserted into the reference store(db.data). > > If master(#1) goes down, memory cache cannot insert. > It seems that the reference sotre index does not match the Data Logs. > > At this time, can #2(New master) start normally ? > If not, What kind of trouble will occur ? > For example, Subscribed messages will be subscribe agein. > > > > > > -- > Sent from: > http://activemq.2283324.n4.nabble.com/ActiveMQ-User-f2341805.html >
Re: Shared File System Master/Slave with DRBD
Greg, Thanks for the reply. I just wanted to confirm a couple of things. 1) The NFS requirement is so that DRBD can be used in Primary/Primary mode as the file system needs to be writeable from both nodes? 2) With NFS I would also need to use Pacemaker to make the NFS server HA? 3) Is the NFS Tech Guide listed at http://www.linbit.com/en/downloads/tech-guides what you are referring to? Thanks, Mark On 1 May 2014 00:34, Greg Eckert wrote: > Hey Mark, > > You should be able to use drbd with something like NFS without a problem. > The LINBIT engineers are in the process publishing an NFS Tech guide... For > current official documentation, feel free to contact me directly. > > Best Regards, > > Greg > > -- > : Greg Eckert > : g...@linbit.com > : Not an Engineer > : LINBIT | "Your Way to High Availability" > : Web: http://www.linbit.com > >
Re: SHARED FILE SYSTEM MASTER/SLAVE (newb)
The slave is a standby that will once it can lock the journal "reverse" the roles, so the downed node once it is up will start looking for the lock. On Jan 8, 2013, at 9:38 AM, pico wrote: > configured 2 brokers using the shared file syntax > > However, the slave broker is always looking for the database connection and > is not starting up. > Is this the expected behavior? > > Log from the slave broker > INFO | jvm 1| 2013/01/08 10:14:40 | INFO | Database > \\servername\Shared-Queue\data\kahadb\lock is locked... waiting 10 seconds > for the database to be unlocked. Reason: java.io.IOException: File > '\\Ssmsftd1\Shared-Queue\data\kahadb\lock' could not be locked. > INFO | jvm 1| 2013/01/08 10:14:50 | INFO | Database > \\servername\Shared-Queue\data\kahadb\lock is locked... waiting 10 seconds > for the database to be unlocked. Reason: java.io.IOException: File > '\\Ssmsftd1\Shared-Queue\data\kahadb\lock' could not be locked. > INFO | jvm 1| 2013/01/08 10:15:00 | INFO | Database > \\servername\Shared-Queue\data\kahadb\lock is locked... waiting 10 seconds > for the database to be unlocked. Reason: java.io.IOException: File > '\\Ssmsftd1\Shared-Queue\data\kahadb\lock' could not be locked. > INFO | jvm 1| 2013/01/08 10:15:10 | INFO | Database > \\servername\Shared-Queue\data\kahadb\lock is locked... waiting 10 seconds > for the database to be unlocked. Reason: java.io.IOException: File > '\\Ssmsftd1\Shared-Queue\data\kahadb\lock' could not be locked. > > > > > > -- > View this message in context: > http://activemq.2283324.n4.nabble.com/SHARED-FILE-SYSTEM-MASTER-SLAVE-newb-tp4661492.html > Sent from the ActiveMQ - User mailing list archive at Nabble.com.
Re: Shared File System Master Slave Tips?
Thank you for sharing that, Mario. Mike On May 31, 2007, at 11:45 AM, Mario Siegenthaler wrote: We've tried it on NFS on linux and it didn't work (some locking issue with java and nfs). However it worked with windows shares, but we're not using it because we run linux boxes. Mario On 5/31/07, Michael Slattery <[EMAIL PROTECTED]> wrote: Hello List! I'm interested in putting together the Shared File System Master Slave scenario in a managed hosting setup. What are you using to achieve the shared file system master slave on your installs? I would appreciate it very much if folks on this list would share descriptions of successful environments. SAN/NAS, Filesystems, etc would be very helpful. If you are doing this in a managed hosting environment, even better!It's not easy to determine who is doing SAN with shared access or decent NAS from the vendor websites out there (rackspace and the like). Last case, if you tried Shared File System Master Slave but found that you had to go with JDBC that would also be helpful. Thank you. Mike
Re: Shared File System Master Slave Tips?
We've tried it on NFS on linux and it didn't work (some locking issue with java and nfs). However it worked with windows shares, but we're not using it because we run linux boxes. Mario On 5/31/07, Michael Slattery <[EMAIL PROTECTED]> wrote: Hello List! I'm interested in putting together the Shared File System Master Slave scenario in a managed hosting setup. What are you using to achieve the shared file system master slave on your installs? I would appreciate it very much if folks on this list would share descriptions of successful environments. SAN/NAS, Filesystems, etc would be very helpful. If you are doing this in a managed hosting environment, even better!It's not easy to determine who is doing SAN with shared access or decent NAS from the vendor websites out there (rackspace and the like). Last case, if you tried Shared File System Master Slave but found that you had to go with JDBC that would also be helpful. Thank you. Mike
Re: Shared File System Master Slave with OCFS
On 5/19/07, Christopher G. Stach II <[EMAIL PROTECTED]> wrote: James Strachan wrote: > > Thanks for the heads up! :) > > I guess we could make the locking strategy pluggable & we could have > some implementation call the fcntl locking. e.g. maybe using Jtux > > http://www.basepath.com/aup/jtux/ > Even though one could achieve this, I don't know what the benefit would be. Allow folks to run multiple broker instances on a shared file system so that if one broker fails, another takes over. http://activemq.apache.org/shared-file-system-master-slave.html It only shifts the responsibility down. At least the user would want a broker that is dependent on one or more brokers. Each of those brokers shouldn't be dependent on each other for locking, data, or anything else. I can appreciate that some people assume that shared data is available, but shared data is just as easily corrupted, locked, or unavailable. Essentially, when you find a single responsibility and divide it, it probably shouldn't converge somewhere down the line. This current pattern is most likely unusable for any HA situation. Agreed - I'd much prefer a share nothing HA strategy where folks can spin up and down brokers at any point in time and everything just works (tm) with messages replicated onto multiple physical stores and things auto-partitioning etc. However we're not there yet, so its a question of trade-offs. Some folks find it easier to rely on their shared file system / SAN to do the HA; others can use the share-nothing approach in ActiveMQ (Pure Master Slave)... http://activemq.apache.org/masterslave.html and live with the current limitations (no automatic fail-back of the old master when it is brought back online). Like many things in IT its a tradeoff. For now, today, the shared file system approach is a pretty reasonable approach; if you already have a reliable distributed file system (particularly if you have a SAN). -- James --- http://macstrac.blogspot.com/
Re: Shared File System Master Slave with OCFS
Christopher G. Stach II wrote: > James Strachan wrote: >> Thanks for the heads up! :) >> >> I guess we could make the locking strategy pluggable & we could have >> some implementation call the fcntl locking. e.g. maybe using Jtux >> >> http://www.basepath.com/aup/jtux/ >> > > Even though one could achieve this, I don't know what the benefit would > be. It only shifts the responsibility down. At least the user would > want a broker that is dependent on one or more brokers. Each of those > brokers shouldn't be dependent on each other for locking, data, or > anything else. I can appreciate that some people assume that shared > data is available, but shared data is just as easily corrupted, locked, > or unavailable. Essentially, when you find a single responsibility and > divide it, it probably shouldn't converge somewhere down the line. This > current pattern is most likely unusable for any HA situation. > Wow. That sounded kind of snotty. :) I meant "client that is dependent", too. -- Christopher G. Stach II
Re: Shared File System Master Slave with OCFS
James Strachan wrote: > > Thanks for the heads up! :) > > I guess we could make the locking strategy pluggable & we could have > some implementation call the fcntl locking. e.g. maybe using Jtux > > http://www.basepath.com/aup/jtux/ > Even though one could achieve this, I don't know what the benefit would be. It only shifts the responsibility down. At least the user would want a broker that is dependent on one or more brokers. Each of those brokers shouldn't be dependent on each other for locking, data, or anything else. I can appreciate that some people assume that shared data is available, but shared data is just as easily corrupted, locked, or unavailable. Essentially, when you find a single responsibility and divide it, it probably shouldn't converge somewhere down the line. This current pattern is most likely unusable for any HA situation. -- Christopher G. Stach II
Re: Shared File System Master Slave with OCFS
On 5/18/07, Christopher G. Stach II <[EMAIL PROTECTED]> wrote:
James Strachan wrote:
> On 5/18/07, James Strachan <[EMAIL PROTECTED]> wrote:
>> On 5/17/07, felipera <[EMAIL PROTECTED]> wrote:
>> > Hi everyone,
>> >
>> > I am trying to setup two MQ Servers (4.1.1), sharing the same data
>> directory
>> > (I tried Derby and Kaha), on top of OCFS, but the locking doesn't
>> seem to be
>> > working. It works fine when both MQs are running on the same server
>> (still
>> > using OCFS). I see the second MQ waiting for the lock to be released
>> > ("Journal is locked... waiting 10 seconds for the journal to be
>> unlocked.").
>> > That's why I am not sure if it's a OCFS issue. But when I run each
>> MQ in
>> > separate boxes (still sharing the same data directory using OCFS) it
>> doesn't
>> > work, they both start successfully.
>>
>> This is the OCFS you're talking about right?
>> http://en.wikipedia.org/wiki/OCFS2
>
> Actually OCFS2 seems more like a real distributed file system for
> general purpose use; the OCFS looks more specifically for using to
> host oracle data tables. Am wondering how good the file locking is on
> OCFS? Certainly its clear the mutex file locking from Java isn't
> supported on OCFS.
>
OCFS2 properly supports POSIX locking semantics with fcntl. lockf and
flock aren't supported yet. If that's what the JVM uses under the
covers, you're out of luck. If this is about OCFS and not OCFS2, I'm
really sorry. :)
Thanks for the heads up! :)
I guess we could make the locking strategy pluggable & we could have
some implementation call the fcntl locking. e.g. maybe using Jtux
http://www.basepath.com/aup/jtux/
--
James
---
http://macstrac.blogspot.com/
Re: Shared File System Master Slave with OCFS
James Strachan wrote:
> On 5/18/07, James Strachan <[EMAIL PROTECTED]> wrote:
>> On 5/17/07, felipera <[EMAIL PROTECTED]> wrote:
>> > Hi everyone,
>> >
>> > I am trying to setup two MQ Servers (4.1.1), sharing the same data
>> directory
>> > (I tried Derby and Kaha), on top of OCFS, but the locking doesn't
>> seem to be
>> > working. It works fine when both MQs are running on the same server
>> (still
>> > using OCFS). I see the second MQ waiting for the lock to be released
>> > ("Journal is locked... waiting 10 seconds for the journal to be
>> unlocked.").
>> > That's why I am not sure if it's a OCFS issue. But when I run each
>> MQ in
>> > separate boxes (still sharing the same data directory using OCFS) it
>> doesn't
>> > work, they both start successfully.
>>
>> This is the OCFS you're talking about right?
>> http://en.wikipedia.org/wiki/OCFS2
>
> Actually OCFS2 seems more like a real distributed file system for
> general purpose use; the OCFS looks more specifically for using to
> host oracle data tables. Am wondering how good the file locking is on
> OCFS? Certainly its clear the mutex file locking from Java isn't
> supported on OCFS.
>
OCFS2 properly supports POSIX locking semantics with fcntl. lockf and
flock aren't supported yet. If that's what the JVM uses under the
covers, you're out of luck. If this is about OCFS and not OCFS2, I'm
really sorry. :)
--
Christopher G. Stach II
Re: Shared File System Master Slave with OCFS
On 5/18/07, James Strachan <[EMAIL PROTECTED]> wrote:
On 5/17/07, felipera <[EMAIL PROTECTED]> wrote:
> Hi everyone,
>
> I am trying to setup two MQ Servers (4.1.1), sharing the same data directory
> (I tried Derby and Kaha), on top of OCFS, but the locking doesn't seem to be
> working. It works fine when both MQs are running on the same server (still
> using OCFS). I see the second MQ waiting for the lock to be released
> ("Journal is locked... waiting 10 seconds for the journal to be unlocked.").
> That's why I am not sure if it's a OCFS issue. But when I run each MQ in
> separate boxes (still sharing the same data directory using OCFS) it doesn't
> work, they both start successfully.
This is the OCFS you're talking about right?
http://en.wikipedia.org/wiki/OCFS2
Actually OCFS2 seems more like a real distributed file system for
general purpose use; the OCFS looks more specifically for using to
host oracle data tables. Am wondering how good the file locking is on
OCFS? Certainly its clear the mutex file locking from Java isn't
supported on OCFS.
--
James
---
http://macstrac.blogspot.com/
Re: Shared File System Master Slave with OCFS
On 5/17/07, felipera <[EMAIL PROTECTED]> wrote:
Hi everyone,
I am trying to setup two MQ Servers (4.1.1), sharing the same data directory
(I tried Derby and Kaha), on top of OCFS, but the locking doesn't seem to be
working. It works fine when both MQs are running on the same server (still
using OCFS). I see the second MQ waiting for the lock to be released
("Journal is locked... waiting 10 seconds for the journal to be unlocked.").
That's why I am not sure if it's a OCFS issue. But when I run each MQ in
separate boxes (still sharing the same data directory using OCFS) it doesn't
work, they both start successfully.
This is the OCFS you're talking about right?
http://en.wikipedia.org/wiki/OCFS2
I guess the file locking isn't working from Java. I wonder how to use
file locking properly on OCFS.
I am thinking about using a network of brokers, since I don't know what else
to try.
If you want clustering & replicated message stores you could try one
of the other Master/Slave implementations.
http://activemq.apache.org/masterslave.html
FWIW Networks of Brokers is for store and forward of messages only;
messages are never replicated in multiple locations with networks of
brokers.
--
James
---
http://macstrac.blogspot.com/
Re: Re: Shared File System Master Slave with Windows
On 4/10/07, Dingwen Yuan <[EMAIL PROTECTED]> wrote: I have tried the latest version - apache-activemq-4.2-20070328.130210-35, but the same error still exists. With what are you going to substitute activeio? activeio has been removed from the codebase -- James --- http://radio.weblogs.com/0112098/
Re: Re: Shared File System Master Slave with Windows
I have tried the latest version - apache-activemq-4.2-20070328.130210-35, but the same error still exists. With what are you going to substitute activeio? Thank you! Dingwen Yuan 2007-04-10 发件人： James Strachan 发送时间： 2007-04-03 15:49:52 收件人： users@activemq.apache.org 抄送： 主题： Re: Shared File System Master Slave with Windows On 4/3/07, pdvyuan <[EMAIL PROTECTED] > wrote: > Hi all, > > Can I use a shared windows file system to achieve "Shared File System Master > Slave"? I have made some tests, but occasionally some error would occur. I > made the test under 2 instances of activemq-4.2 runing on WinXP. The errors > are as follows: > > 2007-03-30 17:04:33,640 [28.64.7.49:4858] DEBUG JournalMessageStore > - Journalled message add for: > ID:xuj01-a7d120-3614-1174637145906-0:0:1:1:296058, at: 39:3829174 > 2007-03-30 17:04:33,687 [eckpoint Worker] DEBUG JournalPersistenceAdapter > - Checkpoint started. > 2007-03-30 17:04:33,703 [8.64.7.111:1333] DEBUG JournalMessageStore > - Journalled message remove for: > ID:xuj01-a7d120-3615-1174637145921-1:0:1:1:109282, at: 39:3830090 > 2007-03-30 17:04:33,781 [eckpoint Worker] DEBUG JournalPersistenceAdapter > - Marking journal at: 39:3829174 > 2007-03-30 17:04:33,781 [eckpoint Worker] ERROR JournalPersistenceAdapter > - Failed to mark the Journal: > org.apache.activeio.journal.InvalidRecordLocationException: The location is > less than the last mark. > org.apache.activeio.journal.InvalidRecordLocationException: The location is > less than the last mark. > at > org.apache.activeio.journal.active.JournalImpl.setMark(JournalImpl.java:340) > at > org.apache.activemq.store.journal.JournalPersistenceAdapter.doCheckpoint(JournalPersistenceAdapter.java:400) > at > org.apache.activemq.store.journal.JournalPersistenceAdapter$2.iterate(JournalPersistenceAdapter.java:128) > at > org.apache.activemq.thread.DedicatedTaskRunner.runTask(DedicatedTaskRunner.java:88) > at > org.apache.activemq.thread.DedicatedTaskRunner.access$000(DedicatedTaskRunner.java:25) > at > org.apache.activemq.thread.DedicatedTaskRunner$1.run(DedicatedTaskRunner.java:39) > 2007-03-30 17:04:33,781 [eckpoint Worker] DEBUG JournalPersistenceAdapter > - Checkpoint done. > > Is this error due to the insufficient support of "exclusive file locks" by > Windows. The above looks like a bug. I'm guessing you've used a fairly old snapshot of 4.2, I'd recommend using a recent one from the end of March 2007 which no longer uses activeio AFAIK. http://people.apache.org/repo/m2-snapshot-repository/org/apache/activemq/apache-activemq/4.2-SNAPSHOT/ -- James --- http://radio.weblogs.com/0112098/
Re: Shared File System Master Slave with Windows
On 4/3/07, pdvyuan <[EMAIL PROTECTED]> wrote: Hi all, Can I use a shared windows file system to achieve "Shared File System Master Slave"? I have made some tests, but occasionally some error would occur. I made the test under 2 instances of activemq-4.2 runing on WinXP. The errors are as follows: 2007-03-30 17:04:33,640 [28.64.7.49:4858] DEBUG JournalMessageStore - Journalled message add for: ID:xuj01-a7d120-3614-1174637145906-0:0:1:1:296058, at: 39:3829174 2007-03-30 17:04:33,687 [eckpoint Worker] DEBUG JournalPersistenceAdapter - Checkpoint started. 2007-03-30 17:04:33,703 [8.64.7.111:1333] DEBUG JournalMessageStore - Journalled message remove for: ID:xuj01-a7d120-3615-1174637145921-1:0:1:1:109282, at: 39:3830090 2007-03-30 17:04:33,781 [eckpoint Worker] DEBUG JournalPersistenceAdapter - Marking journal at: 39:3829174 2007-03-30 17:04:33,781 [eckpoint Worker] ERROR JournalPersistenceAdapter - Failed to mark the Journal: org.apache.activeio.journal.InvalidRecordLocationException: The location is less than the last mark. org.apache.activeio.journal.InvalidRecordLocationException: The location is less than the last mark. at org.apache.activeio.journal.active.JournalImpl.setMark(JournalImpl.java:340) at org.apache.activemq.store.journal.JournalPersistenceAdapter.doCheckpoint(JournalPersistenceAdapter.java:400) at org.apache.activemq.store.journal.JournalPersistenceAdapter$2.iterate(JournalPersistenceAdapter.java:128) at org.apache.activemq.thread.DedicatedTaskRunner.runTask(DedicatedTaskRunner.java:88) at org.apache.activemq.thread.DedicatedTaskRunner.access$000(DedicatedTaskRunner.java:25) at org.apache.activemq.thread.DedicatedTaskRunner$1.run(DedicatedTaskRunner.java:39) 2007-03-30 17:04:33,781 [eckpoint Worker] DEBUG JournalPersistenceAdapter - Checkpoint done. Is this error due to the insufficient support of "exclusive file locks" by Windows. The above looks like a bug. I'm guessing you've used a fairly old snapshot of 4.2, I'd recommend using a recent one from the end of March 2007 which no longer uses activeio AFAIK. http://people.apache.org/repo/m2-snapshot-repository/org/apache/activemq/apache-activemq/4.2-SNAPSHOT/ -- James --- http://radio.weblogs.com/0112098/
