Simon Gash wrote:
I don't disagree. The idea would have been to 'wire together' all of the
'SharedItemState' caches across the cluster. Thus any author who deletes a node
will have their changes propagated throughout all the repositories as well as
to the persistence manager.
However Serge was suggesting that all of the different levels of caching within
a JackRabbit repository would also need to be replicated throughout the
cluster. My idea was to skip the other levels of caching as the greatest
benefit would be for read-only access and not the content authors (write
access).
If of course it is trivial to replicate all the different caches across a cluster then my point is invalid...
Well with OSCache it should involve a little configuration and something
along the lines of
Cache.put(Object key, Object value)
where key and value are serializable objects.
Regards,
Serge Huber.
-----Original Message-----
From: "St�phane" Croisier [mailto:[EMAIL PROTECTED]
Sent: 04 April 2005 16:45
To: [email protected]
Subject: RE: cluster and cache question
At 11:55 04/04/2005, you wrote:
I see what you mean. Which layer to cache depends on the level of
clustering you want to use. For example, I might be using a cluster so
that I can increase the number of people accessing the repository in a
read-only fashion (anonymous users). However any users changing content
would use a session running directly on a specific node in the cluster.
... and how do you warn the other nodes in the cluster when you delete a
content object on the authoring server (e.g. you delete a news)? If you want
some coherence on your publishing servers, they need to be notified
consequently in order to flush their respective caches for all deprecated
objects else these deleted objects may still be served until your next
publishing server reboot...
I know this may sound obvious but this would keep the solution simple.
I'm guessing here that the number of people actually changing content
will always be much smaller than those just using it. This will of
course depend hugely on what type of application you are using the
repository for but does happen to fit my own usage particularly well :)
Yes, but you still want that your publishing servers are coherent with your authoring server...
If you do not need "real time" coherence, you may want to set a global cache expiration
delay (let's say every 24 hours) so that your caches are automatically flushed once a while (more
easy to setup and you avoid all the communication and synchronization layer between your server
nodes).... but if you have a large content repository, you will need to "reload" every XX
hours all your content from the database which may lead to more CPU/DB/FS usage.
Cheers,
St�phane
On the other hand the rest of you might want to access a session across
a cluster, I think that would significantly increase the complexity of
the design. I'm a fan of IOC (inversion of control) wouldn't the best
solution be a pluggable design so that the JackRabbit users can provide
their own particular brand (Tangsol, OS ...) ? Who could possibly be
against a pluggable design :)
Simon
-----Original Message-----
From: Serge Huber [mailto:[EMAIL PROTECTED]
Sent: 04 April 2005 10:21
To: [email protected]
Subject: Re: cluster and cache question
While I'm not a huge expert in clustering either, but I do have a
little bit of experience with it.
Basically, all caches must be able to communicate with other nodes in
order to guarantee a coherent system. That means that the
SharedItemStateManager must use a cache that can communicate with other
nodes of the cluster, otherwise you'll run into problems.
For example : on node 1 you remove a node that is cached on node 2.
Unless the cache on node 2 is notified, you will be in an incoherent
state. I know this is basic clustering, so sorry if I'm stating the
obvious here :)
So the basic rule of thumb is : everywhere there is a cache/hashmap
that is used to keep objects a memory, there should be a way to
substitute this for a clustered-aware cache implementation.
Also, I have used OSCache for clustering implementations, and although
it is very good, I also think that it would be a shame to limit
Jackrabbit to just this implementation. For example, we might want to
let the door open for clustering commercial cache implementations such
as Tangosol (not affiliated, it's just an example :)). JCS (at Apache),
also has some support for clustering, and there are others out there.
In case other cluster communication systems are needed, it might be
interesting to evaluate JGroups
(http://www.jgroups.org/javagroupsnew/docs/index.html) or JMS. JGroups
is already integrated with Tomcat, JBoss and others.
Regards,
Serge Huber.
ps : I'd be willing to help on this of course, as it is something I am
also very interested in.
Simon Gash wrote:
Guess there's no reason why the rest of us JackRabbit fans can't chew
over a few design ideas around clustering ;)
I was thinking how the 'observer' pattern could be used. Each node of
the cluster could have its own JackRabbit repository. The
SharedItemState Manager for each node would register with other nodes
in the cluster. Whenever an item is changed this is simply broadcast
to
any other repositories that are listening.
There would also need to be a way of dealing with Sessions, unless
you implement the 'sticky' session stuff (Session always returning to
the same node in the cluster).
Anyone else got any ideas...
-----Original Message-----
From: Stefan Guggisberg [mailto:[EMAIL PROTECTED]
Sent: 03 April 2005 12:21
To: [email protected]
Subject: Re: cluster and cache question
hi edgar,
regarding clustering:
clustering is a very interesting topic and we had quite a few
discussions on how it could be supported in jackrabbit.
is there an archive of this?
unfortunately not, those have been only verbal discussions during
coffe
breaks so far.
clustering can IMO not be
entirely delegated to the PM. it has to be tackled on a higher
level.
the sticking point is how to synchronize the multiple jackrabbit
instances in a cluster.
Have you seen the oscache approach for clustering? it seems
interesting.
i didn't know oscache before, it looks interesting. thanks for the
pointer.
I'm just thinking out loud, Local and Shared ItemStateManagers could
favor composition over inheritance. The current ItemStateCache
implementation is a good fit for the first, and an oscache like
approach could be a good choice for the latter in a clustering
scenario.
Maybe this could be a deployment decision, with a "shared-cache" tag
in the config file that leaves to the deployer the cache strategy
selection for shared ItemStates.
A pluggable cache for shared item states would also be useful for
network deployments with or without clustering. Those who chose a
rdbms backend would be able to to use a cache that relies also in
the local filesystem, and not only in mem.
as you might have noticed i am not a huge fan of 'pluggable' core
components ;) but i agree with you that tackling clustering on the
shared ItemState cache level would be certainly worth thinking about
more.
but as i said, i think it's a bit too early to address something as
complex and advanced as clustering at this stage.
Sorry for being such a pain, I'm becoming a jackrabbit fun and I'd
like to use it on any project I get involved.
great to hear that! ...and don't worry about being a pain ;) your
feedback and your suggestions, although we might not always be
sharing the same position, are very much appreciated.
at the very least it forces us to explain and justify design
decisions that we've taken. on the other hand it might also lead us
to reconsider
certain designs.
cheers
stefan
thanks
edgar
This email contains proprietary information, some or all of which may
be legally privileged. It is for the intended recipient only. If an
addressing or transmission error has misdirected this email, please
notify the author by replying to this email. If you are not the
intended recipient you may not use, disclose, distribute, copy, print
or rely on this email.
Email transmission cannot be guaranteed to be secure or error free,
as
information may be intercepted, corrupted, lost, destroyed, arrive late
or incomplete or contain viruses. This email and any files attached to
it have been checked with virus detection software before transmission.
You should nonetheless carry out your own virus check before opening
any attachment. GOSS Interactive Ltd accepts no liability for any loss
or damage that may be caused by software viruses.
GOSS - Ranked 4th in the Deloitte Technology Fast 50 Awards 2004 and
88th in the Deloitte Technology Fast 500 EMEA.
This email contains proprietary information, some or all of which may
be legally privileged. It is for the intended recipient only. If an
addressing or transmission error has misdirected this email, please
notify the author by replying to this email. If you are not the
intended recipient you may not use, disclose, distribute, copy, print
or rely on this email.
Email transmission cannot be guaranteed to be secure or error free, as
information may be intercepted, corrupted, lost, destroyed, arrive late
or incomplete or contain viruses. This email and any files attached to
it have been checked with virus detection software before transmission.
You should nonetheless carry out your own virus check before opening
any attachment. GOSS Interactive Ltd accepts no liability for any loss
or damage that may be caused by software viruses.
GOSS - Ranked 4th in the Deloitte Technology Fast 50 Awards 2004 and
88th in the Deloitte Technology Fast 500 EMEA.
- -- --- -----=[ scroisier2 at jahia dot com ]=---- --- -- - www.jahia.org : The Open Unified Web Platform
This email contains proprietary information, some or all of which may be legally privileged. It is for the intended recipient only. If an addressing or transmission error has misdirected this email, please notify the author by replying to this email. If you are not the intended recipient you may not use, disclose, distribute, copy, print or rely on this email.
Email transmission cannot be guaranteed to be secure or error free, as
information may be intercepted, corrupted, lost, destroyed, arrive late or
incomplete or contain viruses. This email and any files attached to it have
been checked with virus detection software before transmission. You should
nonetheless carry out your own virus check before opening any attachment. GOSS
Interactive Ltd accepts no liability for any loss or damage that may be caused
by software viruses.
GOSS - Ranked 4th in the Deloitte Technology Fast 50 Awards 2004 and 88th in
the Deloitte Technology Fast 500 EMEA.
