Re: Cleaning the database
On 5/18/07, Jim Alateras [EMAIL PROTECTED] wrote: James Strachan wrote: On 5/17/07, Jim Alateras [EMAIL PROTECTED] wrote: What is the best way to clear the database that stores persistent messages? I am using an embedded broker and the mysql database, which is shared with other applications. You can purge individual queues via JMX; or just drop recreate the database in mysql :) thanks James, can you point me a URL that describes the activemq database schema. No its created on startup. Note if you're using the journal with ActiveMQ for performance, deleting messages in the database before checkpointing could cause confusion (i.e. they may come back next checkpoint). -- James --- http://macstrac.blogspot.com/
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
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
