So the next time the app starts up, the cnd files are not copied into memory
and not used by the repo to decipher the node types?
On Thu, Aug 21, 2008 at 8:56 AM, Stefan Guggisberg <
stefan.guggisberg@day.com> wrote:
> 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
> >
>
--
---------------------
Michael Harris
Mail Thread
