You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@sling.apache.org by Tony Giaccone <to...@giaccone.org> on 2010/06/17 14:32:24 UTC

Database issues..


Twice now, I've ended up having problems starting up Sling and ended up having to delete all the tables in the database, to solve the problem. 

I recognize that this is probably a jackrabbit problem and so perhaps not appropriate for this list, but given that the jackrabbit instance is part of the sling install, I'm going to start here first. 


The app was shut down, perhaps improperly, but I had to reboot my laptop. I had to delete glassfish and in doing so blasted the repository file system. 


On restart I get this message: 

16.06.2010 20:49:00.906 *ERROR* [Repository Pinger] org.apache.jackrabbit.core.RepositoryImpl Failed to initialize workspace 'default' javax.jcr.RepositoryException: Cannot instantiate persistence manager org.apache.jackrabbit.core.persistence.bundle.PostgreSQLPersistenceManager

Caused by: java.sql.SQLException: Schema generation error: Issuing statement: create table JCR_DEFAULT_REFS (NODE_ID_HI bigint not null, NODE_ID_LO bigint not null, REFS_DATA bytea not null, PRIMARY KEY (NODE_ID_HI, NODE_ID_LO))

Caused by: org.postgresql.util.PSQLException: ERROR: relation "jcr_default_refs" already exists


Now I'm only using Postgres for the Persistence manager, and not also using the DbFileSystem. Is this possibly a problem with the FileSystem being out of synch with the Persistence manager?

Is this a general tip in the direction that says, keep your file system in the database also?


Tony Giaccone

Re: Database issues..

Posted by Felix Meschberger <fm...@gmail.com>.
Hi Ton,y

On 17.06.2010 21:49, Tony Giaccone wrote:
> 
> On Jun 17, 2010, at 10:10 AM, Felix Meschberger wrote:
> 
>> sling.home
> Felix, 
> 
> 
> I'm such a literal guy.. I need a bit of hand holding..

;-)

I mean in the web.xml file, where the SlingServlet is configured, you
can define init-params. You set sling.home there, something like:

   <init-param>
       <param-name>sling.home</param-name>
       <param-value>/var/sling</param-value>
   </init-param>

This will cause everything currently below "sling" to be placed inside
/var/sling (requiring access to this filesystem location ;-) ) This
includes also the filesystem data of the repository.

Look at the web.xml file enclosed in the sling launchpad .war file. You
should see some commment and even a prepared <init-param> element for
you to start with.

Hope, this helps.

Regards
Felix

> 
> 
> do you mean that by setting this property
> 
> 
> sling.home
> 
> in 
> 
> sling/launchpad/base/src/main/resources/sling.properites
> 
> which is currently set to 
> 
> sling.home = sling
> 
> 
> to something like:
> 
> sling.home = /sling
> 
> that I would move the sling and all  the deployed directories to a different location on the file system?
> 
> 
> 
> Tony

Re: Database issues..

Posted by Tony Giaccone <tg...@masslight.net>.
On Jun 17, 2010, at 10:10 AM, Felix Meschberger wrote:

> sling.home
Felix, 


I'm such a literal guy.. I need a bit of hand holding..


do you mean that by setting this property


sling.home

in 

sling/launchpad/base/src/main/resources/sling.properites

which is currently set to 

sling.home = sling


to something like:

sling.home = /sling

that I would move the sling and all  the deployed directories to a different location on the file system?



Tony

Re: Database issues..

Posted by Felix Meschberger <fm...@gmail.com>.
Hi,

On 17.06.2010 15:59, Tony Giaccone wrote:
> Felix,
> 
> What I think is happening, and I'm not sure about this, is that the filesystem repository was deleted. So now Jackrabbit thinks it has to start up with an empty instance and it's going to try and create those tables as part of the "instantiate the repository". 

Not, sure. Looking at the code it looks like the persistence manager (as
I said) looks for one of the expected tables to exist. If so, the
manager expects all to exist. If that single table does not exist, the
persistencemanager assumes all to not exist.

> 
> I solved the problem by deleting the tables and sequences and letting Jackrabbit create a blank new instance.  That solves the problem for now. 

Ok, this helps for now, but ... the question remains, why tables are
incomplete. Have you looked at the PostgreSQL instance using something
like pgAdmin ?

> 
> I was able to start stop and restart the instance of sling/jackrabbit/postgres many times before I had a problem. 
> 
> I'm playing a bit lose with this as I'm trying to switch between jackrabbit using postgress and jackrabbit using oracle. 
> 
> I'm not keen on the file repository being in the same space as the web server
> 
> To solve this problem in part, I think I need to move the repository out from under the application server (glassfish) and into a file space
> that won't be disturbed as I do new installs of glassfish, sling and jackrabbit. 
> 
> . So I made this change:
> 
>     <FileSystem class="org.apache.jackrabbit.core.fs.local.LocalFileSystem">
>         <!-- <param name="path" value="${rep.home}/repository"/> -->
>         <param name="path" value="/jackrabbit/repository/postgres/"/>
>     </FileSystem>
> 
> I believe that should move the file repository out of the file system controlled by the application server.
> 
> That way I can have one filesystem that's set up for oracle, and another for postgres, and not have any problem with documents inconsistencies between the two repositories. 
> 
> Does this approach seem reasonable?

