Mailing-List: contact users-help@jackrabbit.apache.org; run by ezmlm
Precedence: bulk
Reply-To: users@jackrabbit.apache.org
Received-SPF: pass (herse.apache.org: domain of tobias.strasser@gmail.com
 designates 64.233.182.186 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=beta;
        h=received:message-id:date:from:reply-to:sender:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth;
        b=UnczMOUQ/721SMUTN5rammntTtHhFxfvZxsQ8VnkDGl/FC0qgOGysNiXP1cWT2RlTEzPciv1ioomkIwZOH0+2T7jNn1y1acRuctZGqCSH/hcOM2AEwJWQFXvOqesOCb9OaQ9/YdK03XznZKQp2nHLbHpgAUUhXM4wWoDjWY5i5Q=
Message-ID: <8be731880703071138j3e18df80mf5139ad1625d514c@mail.gmail.com>
Date: Wed, 7 Mar 2007 20:38:05 +0100
From: "Tobias Bocanegra" <tobias.bocanegra@day.com>
Reply-To: tobias.bocanegra@day.com
Sender: tobias.strasser@gmail.com
To: users@jackrabbit.apache.org
Subject: Re: Observation within a Cluster
In-Reply-To: <70D96B2F-0D2A-4BBA-9372-C7D130213E90@maven.net>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
References: <C8FAACB7-A244-4AB9-B758-F0363E224FDB@maven.net>
	 <66c10f230703062244w68bff852s4b5bb94964d27005@mail.gmail.com>
	 <66c10f230703062246gec9e9bfxfe957255cd2958b0@mail.gmail.com>
	 <70D96B2F-0D2A-4BBA-9372-C7D130213E90@maven.net>

hi,
from the view of the repository, the JCR observation works as
specified. it does not matter if the change was done on the 'local'
cluster node or an 'external' cluster node. an event listener that is
registered properly will be notified.

imo, managing an event queue is the task of the application. of course
this could be a pre factored utility that comes with jackrabbit (but
not as part of the core repository). the queue could consist of a
queue-node where events are added as children. the queue manager
listens on changes on that node and locks it before it removes the
event-node. the locking prevents other cluster instances from handling
the same event as well. if, on the other hand, you need a
deliver-to-all, the event node is not removed, but maybe flagged as
processed by the cluster instance. if you know the number of cluster
instances, you may also remove the node after it is processed by all
instances.

regards, toby

On 3/7/07, Noah Vihinen <nvihinen@maven.net> wrote:
> We can leverage "isExternal()" in the short-term.  Are there any
> plans in place to implement the "deliver-exactly-once"
> functionality?  Most use-cases I can think of for JCR observation
> (other than JCR implementation internals such as cluster node cache
> synchronization) would work more efficiently with the "deliver-
> exactly-once" functionality.
>
> Thanks,
> Noah
>
> On Mar 7, 2007, at 1:46 AM, Dominique Pfister wrote:
>
> > Hi again,
> >
> > Sorry, I made a mistake: of course, isExternal() returns "true" for
> > all but one cluster node, namely the active one.
> >
> > Kind regards
> > Dominique
> >
> > On 3/7/07, Dominique Pfister <dominique.pfister@day.com> wrote:
> >> Hi Noah,
> >>
> >> Jackrabbit's implementation of javax.jcr.observation.Event, namely
> >>
> >>   org.apache.jackrabbit.core.observation.EventImpl
> >>
> >> has a public method called "isExternal()" that will return "true" if
> >> your EventListener is registered in the "active" cluster node, i.e.
> >> the one making the change, and "false" for all the passive ones. May
> >> be that helps?
> >>
> >> Apart from that, it is currently not possible to register a
> >> "deliver-exactly-once" EventListener in a cluster.
> >>
> >> Kind regards
> >> Dominique
> >>
> >> On 3/6/07, Noah Vihinen <nvihinen@maven.net> wrote:
> >> > Suppose I would like to construct an EventListener that makes some
> >> > persistent change to the repository as a result of some type of
> >> node
> >> > being added.  For example, the event listener may create a new node
> >> > of a different type, or set some properties.  How do I ensure that
> >> > only one JCR server within the cluster processes the NODE_ADDED
> >> > event, so the resultant persistent change only happens once?
> >> >
> >> > Is the only solution to add logic to my event listener to determine
> >> > whether or not it should proceed with the persistent change?
> >> > Further, if this is the case, are there any plans to make event
> >> > handling more efficient in the future, so only one node in the
> >> > cluster will receive notification of a particular event?
> >> >
> >> > Thanks,
> >> > Noah
> >> >
> >>
>
>


-- 
-----------------------------------------< tobias.bocanegra@day.com >---
Tobias Bocanegra, Day Management AG, Barfuesserplatz 6, CH - 4001 Basel
T +41 61 226 98 98, F +41 61 226 98 97
-----------------------------------------------< http://www.day.com >---