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
>>
>>
