Mailing-List: contact dev-help@directory.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Apache Directory Developers List" <dev@directory.apache.org>
Received-SPF: pass (athena.apache.org: domain of elecharny@gmail.com
 designates 74.125.82.44 as permitted sender)
Message-ID: <4E42A6F1.6060709@gmail.com>
Date: Wed, 10 Aug 2011 17:42:41 +0200
From: Emmanuel Lecharny <elecharny@gmail.com>
Reply-To: elecharny@apache.org
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6;
 rv:5.0) Gecko/20110624 Thunderbird/5.0
MIME-Version: 1.0
To: Apache Directory Developers List <dev@directory.apache.org>
Subject: Replication & activeMQ
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit

Hi guys,

currently, we are using ActiveMQ to store the modifications we send to 
the client. This leads to an issue caused by the way we have configured 
it, simply because all the mods are stored in memory, and never removed.

Obviously, this is bad.

Thinking about it, my opinion is that it's may be a bit overkilling 
considering our need :
- when a mod is made on the provider, it has to be sent to the consumer
- in any case, we store the mod in a file associated with the consumer
- we send the mod to the consumer unless we *know* that the consumer is 
offline
- we will have no way to be sure that the consumer has correctly 
received the mod
- when a consumer gets online again, it will send a cookie with the last 
CSN it received
- in this case, we have to get all the mods from the file, and send the 
mods to the consumer.

Now, we already are saving the mods in a file, in the 
JournalInterceptor. We just have to implement the recovery system (ie, 
finding the last entry sent from the file) and send all the following 
entries. Then we can delete all the entries older than the requested one.

I don't think that using our own implementation would be an issue here. 
I mean, ActiveMQ is a great piece of software, but having to go through 
tends of options (hundreds?), most of which are totally useless in our 
case, is a bit overkilling for this version.

thoughts ?

-- 
Regards,
Cordialement,
Emmanuel Lécharny
www.iktek.com