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