jackrabbit-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Stefan Guggisberg" <stefan.guggisb...@day.com>
Subject Re: is this a valid configuration? somewhat urgent...
Date Thu, 21 Aug 2008 12:56:27 GMT
On Thu, Aug 21, 2008 at 2:46 PM, Michael Harris
<michael.e.harris@gmail.com> wrote:
> would there be any way to recover in that situation?

no. the node type defintions would be gone. as i said, MemoryFileSystem
is not meant for production use. the only legitimate use is IMO for testing.

cheers
stefan

>
> On Thu, Aug 21, 2008 at 8:22 AM, Stefan Guggisberg <
> stefan.guggisberg@day.com> wrote:
>
>> On Thu, Aug 21, 2008 at 1:58 PM, Michael Harris
>> <michael.e.harris@gmail.com> wrote:
>> > Indeed that is not what I want.  Ok should we go with the default derby
>> fs
>> > or the local file system....
>>
>> it depends on your requirements. the default config uses the local file
>> system.
>>
>> >
>> > also, when you say "not being persisted" at what scope do you mean?  i
>> would
>> > assume with a mem fs that everytime a transientrepo is started the
>> necessary
>> > stuf (.cnd files, etc) is put in memory....
>>
>> say you startet a transient repo using the before mentioned config.
>> you then register custom node types and namespaces.
>> finally yoy create new nodes using your new node types & namespaces.
>> everything's fine so far.
>>
>> ...but....
>>
>> if you restart your repo, the custom node types and namespaces are gone
>> and your repository content is corrupted since it references non-existing
>> node types and namespaces...
>>
>> cheers
>> stefan
>>
>> >
>> >
>> > On 8/21/08, Stefan Guggisberg <stefan.guggisberg@day.com> wrote:
>> >>
>> >> On Wed, Aug 20, 2008 at 11:16 PM, Michael Harris
>> >> <michael.e.harris@gmail.com> wrote:
>> >> > I was wondering if this is a valid configuration
>> >> >
>> >> > <Repository>
>> >> >    <!--FileSystem
>> >> > class="org.apache.jackrabbit.core.fs.mem.MemoryFileSystem"/-->
>> >> >    <FileSystem
>> >> class="org.apache.jackrabbit.core.fs.mem.MemoryFileSystem">
>> >> >    </FileSystem>
>> >> >    <Security appName="Jackrabbit">
>> >> >        <AccessManager
>> >>
>> >> >
>>  class="org.apache.jackrabbit.core.security.SimpleAccessManager"
>> >> >            />
>> >> >        <LoginModule
>> >> >
>>  class="org.apache.jackrabbit.core.security.SimpleLoginModule"
>> >> />
>> >> >    </Security>
>> >> >    <Workspaces rootPath="${rep.home}/workspaces"
>> >> >        defaultWorkspace="default" />
>> >> >    <Workspace name="${wsp.name}">
>> >> >        <FileSystem
>> >> > class="org.apache.jackrabbit.core.fs.mem.MemoryFileSystem">
>> >> >        </FileSystem>
>> >> >        <PersistenceManager
>> >> >
>> >>
>> class="org.apache.jackrabbit.core.persistence.db.OraclePersistenceManager">
>> >> >            <param name="url" value="@oracle.jdbc.url@"/>
>> >> >            <param name="user" value="@oracle.jdbc.username@"/>
>> >> >            <param name="password" value="@oracle.jdbc.password@"/>
>> >> >            <param name="schemaObjectPrefix" value="${wsp.name}_"/>
>> >> >            <param name="externalBLOBs" value="false"/>
>> >> >        </PersistenceManager>
>> >> >    </Workspace>
>> >> >    <Versioning rootPath="${rep.home}/versions">
>> >> >        <FileSystem
>> >> > class="org.apache.jackrabbit.core.fs.mem.MemoryFileSystem">
>> >> >        </FileSystem>
>> >> >        <PersistenceManager
>> >> >
>> >>
>> class="org.apache.jackrabbit.core.persistence.db.OraclePersistenceManager">
>> >> >            <param name="url" value="@oracle.jdbc.url@"/>
>> >> >            <param name="user" value="@oracle.jdbc.username@"/>
>> >> >            <param name="password" value="@oracle.jdbc.password@"/>
>> >> >            <param name="externalBLOBs" value="false"/>
>> >> >        </PersistenceManager>
>> >> >    </Versioning>
>> >> > </Repository>
>> >> >
>> >> > we are seeing some extremely wierd behavior.  Basically DAO tests will
>> >> run
>> >> > fine for an hour or two and then all of a sudden they stop
>> >> working.  There
>> >> > cause is unknown,
>> >> > but we know for sure that it is not a connectivity issue (no cannot
>> >> connect
>> >> > errors) and it is unlikely that it is a db issue (other apps are using
>> >> the
>> >> > db just fine).  There are no exceptions being thrown -- the dao will
>> >> create
>> >> > a node and then the test looks for it an it isnt there.  The only way
>> I
>> >> can
>> >> > recover is to drop all the tables JR created -- then the tests will
>> work
>> >> > fine for a few hours and just start failing again.
>> >> >
>> >> > The only thing
>> >> > i can think of is a configuration issue.
>> >> >
>> >> > So as you can see running the filesystems in memory and using oracle
>> >> based
>> >>
>> >> why are you using MemoryFileSystem? it's not meant for production use
>> (see
>> >> javadoc). using MemoryFileSystem as the top-level repository fs causes
>> >> custom node types, namespaces etc not being persisted. i assume that's
>> >> not what you want.
>> >>
>> >> cheers
>> >> stefan
>> >>
>> >> > persistence managers.  The @value@ tokens get replaced in a build so
>> >> there
>> >> > are actual values there for the copy on the classpath.
>> >> > There is a custom node definition in a cnd file.
>> >> >
>> >> >
>> >> >
>> >> >
>> >> >
>> >> >
>> >> > --
>> >> > ---------------------
>> >> > Michael Harris
>> >> >
>> >>
>> >
>> >
>> >
>> > --
>> > ---------------------
>> > Michael Harris
>> >
>>
>
>
>
> --
> ---------------------
> Michael Harris
>

Mime
View raw message