I think it is reasonable to move stuff out from the web server area. But
I suggest to move the complete Sling instance data out of that area by
setting the sling.home init-param of the Sling servlet to some other
location.

Regards
Felix

> 
> 
> Tony
> 
> 
> On Jun 17, 2010, at 9:31 AM, Felix Meschberger wrote:
> 
>> Hi Tony,
>>
>> On 17.06.2010 14:32, Tony Giaccone wrote:
>>>
>>>
>>> Twice now, I've ended up having problems starting up Sling and ended up having to delete all the tables in the database, to solve the problem. 
>>>
>>> I recognize that this is probably a jackrabbit problem and so perhaps not appropriate for this list, but given that the jackrabbit instance is part of the sling install, I'm going to start here first. 
>>>
>>>
>>> The app was shut down, perhaps improperly, but I had to reboot my laptop. I had to delete glassfish and in doing so blasted the repository file system. 
>>>
>>>
>>> On restart I get this message: 
>>>
>>> 16.06.2010 20:49:00.906 *ERROR* [Repository Pinger] org.apache.jackrabbit.core.RepositoryImpl Failed to initialize workspace 'default' javax.jcr.RepositoryException: Cannot instantiate persistence manager org.apache.jackrabbit.core.persistence.bundle.PostgreSQLPersistenceManager
>>>
>>> Caused by: java.sql.SQLException: Schema generation error: Issuing statement: create table JCR_DEFAULT_REFS (NODE_ID_HI bigint not null, NODE_ID_LO bigint not null, REFS_DATA bytea not null, PRIMARY KEY (NODE_ID_HI, NODE_ID_LO))
>>>
>>> Caused by: org.postgresql.util.PSQLException: ERROR: relation "jcr_default_refs" already exists
>>>
>>>
>>> Now I'm only using Postgres for the Persistence manager, and not also using the DbFileSystem. Is this possibly a problem with the FileSystem being out of synch with the Persistence manager?
>>>
>>> Is this a general tip in the direction that says, keep your file system in the database also?
>>
>> I have also setup a Sling instance with PostgresSQL without switching to
>> DbFileSystem. And until now, I had no issues whatsoever.
>>
>> It looks like the persistence manager cannot find the jcr_default_bundle
>> table and thus decides to create all tables for the "default" workspace.
>>
>> This then fails, because the jcr_default_refs table (?) seems to
>> still/already exist.
>>
>> It sure looks strange, that the jcr_default_bundle table is missing, but
>> the jcr_default_refs table exists.
>>
>> What tables exist at all ? In my instance, I have 12 tables whose names
>> are prefix_binval, prefix_bundle, prefix_names, prefix_refs where prefix
>> is jcr_default (for the default workspace), jcr_security (for the
>> security workspace) and version (for the version history store).
>>
>> Regards
>> Felix
>>
>>>
>>>
>>> Tony Giaccone
>>>
>>>
> 
>

Re: Database issues..

Posted by Tony Giaccone <to...@giaccone.org>.
Felix,

What I think is happening, and I'm not sure about this, is that the filesystem repository was deleted. So now Jackrabbit thinks it has to start up with an empty instance and it's going to try and create those tables as part of the "instantiate the repository". 

I solved the problem by deleting the tables and sequences and letting Jackrabbit create a blank new instance.  That solves the problem for now. 

I was able to start stop and restart the instance of sling/jackrabbit/postgres many times before I had a problem. 

I'm playing a bit lose with this as I'm trying to switch between jackrabbit using postgress and jackrabbit using oracle. 

I'm not keen on the file repository being in the same space as the web server

To solve this problem in part, I think I need to move the repository out from under the application server (glassfish) and into a file space
that won't be disturbed as I do new installs of glassfish, sling and jackrabbit. 

. So I made this change:

    <FileSystem class="org.apache.jackrabbit.core.fs.local.LocalFileSystem">
        <!-- <param name="path" value="${rep.home}/repository"/> -->
        <param name="path" value="/jackrabbit/repository/postgres/"/>
    </FileSystem>

I believe that should move the file repository out of the file system controlled by the application server.

That way I can have one filesystem that's set up for oracle, and another for postgres, and not have any problem with documents inconsistencies between the two repositories. 

Does this approach seem reasonable?


Tony


On Jun 17, 2010, at 9:31 AM, Felix Meschberger wrote:

