jackrabbit-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Luke Noel-Storr <luke.noel-st...@integrate.co.uk>
Subject Re: Clustering Question
Date Wed, 06 Feb 2013 16:28:49 GMT
Hi,

I'm currently setting them in my Jetty configuration file, for development/testing.

This sets them as system properties, by calling System.setProperty() (using reflection). 
Most/all web container should allow you to set system properties in some way, and it seems
these can be referenced in the configuration.xml files.

I think you can also use the standard java -Dxx=yy syntax on the command line to set them.


Many Thanks,

Luke Noel-Storr.
----------------

Integrated Publishing Solutions Ltd.
Tel: +44 (0)1926 889199
http://www.integrate.co.uk



On 6 Feb 2013, at 14:28, Cody Burleson <cody.burleson@base22.com> wrote:

> Luke,
> 
> Where are you defining the values for those property variables? I'm
> kind of in the same boat as you right now and have had similar
> questions about cluster configuration.
> 
> Sent from my iPhone
> 
> On Feb 6, 2013, at 4:11 AM, Luke Noel-Storr
> <luke.noel-storr@integrate.co.uk> wrote:
> 
>> OK,
>> 
>> I bit more experimenting, and I think I can answer my own questions a bit:
>> 
>> I believe it is just the version and workspace FileSystem that needs to be unique
to each node, and I have discovered that environment variables can be embedded in prefixes,
so, for the version and workspace filesystem schema prefixes I have:
>> 
>> <param name="schemaObjectPrefix" value="${wsp.name}_${node.id}_"/>
>> 
>> and
>> 
>> <param name="schemaObjectPrefix" value="${wsp.name}_${node.id}_"/>
>> 
>> And, to give the nodes unique ids, but with a single repository.xml, I have:
>> 
>> <Cluster id="${node.id}">
>> 
>> Does this seem like I'm on the right track?
>> 
>> 
>> Many Thanks,
>> 
>> Luke Noel-Storr.
>> ----------------
>> 
>> Integrated Publishing Solutions Ltd.
>> Tel: +44 (0)1926 889199
>> http://www.integrate.co.uk
>> 
>> 
>> 
>> On 6 Feb 2013, at 11:03, Luke Noel-Storr <luke.noel-storr@integrate.co.uk>
wrote:
>> 
>>> Hi,
>>> 
>>> Thanks for the answers, both.
>>> 
>>> Regarding locks, from what I've read session locks won't work, but object locks
should.  Can anyone confirm this.
>>> 
>>> I think I will need to use locks as, as far as I can tell, JCR offers no means
of specifying unique keys, or of doing an atomic query+update.  The only two ways I've seen
recommended of doing this are using locks, or using single name siblings, as my "unique key"
is made of a number of fields, single name siblings seem to be an unlikely solution, unless
the name I use is some combination of all the properties and their values.
>>> 
>>> Also, regarding the FileSystem, where the clustering page in the wiki says:
>>> 
>>> 
>>>> Each cluster node needs its own (private) workspace level and version FileSystem
>>>>     (only those within the workspace and versioning configuration; the ones
in the
>>>>    repository.xml and workspace.xml file)
>>> 
>>> 
>>> Does this mean that I will not be able to use Oracle persistence for the version
table and the workspace file system, or, if I do, will each node need to use a different schema
object prefix pre-fix? (and can the node id be automatically added to the prefix, like value="${node.id}_version"?)
>>> 
>>> 
>>> Regarding using Oracle, I seem to have come across a strange bug, which I've
not yet been able to identify.  When starting up a new repository on a clean DB, you get an
error "ORA-00955: name is already used by an existing object" for every set of tables it tries
to create.  If you restart it then gets past the error, but hits it again for the next set
of tables.  This meant I needed to restart 4 times before it would run, once for the default
workspace, once for versions, and one for security, and then the final time it worked.  I'll
try and have a dig into this when I get a bit more time, but, wondered if anyone else had
experienced this.
>>> 
>>> I lost about two days to the bug, as every time I hit it I tried clearing the
database, changing some configuration, or settings, and then restarting.  It was only by chance
that I finally found that a brute force effort would finally get it running smoothly.
>>> 
>>> 
>>> Many Thanks,
>>> 
>>> Luke Noel-Storr.
>>> ----------------
>>> 
>>> Integrated Publishing Solutions Ltd.
>>> Tel: +44 (0)1926 889199
>>> http://www.integrate.co.uk
>>> 
>>> 
>>> 
>>> On 5 Feb 2013, at 22:08, Ian Boston <ieb@tfd.co.uk> wrote:
>>> 
>>>> On 5 February 2013 20:57, Jeroen Reijn <j.reijn@onehippo.com> wrote:
>>>>> On Mon, Feb 4, 2013 at 11:10 AM, Luke Noel-Storr
>>>>> <luke.noel-storr@integrate.co.uk> wrote:
>>>>>> 
>>>>>> 
>>>>>> Also, and advice on locking would be appreciated.
>>>>> 
>>>>> Sorry can't help you with this one.
>>>> 
>>>> JCR locks will work within the same JVM but will not propagate
>>>> reliably throughout a cluster since the replay of the journal  (which
>>>> is used to propagate the lock) is not synchronised with the writing of
>>>> that journal. ie cluster nodes can fall behind.
>>>> 
>>>> If you need cluster wide locks then you should probably use separate
>>>> component. Since you have Oracle in the mix, a transactional lock
>>>> within Oracle will be the easiest way of achieving this. Perhaps a
>>>> table with a sha1of the path to be locked will work, with a simple IN
>>>> query to select descendents. YMMV.
>>>> 
>>>> 
>>>> HTH
>>>> Ian
>> 


Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message