You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@jackrabbit.apache.org by Costin Leau <co...@gmail.com> on 2006/01/16 11:05:29 UTC
workspace already exists
Hello,
After I have updated to rev 367534 (10.01.2006) I keep receiving these
errors between redeploys:
org.apache.jackrabbit.core.config.ConfigurationException: Workspace directory already exists: default
at org.apache.jackrabbit.core.config.RepositoryConfig.createWorkspaceConfig(RepositoryConfig.java:454)
at org.apache.jackrabbit.core.config.RepositoryConfig.init(RepositoryConfig.java:317)
at org.apache.jackrabbit.core.config.RepositoryConfig.create(RepositoryConfig.java:137)
Is there any way to tell jr to use the workspace - the only solution I
could find is to delete the directory and restart the application.
Since I can reuse the information it would be nice to have a flag to
tell jackrabbit to do that force me.
--
Best regards,
Costin Leau mailto:costin.leau@gmail.com
Re: workspace already exists
Posted by Martin Perez <mp...@gmail.com>.
Sorry for the question if it's trivial, because I haven't got time yet to
update my PM to Derby one, but, how can I enable transactions? Is it
documented? If it's document feel free to send me a RTFM response :)
Martin.
On 1/18/06, Brian Moseley <bc...@osafoundation.org> wrote:
>
> On 1/18/06, Marcel Reutegger <ma...@gmx.net> wrote:
>
> > there is a wiki page that lists the properties of the different
> > persistence managers:
> >
> > http://wiki.apache.org/jackrabbit/PersistenceManagerFAQ
>
> thanks for reminding us of this page. i've seen it updated over time
> but continue to forget that it exists.
>
Re: workspace already exists
Posted by Brian Moseley <bc...@osafoundation.org>.
On 1/18/06, Marcel Reutegger <ma...@gmx.net> wrote:
> there is a wiki page that lists the properties of the different
> persistence managers:
>
> http://wiki.apache.org/jackrabbit/PersistenceManagerFAQ
thanks for reminding us of this page. i've seen it updated over time
but continue to forget that it exists.
Re: workspace already exists
Posted by Marcel Reutegger <ma...@gmx.net>.
Stefan Guggisberg wrote:
> On 1/18/06, Costin Leau <co...@gmail.com> wrote:
>>I'm using XML PM with jr transactional support. If this PM doesn't
>>support transactions shouldn't I be warned about it?
>
>
> you are right. transaction support of the various persistence managers
> is not very well documented. that's something that should be improved.
there is a wiki page that lists the properties of the different
persistence managers:
http://wiki.apache.org/jackrabbit/PersistenceManagerFAQ
regards
marcel
Re: Re[4]: workspace already exists
Posted by Stefan Guggisberg <st...@gmail.com>.
On 1/18/06, Costin Leau <co...@gmail.com> wrote:
>
> > On 1/18/06, Costin Leau <co...@gmail.com> wrote:
>
> >> Indeed - the problem appears if the server suffered a forced shutdown
> >> (think of power turned off). What can I do in these cases where the
> >> repository might be in a inconsistent state ? How can I recover my
> >> information?
>
> > if you're using a transactional pm (e.g. DerbyPersistenceManager)
> > you should be pretty safe wrt corrupted repository state after abnormal
> > process termination.
>
> > however, in your case you seem to end up with disappearing workspace.xml
> > files which is pretty weird. i have no idea how this could happen.
> > you'll have to investigate yourself i'm afraid since i don't know your
> > environment.
> I'm using XML PM with jr transactional support. If this PM doesn't
> support transactions shouldn't I be warned about it?
you are right. transaction support of the various persistence managers
is not very well documented. that's something that should be improved.
>
> Another aspect is that the problem seems to occur not during writing
> but actually because the repository internals don't flush all the
> information to disk because the VM stops too fast (tomcat is shutdown
> with -force argument).
> I'll investigate this problem further and come back if I have any questions.
ok.
cheers
stefan
>
> --
> Best regards,
> Costin mailto:costin.leau@gmail.com
>
>
Re[4]: workspace already exists
Posted by Costin Leau <co...@gmail.com>.
> On 1/18/06, Costin Leau <co...@gmail.com> wrote:
>> Indeed - the problem appears if the server suffered a forced shutdown
>> (think of power turned off). What can I do in these cases where the
>> repository might be in a inconsistent state ? How can I recover my
>> information?
> if you're using a transactional pm (e.g. DerbyPersistenceManager)
> you should be pretty safe wrt corrupted repository state after abnormal
> process termination.
> however, in your case you seem to end up with disappearing workspace.xml
> files which is pretty weird. i have no idea how this could happen.
> you'll have to investigate yourself i'm afraid since i don't know your
> environment.
I'm using XML PM with jr transactional support. If this PM doesn't
support transactions shouldn't I be warned about it?
Another aspect is that the problem seems to occur not during writing
but actually because the repository internals don't flush all the
information to disk because the VM stops too fast (tomcat is shutdown
with -force argument).
I'll investigate this problem further and come back if I have any questions.
--
Best regards,
Costin mailto:costin.leau@gmail.com
Re: workspace already exists
Posted by Alexandru Popescu <th...@gmail.com>.
#: Brian Moseley changed the world a bit at a time by saying (astral date: 1/19/2006 3:50 AM) :#
> On 1/18/06, Alexandru Popescu <th...@gmail.com> wrote:
>
>> Can you pls specify where is this setting available? (externalBlobs=true|false). I couldn't find it,
>> so sorry if it is right in front of me.
>
> it's part of the persistence manager configuration:
>
> <PersistenceManager
> class="org.apache.jackrabbit.core.state.db.DerbyPersistenceManager">
> <param name="url" value="jdbc:derby:${wsp.home}/db"/>
> <param name="schemaObjectPrefix" value="${wsp.name}_"/>
> <param name="externalBLOBs" value="true"/>
> </PersistenceManager>
>
Thanks a lot... and as I suspected right under my nose :-).
./alex
--
.w( the_mindstorm )p.
Re: workspace already exists
Posted by Brian Moseley <bc...@maz.org>.
On 1/18/06, Alexandru Popescu <th...@gmail.com> wrote:
> Can you pls specify where is this setting available? (externalBlobs=true|false). I couldn't find it,
> so sorry if it is right in front of me.
it's part of the persistence manager configuration:
<PersistenceManager
class="org.apache.jackrabbit.core.state.db.DerbyPersistenceManager">
<param name="url" value="jdbc:derby:${wsp.home}/db"/>
<param name="schemaObjectPrefix" value="${wsp.name}_"/>
<param name="externalBLOBs" value="true"/>
</PersistenceManager>
Re: workspace already exists
Posted by Alexandru Popescu <th...@gmail.com>.
#: Brian Moseley changed the world a bit at a time by saying (astral date: 1/18/2006 7:27 PM) :#
> On 1/18/06, Stefan Guggisberg <st...@gmail.com> wrote:
>
>> touché ;) you must have caught me on the wrong foot, sorry.
>
> i just woke up so i'm kinda grouchy myself. need to remember to get a
> cup of coffee before reading email :)
>
>> fair enough :) currently only SimpleDbPersistenceManager and subclasses thereof
>> do support transactions. i guess BerkeleyDBPersistenceManager in contrib does
>> also but i didn't test it.
>>
>> wrt externalBlobs=true: blobs in the file system are not stored within
>> the context
>> of a transaction, i.e. the changes in the fs wont be reverted on
>> rollback. if you do
>> need transaction support you have to specify externalBlobs=false.
>
> as i suspected. i'll probably wind up testing blobs both externally
> and db to see how different performance is. storing blobs in the db
> would certainly be more robust, as we're discussing now, and it would
> make the job of backing up the repository data easier, since we could
> stick to the dbms' provided backup tools.
>
> backup is another very interesting topic, of course, when you have
> large numbers of nodes and blobs. i'll be doing some work here in the
> next couple months and will share whatever i come up with.
>
Can you pls specify where is this setting available? (externalBlobs=true|false). I couldn't find it,
so sorry if it is right in front of me.
./alex
--
.w( the_mindstorm )p.
Re: Re[2]: workspace already exists
Posted by Brian Moseley <bc...@osafoundation.org>.
On 1/18/06, Stefan Guggisberg <st...@gmail.com> wrote:
> touché ;) you must have caught me on the wrong foot, sorry.
i just woke up so i'm kinda grouchy myself. need to remember to get a
cup of coffee before reading email :)
> fair enough :) currently only SimpleDbPersistenceManager and subclasses thereof
> do support transactions. i guess BerkeleyDBPersistenceManager in contrib does
> also but i didn't test it.
>
> wrt externalBlobs=true: blobs in the file system are not stored within
> the context
> of a transaction, i.e. the changes in the fs wont be reverted on
> rollback. if you do
> need transaction support you have to specify externalBlobs=false.
as i suspected. i'll probably wind up testing blobs both externally
and db to see how different performance is. storing blobs in the db
would certainly be more robust, as we're discussing now, and it would
make the job of backing up the repository data easier, since we could
stick to the dbms' provided backup tools.
backup is another very interesting topic, of course, when you have
large numbers of nodes and blobs. i'll be doing some work here in the
next couple months and will share whatever i come up with.
Re: Re[2]: workspace already exists
Posted by Stefan Guggisberg <st...@gmail.com>.
On 1/18/06, Brian Moseley <bc...@maz.org> wrote:
> On 1/18/06, Stefan Guggisberg <st...@gmail.com> wrote:
>
> > brian, since you're a committer i guess you know the answers to your questions.
>
> just because i have the ability to check in doesn't mean i am an
> expert on all areas of the code :) gosh, that i'm competent in any
> area of the code is in doubt! i don't recall having to take a
> qualifying exam in order to get the invitation to become a committer
> :)
touché ;) you must have caught me on the wrong foot, sorry.
>
> seriously though, i'm sure i'm not the only person who's interested in
> finding out more about jackrabbit's robustness. certainly i and every
> other person who has these questions can embark on our own independent
> research projects and hopefully come up with the right answers - or,
> more efficiently, we can ask the expert.
>
> this is certainly the type of information that would be helpful to
> have on the wiki, and i'll be happy to record it there if you do have
> something to share.
>
fair enough :) currently only SimpleDbPersistenceManager and subclasses thereof
do support transactions. i guess BerkeleyDBPersistenceManager in contrib does
also but i didn't test it.
wrt externalBlobs=true: blobs in the file system are not stored within
the context
of a transaction, i.e. the changes in the fs wont be reverted on
rollback. if you do
need transaction support you have to specify externalBlobs=false.
cheers
stefan
Re: Re[2]: workspace already exists
Posted by Brian Moseley <bc...@maz.org>.
On 1/18/06, Stefan Guggisberg <st...@gmail.com> wrote:
> brian, since you're a committer i guess you know the answers to your questions.
just because i have the ability to check in doesn't mean i am an
expert on all areas of the code :) gosh, that i'm competent in any
area of the code is in doubt! i don't recall having to take a
qualifying exam in order to get the invitation to become a committer
:)
seriously though, i'm sure i'm not the only person who's interested in
finding out more about jackrabbit's robustness. certainly i and every
other person who has these questions can embark on our own independent
research projects and hopefully come up with the right answers - or,
more efficiently, we can ask the expert.
this is certainly the type of information that would be helpful to
have on the wiki, and i'll be happy to record it there if you do have
something to share.
Re: Re[2]: workspace already exists
Posted by Stefan Guggisberg <st...@gmail.com>.
On 1/18/06, Brian Moseley <bc...@osafoundation.org> wrote:
> On 1/18/06, Stefan Guggisberg <st...@gmail.com> wrote:
>
> > if you're using a transactional pm (e.g. DerbyPersistenceManager)
> > you should be pretty safe wrt corrupted repository state after abnormal
> > process termination.
>
> are these pms transactional with regard to external blobs? in other
> words, if i'm storing an nt:file node with a 5mb file and i cut the
> power to the machine in the middle of writing the blob to disk, are
> derby and the blob fs going to be inconsistent? will jackrabbit be
> able to start up in such a state? does jackrabbit provide a tool to
> check for and repair inconsistencies?
brian, since you're a committer i guess you know the answers to your questions.
>
Re: Re[2]: workspace already exists
Posted by Brian Moseley <bc...@osafoundation.org>.
On 1/18/06, Stefan Guggisberg <st...@gmail.com> wrote:
> if you're using a transactional pm (e.g. DerbyPersistenceManager)
> you should be pretty safe wrt corrupted repository state after abnormal
> process termination.
are these pms transactional with regard to external blobs? in other
words, if i'm storing an nt:file node with a 5mb file and i cut the
power to the machine in the middle of writing the blob to disk, are
derby and the blob fs going to be inconsistent? will jackrabbit be
able to start up in such a state? does jackrabbit provide a tool to
check for and repair inconsistencies?
Re: Re[2]: workspace already exists
Posted by Stefan Guggisberg <st...@gmail.com>.
On 1/18/06, Costin Leau <co...@gmail.com> wrote:
> Indeed - the problem appears if the server suffered a forced shutdown
> (think of power turned off). What can I do in these cases where the
> repository might be in a inconsistent state ? How can I recover my
> information?
if you're using a transactional pm (e.g. DerbyPersistenceManager)
you should be pretty safe wrt corrupted repository state after abnormal
process termination.
however, in your case you seem to end up with disappearing workspace.xml
files which is pretty weird. i have no idea how this could happen.
you'll have to investigate yourself i'm afraid since i don't know your
environment.
cheer
stefan
>
> Thanks.
>
>
> --
> Best regards,
> Costin mailto:costin.leau@gmail.com
>
>
Re[2]: workspace already exists
Posted by Costin Leau <co...@gmail.com>.
Hello Stefan,
Tuesday, January 17, 2006, 5:09:22 PM, you wrote:
> hi costin
> On 1/16/06, Costin Leau <co...@gmail.com> wrote:
>> Hello,
>>
>> After I have updated to rev 367534 (10.01.2006) I keep receiving these
>> errors between redeploys:
>>
>> org.apache.jackrabbit.core.config.ConfigurationException: Workspace directory already exists: default
>> at org.apache.jackrabbit.core.config.RepositoryConfig.createWorkspaceConfig(RepositoryConfig.java:454)
>> at org.apache.jackrabbit.core.config.RepositoryConfig.init(RepositoryConfig.java:317)
>> at org.apache.jackrabbit.core.config.RepositoryConfig.create(RepositoryConfig.java:137)
>>
>> Is there any way to tell jr to use the workspace - the only solution I
>> could find is to delete the directory and restart the application.
>> Since I can reuse the information it would be nice to have a flag to
>> tell jackrabbit to do that force me.
> the following steps are performed during jr's startup process:
> - read repository config
> - ...
> - read workspace configs, i.e. scan subdirectories of the
> workspaces root directory for workspace.xml files; each
> such file configures an existing workspace
> - if the 'default' workspace doesn't exist yet, create a subdirectory
> with a corresponding workspace.xml
> - initialize the 'default' workspace
> - ...
> your problem seems to be that jr couldn't find the workspace.xml
> for the default workspace and tried to create it in a corresponding
> subdirectory. creating the subdirectory failed because there was
> an existing directory with the same name, probably a leftover from
> a previous install.
> the "Workspace directory already exists" exception is thrown intentionally
> in order to prevent accidentally overwriting existing data.
> i suggest you check your redeployment procedure and make sure
> you don't leave empty workspace directories.
Indeed - the problem appears if the server suffered a forced shutdown
(think of power turned off). What can I do in these cases where the
repository might be in a inconsistent state ? How can I recover my
information?
Thanks.
--
Best regards,
Costin mailto:costin.leau@gmail.com
Re: workspace already exists
Posted by Stefan Guggisberg <st...@gmail.com>.
hi costin
On 1/16/06, Costin Leau <co...@gmail.com> wrote:
> Hello,
>
> After I have updated to rev 367534 (10.01.2006) I keep receiving these
> errors between redeploys:
>
> org.apache.jackrabbit.core.config.ConfigurationException: Workspace directory already exists: default
> at org.apache.jackrabbit.core.config.RepositoryConfig.createWorkspaceConfig(RepositoryConfig.java:454)
> at org.apache.jackrabbit.core.config.RepositoryConfig.init(RepositoryConfig.java:317)
> at org.apache.jackrabbit.core.config.RepositoryConfig.create(RepositoryConfig.java:137)
>
> Is there any way to tell jr to use the workspace - the only solution I
> could find is to delete the directory and restart the application.
> Since I can reuse the information it would be nice to have a flag to
> tell jackrabbit to do that force me.
the following steps are performed during jr's startup process:
- read repository config
- ...
- read workspace configs, i.e. scan subdirectories of the
workspaces root directory for workspace.xml files; each
such file configures an existing workspace
- if the 'default' workspace doesn't exist yet, create a subdirectory
with a corresponding workspace.xml
- initialize the 'default' workspace
- ...
your problem seems to be that jr couldn't find the workspace.xml
for the default workspace and tried to create it in a corresponding
subdirectory. creating the subdirectory failed because there was
an existing directory with the same name, probably a leftover from
a previous install.
the "Workspace directory already exists" exception is thrown intentionally
in order to prevent accidentally overwriting existing data.
i suggest you check your redeployment procedure and make sure
you don't leave empty workspace directories.
cheers
stefan
>
>
> --
> Best regards,
> Costin Leau mailto:costin.leau@gmail.com
>
>