Return-Path: Delivered-To: apmail-jakarta-lucene-dev-archive@apache.org Received: (qmail 63357 invoked from network); 17 Feb 2003 22:31:33 -0000 Received: from exchange.sun.com (192.18.33.10) by daedalus.apache.org with SMTP; 17 Feb 2003 22:31:33 -0000 Received: (qmail 15265 invoked by uid 97); 17 Feb 2003 22:33:11 -0000 Delivered-To: qmlist-jakarta-archive-lucene-dev@nagoya.betaversion.org Received: (qmail 15258 invoked from network); 17 Feb 2003 22:33:11 -0000 Received: from daedalus.apache.org (HELO apache.org) (208.185.179.12) by nagoya.betaversion.org with SMTP; 17 Feb 2003 22:33:11 -0000 Received: (qmail 61715 invoked by uid 500); 17 Feb 2003 22:31:12 -0000 Mailing-List: contact lucene-dev-help@jakarta.apache.org; run by ezmlm Precedence: bulk List-Unsubscribe: List-Subscribe: List-Help: List-Post: List-Id: "Lucene Developers List" Reply-To: "Lucene Developers List" Delivered-To: mailing list lucene-dev@jakarta.apache.org Received: (qmail 61660 invoked from network); 17 Feb 2003 22:31:11 -0000 Received: from pimout4-ext.prodigy.net (207.115.63.103) by daedalus.apache.org with SMTP; 17 Feb 2003 22:31:11 -0000 Received: from simpledesign.com (adsl-67-116-155-178.dsl.snfc21.pacbell.net [67.116.155.178]) by pimout4-ext.prodigy.net (8.12.3 da nor stuldap/8.12.3) with ESMTP id h1HMVGUW335220; Mon, 17 Feb 2003 17:31:16 -0500 Date: Mon, 17 Feb 2003 14:32:44 -0800 Subject: [LARM] using SEDA, pros and cons Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v551) Cc: Avalon users To: lucene-dev@jakarta.apache.org From: David Worms Content-Transfer-Encoding: 7bit Message-Id: X-Mailer: Apple Mail (2.551) X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N In order to move our project to the next level, it has been discussed the use of an SEDA architecture. With the help of the Excalibur / Event library, I created a simplified version of Larm which use SEDA as its backbone architecture. The goal was not to make it pretty or even working, but to see how each application components could feet in an event stage architecture. The great thing I notice is how flexible the application become. it is extremely easy to map each stage with the others. One of the features of LARM is the ability to have different sources( db, web, filesystem, ... ), process them, and store them (lucene index, log, ...). This seems easily achieveable with SEDA. Also clustering the LARM could be done through a specific stage implementation. This was for the pros. However, it will be great to get some feedback because I am really not sure on how to deal with SEDA. here is some problems I am facing. - In order for the crawler to be efficient, I had to raise the number of threads, but from what I read in the past, only one or two threads should be used in a SEDA environment. - Also, it looks to consume a lot of memory, which could be due to the number of messages put into the queue. Clemens, and others, please have a look of it, and give me some feedback. http://67.116.155.180/~wdavidw/stage.zip David. --------------------------------------------------------------------- To unsubscribe, e-mail: lucene-dev-unsubscribe@jakarta.apache.org For additional commands, e-mail: lucene-dev-help@jakarta.apache.org