cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Geoff Howard <geoff.how...@gmail.com>
Subject Re: event aware object cache?
Date Wed, 23 Nov 2005 17:35:14 GMT
On 11/23/05, Max Pfingsthorn <m.pfingsthorn@hippo.nl> wrote:
>
>
> Geoff Howard [mailto:geoff.howard@gmail.com] wrote:
> ...
> > > > Would it be sufficient to configure JMSEventMessageListener with a
> > > > list of EventAwares?  If the EAManager is necessary, I
> > guess it would
> > > > have to be configured with such a list unless you can
> > think of a way
> > > > for it to discover all EventAwares in the system?
> > >
> > > Well, I was thinking of registering event awares with that
> > manager so its more up to the components... Then again, if
> > you have multiple jms providers, you might want to listen to
> > a specific topic, or only forward events to a subset of EAs...
> > > Its hard to do this kind of thing with lookup IoC.
> > > Also, its a tradeoff between configuring the connections
> > between source and sink of the events (e.g. the path between
> > the jms listener and the cache) as roles to look up or as
> > some sort of routing configuration.
> > > We could do this by:
> > > 1. Letting event awares choose sources/topics to listen to
> > > 2. Configuring a name per event source
> > >
> > > Then, a listener can say, I want to listen to topic "foo",
> > no matter where from, or even listen to "bar" only from
> > source "baz" and "bas".
> > >
> > > WDYT?
> >
> > Yes, that sounds about right though I haven't fully thought
> > it through.
>
> Okay. What about routing tables? Like the one shown under "Internet Routing - Internal
Routing Tables" in [1], we could make a list of "routing rules":
>
> Source | Topic | Listener
> -------------------------
> foo    | bar   | baz     << means topic bar from source foo should be delivered
to listerner baz
> *      | barr  | baz     << baz should also get any message with topic barr from
any source
> foo    | *     | foolist << foolist listens to any topic from source foo
> foo    | bing  | *       << foo distributes any "bing" message to any listener
> foobar | *     | *       << foobar distributes any message to any listener
> *      | bang  | *       << bang messages are always delivered to all listeners
from any source
> *      | *     | bazz    << bazz listens to any message

Gotcha.  If you have a need for this now, great - seems like maybe
YAGNI would apply otherwise.

> Now, this table can be configured for the EventAwareManager in cocoon.xconf. I would
also add methods such that listeners can add/remove rules, or have some way to do this during
runtime in any case. Maybe with an interface using cforms? :D
>
> Covers all cases, right?
> > > ...
> > > > > Another usecase in favor of having a general
> > > > EventAwareManager to keep track of EventAware instances would
> > > > be to have a way to notify a business object model when the
> > > > backend changes, or generally notify it via JMS. We'll be
> > > > running into that soon over here, so it would be nice to get
> > > > some ground work done.
> > > >
> > > > That is outside the original intention but should work.
> > There may be
> > > > some odd block dependencies if someone wants to do that
> > but not use an
> > > > EventAwareCache, they could wind up requiring both the
> > JMS block and
> > > > the EventAware block anyway.  If you can see a way to allow your
> > > > use-case but avoid that false dependency, that'd be great.
> > >
> > > I don't really see that problem as you still have to
> > configure which cache to use in your cocoon.xconf. Otherwise,
> > if you want to use jms/eventaware, of course you need both
> > blocks... I don't really understand the false dependency, can
> > you explain?
> >
> > I thought I had remembered that the EventAware interfaces and
> > implementations were all in the two blocks, but now that I think of
> > it, I guess EventAware itself is in core?  I just switched to a new
> > laptop recently and don't even have a local copy of the source on it
> > yet.
>
> EventAware, EventAwareCacheImpl, EventRegistry, JMSEventMessageListener, etc are all
in the eventcache block. JMSEventMessageListener extends AbstractMessageListener from the
jms block.

Ah, right (memory's not as bad as I thought).  So if you wanted a more
generic implementation of an EventAware component that wasn't a Cache
or Store, you'd still have to rely on the "eventaware" cache block,
and probably would have a event-based cache set up in your .xconf
though you may not need it.  No biggie for now.

> I just don't see how you can use the eventcache or "eventaware" block without needing
the jms block... at least right now.

Well, the eventcache block works now without JMS.  You can have
http-based events (the sample does this).  Before my work on this
there was (and maybe still is) a commercial cocoon add-on which did
something similar using database triggers in Oracle to access URLs to
do just this - without JMS.  Can't remember the name at the moment.

Also, at the time I was also working on a filesytem listener to listen
to OS-specific events at the file system level to let you do your
uncaching automatically only when files were updated, without polling.
 IIRC, Windows, Linuxes, and Solaris all supported the basic plumbing
to allow this to happen with some native code.  So that would just
need eventcache block without JMS.

> Maybe we can factor out an interface for a generic "EventSource" which associates with
the "EventAwareManager" (or maybe "EventMultiplexer"?) to deliver events? Then the jms block
can provide a jms implementation of it (the JMSEventMessageListener) and there you go, blocks
decoupled! :)
>
> WDYT?

That might be necessary, but I'd suggest leaving it be for now.

> > Anyway, it's almost certainly not important to consider at the moment.
>
> Okay.
>
> Am I ready to roll, then?
>
> max

I'd say so!

Geoff

Mime
View raw message