jackrabbit-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Aarnout van der Meulen <Aarnout.van.der.Meu...@e-office.com>
Subject Re: AW: AW: Jackrabbit on Websphere - problems with .lock
Date Mon, 19 Mar 2007 14:00:20 GMT
The repository is looked up in the context more than once (different 
portlets using the same backend).
In most cases it works fine, but somtimes the .lock error is thrown.

I will have a closer look at the different processes.
Thanks for the suggestions.

Aarnout





KÖLL Claus <C.KOELL@TIROL.GV.AT> 
19-03-2007 09:58
Please respond to
users@jackrabbit.apache.org


To
<users@jackrabbit.apache.org>
cc

Subject
AW: AW: Jackrabbit on Websphere - problems with .lock






Do you see any logs before you get the lock exception ?
Something like try to start the repository ?
It looks like that jackrabbit trys to start the workspace a second time ..


-----Ursprüngliche Nachricht-----
Von: Aarnout van der Meulen [mailto:Aarnout.van.der.Meulen@e-office.com] 
Gesendet: Freitag, 16. März 2007 10:42
An: users@jackrabbit.apache.org
Betreff: Re: AW: Jackrabbit on Websphere - problems with .lock

There are no errors on server start.
Another thread: The repository is initialized in a .ear, when it is called 

from a portlet I get the .lock-error but login is possible and it works. 
When it is called from a seperate servlet, I get the .lock-error and it 
fails.

Aarnout




KÖLL Claus <C.KOELL@TIROL.GV.AT> 
16-03-2007 09:48
Please respond to
users@jackrabbit.apache.org


To
<users@jackrabbit.apache.org>
cc

Subject
AW: Jackrabbit on Websphere - problems with .lock






We are working with higher Versions on Websphere 5.1. and we had some 
problems which now has been fixed ;-)
Do you see any logs on server start ?
Maybe it will be started from a other Thread (RecoveryManager) ..

 
-----Ursprüngliche Nachricht-----
Von: Aarnout van der Meulen [mailto:Aarnout.van.der.Meulen@e-office.com] 
Gesendet: Freitag, 16. März 2007 09:29
An: users@jackrabbit.apache.org
Betreff: Jackrabbit on Websphere - problems with .lock

Hello,

Almost a year ago we used Jackrabbit 1.0 for an application for WebSphere 
Portal Server 5.1 (on WebSphere Application Server 5.1). We used 
deployment model 2, and configured Jackrabbit using a Resource Environment 


Provider. Everything works fine.

Now we want to build a next version of out application, and upgrade 
Jackrabbit (to use DbFileSystem instead of LocalFileSystem). But if I use 
a higher version of Jackrabbit, errors are thrown as soon as I try to get 
the repository from the context.

Does anybody know what has changed? Is it possible to run versions above 
1.0 on WebSphere 5.1?


Code to get the repository is not more than this:
        InitialContext ctx = new InitialContext();
        Repository repository = (Repository) 
ctx.lookup("java:comp/env/jcrRepository");

The error thrown:
Exception data follows:
javax.jcr.RepositoryException: The repository home at D:\StadsPoortJCR 
appears to be in use since the file at D:\StadsPoortJCR\.lock is locked by 


another process.
        at 
org.apache.jackrabbit.core.RepositoryImpl.acquireRepositoryLock(RepositoryImpl.java:412)
        at 
org.apache.jackrabbit.core.RepositoryImpl.<init>(RepositoryImpl.java:236)
        at 
org.apache.jackrabbit.core.RepositoryImpl.create(RepositoryImpl.java:573)
        at 
org.apache.jackrabbit.core.jndi.BindableRepository.createRepository(BindableRepository.java:174)
        at 
org.apache.jackrabbit.core.jndi.BindableRepository.init(BindableRepository.java:138)
        at 
org.apache.jackrabbit.core.jndi.BindableRepository.create(BindableRepository.java:125)
        at 
org.apache.jackrabbit.core.jndi.BindableRepositoryFactory.createInstance(BindableRepositoryFactory.java:59)
        at 
org.apache.jackrabbit.core.jndi.BindableRepositoryFactory.getObjectInstance(BindableRepositoryFactory.java:81)
        at 
javax.naming.spi.NamingManager.getObjectInstance(NamingManager.java:314)
        at 
com.ibm.ws.naming.util.Helpers.processSerializedObjectForLookupExt(Helpers.java:873)
        at 
com.ibm.ws.naming.util.Helpers.processSerializedObjectForLookup(Helpers.java:680)
        at 
com.ibm.ws.naming.jndicos.CNContextImpl.processResolveResults(CNContextImpl.java:1714)
        at 
com.ibm.ws.naming.jndicos.CNContextImpl.doLookup(CNContextImpl.java:1569)
        at 
com.ibm.ws.naming.jndicos.CNContextImpl.doLookup(CNContextImpl.java:1482)
        at 
com.ibm.ws.naming.jndicos.CNContextImpl.lookupExt(CNContextImpl.java:1189)
        at 
com.ibm.ws.naming.util.IndirectJndiLookupObjectFactory$1.run(IndirectJndiLookupObjectFactory.java:372)
        at 
com.ibm.ws.security.util.AccessController.doPrivileged(AccessController.java(Compiled 


Code))
        at 
com.ibm.ws.naming.util.IndirectJndiLookupObjectFactory.getObjectInstanceExt(IndirectJndiLookupObjectFactory.java:221)
        at 
com.ibm.ws.naming.util.Helpers.processSerializedObjectForLookupExt(Helpers.java:868)
        at 
com.ibm.ws.naming.urlbase.UrlContextHelper.processBoundObjectForLookup(UrlContextHelper.java:152)
        at 
com.ibm.ws.naming.java.javaURLContextRoot.processBoundObjectForLookup(javaURLContextRoot.java:398)
        at 
com.ibm.ws.naming.urlbase.UrlContextImpl.lookup(UrlContextImpl.java(Compiled 


Code))
        at 
com.ibm.ws.naming.java.javaURLContextRoot.lookup(javaURLContextRoot.java(Compiled 


Code))
        at 
com.ibm.ws.naming.java.javaURLContextRoot.lookup(javaURLContextRoot.java:137)
        at javax.naming.InitialContext.lookup(InitialContext.java:361)

Thanks,
Aarnout

De informatie in dit e-mailbericht (inclusief aanhangsels) is 
vertrouwelijk en is alleen bestemd voor de beoogde ontvanger(s). Indien u 
dit bericht onterecht heeft ontvangen, wordt u verzocht het bericht te 
retourneren en de ontvangen informatie op geen enkele wijze te gebruiken. 

The information contained in this e-mail (attachments included) may be 
confidential and is intended solely for the person(s) indicated in the 
message. Should you have received this e-mail unintentionally, please 
return it to the sender and do not use the content of the message in any 
way.



Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message