jackrabbit-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Matej Knopp" <matej.kn...@gmail.com>
Subject Re: Jackrabbit cluster and workspace creation
Date Mon, 14 Jul 2008 11:20:27 GMT
That is a very inconvenient limitation. We are using workspaces for
snapshots, publishing states and possibly for language versions. None
of these we know upfront. Workspaces give us the possibility to match
nodes with same UUID, something we wouldn't be able to do with
top-level structure. I think the usecase is quite reasonable, the only
limitation is workspace creation not being accepted on other nodes.

This seems quite arbitrary to me though. I don't think we're the only
ones depending on runtime workspace creation.

Now it is possible to get workspace creation across cluster, however
it requires me to subclass RepositoryImpl and ClusterNode which in
turn requires me to touch package protected classes and it seems quite
hacky. Is there any chance there would be at least a system property
introduced in 1.5 that would force creation of the appropriate
workspace when the workspace is first time encountered in
ClusterNode#process (or other appropriate places)?

Kind regards,
Matej Knopp

On Mon, Jul 14, 2008 at 12:22 PM, Alexander Klimetschek
<aklimets@day.com> wrote:
> Hi Matej,
> this is normal. Clustering expects the same setup on all nodes - and
> the workspaces are a part of them.
> Why do you have so many workspaces? It sounds like you might be better
> off by organizing your content model into a top-level structure inside
> one workspace. The number of workspaces should IMHO not depend on
> "input-data", like requests or content of imported data. Otherwise you
> can make your application code create all the necessary workspaces on
> startup - this is the typical way to do it.
> Regards,
> Alex
> On Sun, Jul 13, 2008 at 1:28 AM, Matej Knopp <matej.knopp@gmail.com> wrote:
>> Hi,
>> I have the following problem when running jackrabbit in clustered
>> environment. When I create workspace on cluster node A and then add a
>> node to that workspace, the proper event is sent to the journal, but
>> other cluster nodes are not able to process it because they don't have
>> the workspace.
>> I did manage to intercept the this making the other nodes create the
>> workspace (subclassing ClusterNode, peeking in the record inside
>> #consume and creating the workspace there) but is it really necessary
>> to have to go over all these hoops? Couldn't be there way (at east an
>> option) to create workspace any time a node is being added to that
>> workspace for cluster nodes that don't have the workspace yet?
>> Kind regards,
>> Matej Knopp
> --
> Alexander Klimetschek
> alexander.klimetschek@day.com

View raw message