No, they each have their own (configurable) node name. I'm attaching
my repository.xml file for you. Thanks for the help, it's greatly
appreciated.
-warner
<?xml version="1.0" encoding="ISO-8859-1"?>
<!--
Licensed to the Apache Software Foundation (ASF) under one or more
contributor license agreements. See the NOTICE file distributed with
this work for additional information regarding copyright ownership.
The ASF licenses this file to You under the Apache License, Version 2.0
(the "License"); you may not use this file except in compliance with
the License. You may obtain a copy of the License at
http://www.apache.org/licenses/LICENSE-2.0
Unless required by applicable law or agreed to in writing, software
distributed under the License is distributed on an "AS IS" BASIS,
WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
See the License for the specific language governing permissions and
limitations under the License.
-->
<!DOCTYPE Repository PUBLIC "-//The Apache Software Foundation//DTD Jackrabbit 1.4//EN"
"http://jackrabbit.apache.org/dtd/repository-1.4.dtd";>
<!-- Example Repository Configuration File -->
<Repository>
<Cluster id="${webDAV.clusterNode}">
<Journal class="org.apache.jackrabbit.core.journal.OracleDatabaseJournal">
<param name="revision" value="${rep.home}/revision.log" />
<param name="driver" value="${oracle.driver}"/>
<param name="url" value="${oracle.url}" />
<param name="user" value="${webDAV.oracle.userName}"/>
<param name="password" value="${webDAV.oracle.password}"/>
</Journal>
</Cluster>
<!--
virtual file system where the repository stores global state
(e.g. registered namespaces, custom node types, etc.)
-->
<FileSystem class="org.apache.jackrabbit.core.fs.local.LocalFileSystem">
<param name="path" value="${rep.home}/repository"/>
</FileSystem>
<!--
security configuration
-->
<Security appName="Jackrabbit">
<!--
access manager:
class: FQN of class implementing the AccessManager interface
-->
<AccessManager class="###"/>
<LoginModule class="###"/>
</Security>
<!--
location of workspaces root directory and name of default workspace
-->
<Workspaces rootPath="${rep.home}/workspaces" defaultWorkspace="default"/>
<!--
workspace configuration template:
used to create the initial workspace if there's no workspace yet
-->
<Workspace name="${wsp.name}">
<!--
virtual file system of the workspace:
class: FQN of class implementing the FileSystem interface
-->
<FileSystem class="org.apache.jackrabbit.core.fs.local.LocalFileSystem">
<param name="path" value="${wsp.home}"/>
</FileSystem>
<!--
persistence manager of the workspace:
class: FQN of class implementing the PersistenceManager interface
-->
<PersistenceManager class="org.apache.jackrabbit.core.persistence.bundle.DerbyPersistenceManager">
<param name="url" value="jdbc:derby:${wsp.home}/db;create=true"/>
<param name="schemaObjectPrefix" value="${wsp.name}_"/>
</PersistenceManager>
<!--
Search index and the file system it uses.
class: FQN of class implementing the QueryHandler interface
If required by the QueryHandler implementation, one may configure
a FileSystem that the handler may use.
Supported parameters for lucene search index:
- path: location of the index. This parameter is mandatory!
- useCompoundFile: advises lucene to use compound files for the index files
- minMergeDocs: minimum number of nodes in an index until segments are merged
- volatileIdleTime: idle time in seconds until the volatile index is
moved to persistent index even though minMergeDocs is not reached.
- maxMergeDocs: maximum number of nodes in segments that will be merged
Default value: Integer.MAX_VALUE
- mergeFactor: determines how often segment indices are merged
- maxFieldLength: the number of words that are fulltext indexed at most per property.
- bufferSize: maximum number of documents that are held in a pending
queue until added to the index
- cacheSize: size of the document number cache. This cache maps
uuids to lucene document numbers
- forceConsistencyCheck: runs a consistency check on every startup. If
false, a consistency check is only performed when the search index
detects a prior forced shutdown. This parameter only has an effect
if 'enableConsistencyCheck' is set to 'true'.
- enableConsistencyCheck: if set to 'true' a consistency check is
performed depending on the parameter 'forceConsistencyCheck'. If
set to 'false' no consistency check is performed on startup, even
if a redo log had been applied.
- autoRepair: errors detected by a consistency check are automatically
repaired. If false, errors are only written to the log.
- analyzer: class name of a lucene analyzer to use for fulltext indexing of text.
- queryClass: class name that implements the javax.jcr.query.Query interface.
this class must extend the class: org.apache.jackrabbit.core.query.AbstractQueryImpl
- respectDocumentOrder: If true and the query does not contain an 'order by' clause,
result nodes will be in document order. For better performance when queries return
a lot of nodes set to 'false'.
- resultFetchSize: The number of results the query handler should
initially fetch when a query is executed.
Default value: Integer.MAX_VALUE (-> all)
- extractorPoolSize: defines the maximum number of background threads that are
used to extract text from binary properties. If set to zero (default) no
background threads are allocated and text extractors run in the current thread.
- extractorTimeout: a text extractor is executed using a background thread if it
doesn't finish within this timeout defined in milliseconds. This parameter has
no effect if extractorPoolSize is zero.
- extractorBackLogSize: the size of the extractor pool back log. If all threads in
the pool are busy, incomming work is put into a wait queue. If the wait queue
reaches the back log size incomming extractor work will not be queued anymore
but will be executed with the current thread.
- synonymProviderClass: the name of a class that implements
org.apache.jackrabbit.core.query.lucene.SynonymProvider. The
default value is null (-> not set).
- synonymProviderConfigPath: the path to the synonym provider configuration file.
This path interpreted relative to the path parameter. If there is a FileSystem
element inside the SearchIndex element, then this path is interpreted relative
to the root path of the FileSystem. Whether this parameter is mandatory depends
on the synonym provider implementation.
The default value is null (-> not set).
Note: all parameters (except path) in this SearchIndex config are default
values and can be omitted.
-->
<SearchIndex class="org.apache.jackrabbit.core.query.lucene.SearchIndex">
<param name="path" value="${wsp.home}/index"/>
<param name="useCompoundFile" value="true"/>
<param name="minMergeDocs" value="100"/>
<param name="volatileIdleTime" value="3"/>
<param name="maxMergeDocs" value="2147483647"/>
<param name="mergeFactor" value="10"/>
<param name="maxFieldLength" value="10000"/>
<param name="bufferSize" value="10"/>
<param name="cacheSize" value="1000"/>
<param name="forceConsistencyCheck" value="false"/>
<param name="enableConsistencyCheck" value="false"/>
<param name="autoRepair" value="true"/>
<param name="analyzer" value="org.apache.lucene.analysis.standard.StandardAnalyzer"/>
<param name="queryClass" value="org.apache.jackrabbit.core.query.QueryImpl"/>
<param name="respectDocumentOrder" value="true"/>
<param name="resultFetchSize" value="2147483647"/>
<param name="extractorPoolSize" value="0"/>
<param name="extractorTimeout" value="100"/>
<param name="extractorBackLogSize" value="100"/>
</SearchIndex>
</Workspace>
<!--
Configures the versioning
-->
<Versioning rootPath="${rep.home}/version">
<!--
Configures the filesystem to use for versioning for the respective
persistence manager
-->
<FileSystem class="org.apache.jackrabbit.core.fs.local.LocalFileSystem">
<param name="path" value="${rep.home}/version"/>
</FileSystem>
<!--
Configures the perisistence manager to be used for persisting version state.
Please note that the current versioning implementation is based on
a 'normal' persistence manager, but this could change in future
implementations.
-->
<PersistenceManager class="org.apache.jackrabbit.core.persistence.db.OraclePersistenceManager">
<param name="url" value="${oracle.url}" />
<param name="user" value="${webDAV.oracle.userName}"/>
<param name="password" value="${webDAV.oracle.password}"/>
<param name="schemaObjectPrefix" value="version_"/>
<param name="externalBLOBs" value="false"/>
</PersistenceManager>
<!-- PersistenceManager class="org.apache.jackrabbit.core.persistence.bundle.DerbyPersistenceManager">
<param name="url" value="jdbc:derby:${rep.home}/version/db;create=true"/>
<param name="schemaObjectPrefix" value="version_"/>
</PersistenceManager-->
<!--
Configures the filesystem to use for versioning for the respective
persistence manager
-->
</Versioning>
<!--
Search index for content that is shared repository wide
(/jcr:system tree, contains mainly versions)
The same parameters are supported as in the search index configuration
inside the workspace definition element.
This element is optional. If omitted, the /jcr:system tree will not be
indexed and no results will be returned for that tree!
-->
<SearchIndex class="org.apache.jackrabbit.core.query.lucene.SearchIndex">
<param name="path" value="${rep.home}/repository/index"/>
</SearchIndex>
</Repository>
On Sep 29, 2008, at 9:41 PM, Thomas Müller wrote:
Hi,
Could you check if the cluster ids are the same on both cluster nodes?
The cluster id is supposed to be unique. If this is not the problem,
could you post both repository.xml files?
Regards,
Thomas
On Tue, Sep 30, 2008 at 12:02 AM, Warner Onstine
<[EMAIL PROTECTED]> wrote:
Wow, after a long wait, it finally showed up (after like 5 - 10
minutes or
more). Is there a config setting for this? I found the syncDelay,
but I'm
not sure if this is the issue as it does detect the change (I'm
attributing
this to the log files below) so I'm not sure what else I need to be
doing
here.
Thanks!
-warner
On Sep 29, 2008, at 2:22 PM, Warner Onstine wrote:
More weirdness, I rebooted both machines and now all the content I
pushed
up to node 2 just disappeared. Only the stuff from node 1 still
exists.
-warner
On Sep 29, 2008, at 2:13 PM, Warner Onstine wrote:
I really am not sure what is going on here as things appear to be
working
(according to the logs), but unfortunately I can't see stuff from
one node
to a different node.
I have two machines setup, each with their own nodes. They are both
connecting to the same db, and when I fired up the second node
everything
seemed fine as the second node synced up with the first one.
I then decided to mount this node (2) (I'm using WebDAV for my
interface
so I'm mounting it that way). I pushed up some new files and in
the log
files of both nodes I can see them syncing with each other.
Node 2:
2008-09-29 17:03:18,200 INFO [ClusterNode] Appended revision: 1918
2008-09-29 17:03:18,592 INFO [ClusterNode] Appended revision: 1919
2008-09-29 17:03:18,939 INFO [ClusterNode] Appended revision: 1920
2008-09-29 17:03:23,230 INFO [ClusterNode] Appended revision: 1923
2008-09-29 17:03:23,681 INFO [ClusterNode] Appended revision: 1924
2008-09-29 17:03:24,017 INFO [ClusterNode] Appended revision: 1925
Node 1:
2008-09-29 17:03:22,464 INFO [AbstractJournal] Record with
revision
'1917' created by this journal, skipped.
2008-09-29 17:03:22,464 INFO [AbstractJournal] Record with
revision
'1918' created by this journal, skipped.
2008-09-29 17:03:22,464 INFO [AbstractJournal] Record with
revision
'1919' created by this journal, skipped.
2008-09-29 17:03:22,465 INFO [AbstractJournal] Record with
revision
'1920' created by this journal, skipped.
2008-09-29 17:03:22,465 INFO [AbstractJournal] Record with
revision
'1921' created by this journal, skipped.
2008-09-29 17:03:22,466 INFO [AbstractJournal] Synchronized to
revision:
1921
2008-09-29 17:03:27,471 INFO [AbstractJournal] Record with
revision
'1922' created by this journal, skipped.
2008-09-29 17:03:27,471 INFO [AbstractJournal] Record with
revision
'1923' created by this journal, skipped.
2008-09-29 17:03:27,471 INFO [AbstractJournal] Record with
revision
'1924' created by this journal, skipped.
2008-09-29 17:03:27,472 INFO [AbstractJournal] Record with
revision
'1925' created by this journal, skipped.
2008-09-29 17:03:27,472 INFO [AbstractJournal] Record with
revision
'1926' created by this journal, skipped.
2008-09-29 17:03:27,473 INFO [AbstractJournal] Synchronized to
revision:
1926
But when I look at these two nodes separately one has the new
content and
one doesn't. Curious, I added new content to node 1 and the same
behavior
comes up where I can see the new content I just put up on node 1,
but not on
node 2.
Any ideas? This seems to be very odd behavior and I'm not sure if
it has
something to do with WebDAV or not.
-warner