> Hi Tony,
> 
> On 17.06.2010 14:32, Tony Giaccone wrote:
>> 
>> 
>> Twice now, I've ended up having problems starting up Sling and ended up having to delete all the tables in the database, to solve the problem. 
>> 
>> I recognize that this is probably a jackrabbit problem and so perhaps not appropriate for this list, but given that the jackrabbit instance is part of the sling install, I'm going to start here first. 
>> 
>> 
>> The app was shut down, perhaps improperly, but I had to reboot my laptop. I had to delete glassfish and in doing so blasted the repository file system. 
>> 
>> 
>> On restart I get this message: 
>> 
>> 16.06.2010 20:49:00.906 *ERROR* [Repository Pinger] org.apache.jackrabbit.core.RepositoryImpl Failed to initialize workspace 'default' javax.jcr.RepositoryException: Cannot instantiate persistence manager org.apache.jackrabbit.core.persistence.bundle.PostgreSQLPersistenceManager
>> 
>> Caused by: java.sql.SQLException: Schema generation error: Issuing statement: create table JCR_DEFAULT_REFS (NODE_ID_HI bigint not null, NODE_ID_LO bigint not null, REFS_DATA bytea not null, PRIMARY KEY (NODE_ID_HI, NODE_ID_LO))
>> 
>> Caused by: org.postgresql.util.PSQLException: ERROR: relation "jcr_default_refs" already exists
>> 
>> 
>> Now I'm only using Postgres for the Persistence manager, and not also using the DbFileSystem. Is this possibly a problem with the FileSystem being out of synch with the Persistence manager?
>> 
>> Is this a general tip in the direction that says, keep your file system in the database also?
> 
> I have also setup a Sling instance with PostgresSQL without switching to
> DbFileSystem. And until now, I had no issues whatsoever.
> 
> It looks like the persistence manager cannot find the jcr_default_bundle
> table and thus decides to create all tables for the "default" workspace.
> 
> This then fails, because the jcr_default_refs table (?) seems to
> still/already exist.
> 
> It sure looks strange, that the jcr_default_bundle table is missing, but
> the jcr_default_refs table exists.
> 
> What tables exist at all ? In my instance, I have 12 tables whose names
> are prefix_binval, prefix_bundle, prefix_names, prefix_refs where prefix
> is jcr_default (for the default workspace), jcr_security (for the
> security workspace) and version (for the version history store).
> 
> Regards
> Felix
> 
>> 
>> 
>> Tony Giaccone
>> 
>>

Re: Database issues..

Posted by Felix Meschberger <fm...@gmail.com>.
Hi Tony,

On 17.06.2010 14:32, Tony Giaccone wrote:
> 
> 
> Twice now, I've ended up having problems starting up Sling and ended up having to delete all the tables in the database, to solve the problem. 
> 
> I recognize that this is probably a jackrabbit problem and so perhaps not appropriate for this list, but given that the jackrabbit instance is part of the sling install, I'm going to start here first. 
> 
> 
> The app was shut down, perhaps improperly, but I had to reboot my laptop. I had to delete glassfish and in doing so blasted the repository file system. 
> 
> 
> On restart I get this message: 
> 
> 16.06.2010 20:49:00.906 *ERROR* [Repository Pinger] org.apache.jackrabbit.core.RepositoryImpl Failed to initialize workspace 'default' javax.jcr.RepositoryException: Cannot instantiate persistence manager org.apache.jackrabbit.core.persistence.bundle.PostgreSQLPersistenceManager
> 
> Caused by: java.sql.SQLException: Schema generation error: Issuing statement: create table JCR_DEFAULT_REFS (NODE_ID_HI bigint not null, NODE_ID_LO bigint not null, REFS_DATA bytea not null, PRIMARY KEY (NODE_ID_HI, NODE_ID_LO))
> 
> Caused by: org.postgresql.util.PSQLException: ERROR: relation "jcr_default_refs" already exists
> 
> 
> Now I'm only using Postgres for the Persistence manager, and not also using the DbFileSystem. Is this possibly a problem with the FileSystem being out of synch with the Persistence manager?
> 
> Is this a general tip in the direction that says, keep your file system in the database also?

I have also setup a Sling instance with PostgresSQL without switching to
DbFileSystem. And until now, I had no issues whatsoever.

It looks like the persistence manager cannot find the jcr_default_bundle
table and thus decides to create all tables for the "default" workspace.

This then fails, because the jcr_default_refs table (?) seems to
still/already exist.

It sure looks strange, that the jcr_default_bundle table is missing, but
the jcr_default_refs table exists.

What tables exist at all ? In my instance, I have 12 tables whose names
are prefix_binval, prefix_bundle, prefix_names, prefix_refs where prefix
is jcr_default (for the default workspace), jcr_security (for the
security workspace) and version (for the version history store).

Regards
Felix

> 
> 
> Tony Giaccone
> 
>