You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@jackrabbit.apache.org by Boris Kraft <bo...@obinary.com> on 2005/06/14 00:33:33 UTC
indexing, jackrabbit & cqfs
Is it still possible to turn of indexing (and versioning while I am at
it) with the current release of jackrabbit?
The reason why I am asking is that with my latest build (from last
Saturday) I have serious problems to get a stable repository using
cqfs. In particular, the repository breaks and the indexer writes out
index.dat files with a size of ~100GB (yes, thats Gigabyte). Obviously,
I am not really happy about that.
Does anybody else experience similar behavior?
And, while it doesn't help the broken repository, I'd be glad to avoid
these big index.dat files for the time being. Of course if anyone has
any ideas why my repository breaks, I'd be happy to hear about it. See
some log messages below if you want...
Thanks
Boris Kraft
---------------------------
Magnolia Content Management
http://www.magnolia.info/
---------------------------
ERROR org.apache.jackrabbit.core.SearchManager
SearchManager.java(onEvent:265) 13.06.2005 23:22:03 Error deleting
node from index.
java.io.IOException: failed to get output stream for /_9/commit.lock:
Header 1630548756 not found.
at
org.apache.jackrabbit.core.query.lucene.FileSystemDirectory$1.obtain(Fil
eSystemDirectory.java:256)
at org.apache.lucene.store.Lock.obtain(Lock.java:53)
at org.apache.lucene.store.Lock$With.run(Lock.java:108)
at org.apache.lucene.index.IndexReader.open(IndexReader.java:111)
at org.apache.lucene.index.IndexReader.open(IndexReader.java:106)
at
org.apache.jackrabbit.core.query.lucene.AbstractIndex.getIndexReader(Abs
tractIndex.java:127)
at
org.apache.jackrabbit.core.query.lucene.AbstractIndex.removeDocument(Abs
tractIndex.java:112)
at
org.apache.jackrabbit.core.query.lucene.MultiIndex.removeDocument(MultiI
ndex.java:271)
at
org.apache.jackrabbit.core.query.lucene.SearchIndex.deleteNode(SearchInd
ex.java:126)
at
org.apache.jackrabbit.core.SearchManager.deleteNode(SearchManager.java:
155)
at
org.apache.jackrabbit.core.SearchManager.onEvent(SearchManager.java:
263)
...
--------------------
java.io.IOException: No space left on device
at java.io.RandomAccessFile.writeBytes(Native Method)
at java.io.RandomAccessFile.write(RandomAccessFile.java:448)
at com.day.fs.RandomAccessFile.write(RandomAccessFile.java:157)
at com.day.fs.FileSystem.write(FileSystem.java:2023)
at com.day.fs.Block.store(Block.java:283)
at com.day.fs.Block.flush(Block.java:297)
at
com.day.fs.BufferCache$WriteBlockBackHandler.run(BufferCache.java:726)
--------------------
Lock obtain timed out: Lock@commit.lock: Lock obtain timed out:
Lock@commit.lock: Lock obtain timed out: Lock@commit.lock
at
org.apache.jackrabbit.core.SearchManager.<init>(SearchManager.java:124)
at
org.apache.jackrabbit.core.RepositoryImpl$WorkspaceInfo.getSearchManager
(RepositoryImpl.java:1132)
at
org.apache.jackrabbit.core.RepositoryImpl.getSearchManager(RepositoryImp
l.java:536)
at
org.apache.jackrabbit.core.RepositoryImpl.initWorkspace(RepositoryImpl.j
ava:398)
at
org.apache.jackrabbit.core.RepositoryImpl.<init>(RepositoryImpl.java:
293)
at
org.apache.jackrabbit.core.RepositoryImpl.create(RepositoryImpl.java:
344)
at
org.apache.jackrabbit.core.jndi.BindableRepository.init(BindableReposito
ry.java:116)
at
org.apache.jackrabbit.core.jndi.BindableRepository.create(BindableReposi
tory.java:104)
at
org.apache.jackrabbit.core.jndi.RegistryHelper.registerRepository(Regist
ryHelper.java:57)
at info.magnolia.jackrabbit.ProviderImpl.init(ProviderImpl.java:68)
... 53 more
Caused by: java.io.IOException: Lock obtain timed out: Lock@commit.lock
at org.apache.lucene.store.Lock.obtain(Lock.java:58)
at org.apache.lucene.store.Lock$With.run(Lock.java:108)
at org.apache.lucene.index.IndexReader.open(IndexReader.java:111)
at org.apache.lucene.index.IndexReader.open(IndexReader.java:106)
at
org.apache.jackrabbit.core.query.lucene.AbstractIndex.getIndexReader(Abs
tractIndex.java:127)
at
org.apache.jackrabbit.core.query.lucene.AbstractIndex.removeDocument(Abs
tractIndex.java:112)
at
org.apache.jackrabbit.core.query.lucene.MultiIndex.deleteNodePersistent(
MultiIndex.java:495)
at
org.apache.jackrabbit.core.query.lucene.MultiIndex.<init>(MultiIndex.jav
a:214)
at
org.apache.jackrabbit.core.query.lucene.SearchIndex.doInit(SearchIndex.j
ava:83)
at
org.apache.jackrabbit.core.query.AbstractQueryHandler.init(AbstractQuery
Handler.java:39)
at
org.apache.jackrabbit.core.SearchManager.<init>(SearchManager.java:122)
... 62 more
javax.jcr.RepositoryException: Lock obtain timed out: Lock@commit.lock:
Lock obtain timed out: Lock@commit.lock: Lock obtain timed out:
Lock@commit.lock
at
org.apache.jackrabbit.core.SearchManager.<init>(SearchManager.java:124)
at
org.apache.jackrabbit.core.RepositoryImpl$WorkspaceInfo.getSearchManager
(RepositoryImpl.java:1132)
at
org.apache.jackrabbit.core.RepositoryImpl.getSearchManager(RepositoryImp
l.java:536)
at
org.apache.jackrabbit.core.RepositoryImpl.initWorkspace(RepositoryImpl.j
ava:398)
at
org.apache.jackrabbit.core.RepositoryImpl.<init>(RepositoryImpl.java:
293)
at
org.apache.jackrabbit.core.RepositoryImpl.create(RepositoryImpl.java:
344)
at
org.apache.jackrabbit.core.jndi.BindableRepository.init(BindableReposito
ry.java:116)
at
org.apache.jackrabbit.core.jndi.BindableRepository.create(BindableReposi
tory.java:104)
at
org.apache.jackrabbit.core.jndi.RegistryHelper.registerRepository(Regist
ryHelper.java:57)
at info.magnolia.jackrabbit.ProviderImpl.init(ProviderImpl.java:68)
at
info.magnolia.cms.beans.config.ContentRepository.loadRepository(ContentR
epository.java:266)
at
info.magnolia.cms.beans.config.ContentRepository.loadRepositories(Conten
tRepository.java:254)
at
info.magnolia.cms.beans.config.ContentRepository.init(ContentRepository.
java:168)
at
info.magnolia.cms.beans.config.ConfigLoader.load(ConfigLoader.java:100)
at
info.magnolia.cms.beans.config.ConfigLoader.<init>(ConfigLoader.java:
87)
at info.magnolia.cms.servlets.Initializer.init(Initializer.java:54)
at javax.servlet.GenericServlet.init(GenericServlet.java:211)
at
org.apache.catalina.core.StandardWrapper.loadServlet(StandardWrapper.jav
a:1029)
at
org.apache.catalina.core.StandardWrapper.load(StandardWrapper.java:862)
at
org.apache.catalina.core.StandardContext.loadOnStartup(StandardContext.j
ava:4013)
at
org.apache.catalina.core.StandardContext.start(StandardContext.java:
4357)
at
org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.ja
va:823)
at
org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:807)
at
org.apache.catalina.core.StandardHost.addChild(StandardHost.java:595)
at
org.apache.catalina.core.StandardHostDeployer.addChild(StandardHostDeplo
yer.java:903)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.jav
a:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessor
Impl.java:25)
at java.lang.reflect.Method.invoke(Method.java:324)
at
org.apache.commons.beanutils.MethodUtils.invokeMethod(MethodUtils.java:
216)
at org.apache.commons.digester.SetNextRule.end(SetNextRule.java:256)
at org.apache.commons.digester.Rule.end(Rule.java:276)
at org.apache.commons.digester.Digester.endElement(Digester.java:1058)
at
org.apache.catalina.util.CatalinaDigester.endElement(CatalinaDigester.ja
va:76)
at org.apache.xerces.parsers.AbstractSAXParser.endElement(Unknown
Source)
at
org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanEndElement(Unk
nown Source)
at
org.apache.xerces.impl.XMLDocumentFragmentScannerImpl$FragmentContentDis
patcher.dispatch(Unknown Source)
at
org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanDocument(Unkno
wn Source)
at org.apache.xerces.parsers.XML11Configuration.parse(Unknown Source)
at org.apache.xerces.parsers.XML11Configuration.parse(Unknown Source)
at org.apache.xerces.parsers.XMLParser.parse(Unknown Source)
at org.apache.xerces.parsers.AbstractSAXParser.parse(Unknown Source)
at org.apache.commons.digester.Digester.parse(Digester.java:1567)
at
org.apache.catalina.core.StandardHostDeployer.install(StandardHostDeploy
er.java:488)
at org.apache.catalina.core.StandardHost.install(StandardHost.java:863)
at
org.apache.catalina.startup.HostConfig.deployDescriptors(HostConfig.java
:483)
at
org.apache.catalina.startup.HostConfig.deployApps(HostConfig.java:427)
at org.apache.catalina.startup.HostConfig.start(HostConfig.java:983)
at
org.apache.catalina.startup.HostConfig.lifecycleEvent(HostConfig.java:
349)
at
org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent(LifecycleSu
pport.java:119)
at
org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1091)
at org.apache.catalina.core.StandardHost.start(StandardHost.java:789)
at
org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1083)
at
org.apache.catalina.core.StandardEngine.start(StandardEngine.java:478)
at
org.apache.catalina.core.StandardService.start(StandardService.java:
480)
at
org.apache.catalina.core.StandardServer.start(StandardServer.java:2313)
at org.apache.catalina.startup.Catalina.start(Catalina.java:556)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.jav
a:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessor
Impl.java:25)
at java.lang.reflect.Method.invoke(Method.java:324)
at org.apache.catalina.startup.Bootstrap.start(Bootstrap.java:287)
at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:425)
Caused by: java.io.IOException: Lock obtain timed out: Lock@commit.lock
at org.apache.lucene.store.Lock.obtain(Lock.java:58)
at org.apache.lucene.store.Lock$With.run(Lock.java:108)
at org.apache.lucene.index.IndexReader.open(IndexReader.java:111)
at org.apache.lucene.index.IndexReader.open(IndexReader.java:106)
at
org.apache.jackrabbit.core.query.lucene.AbstractIndex.getIndexReader(Abs
tractIndex.java:127)
at
org.apache.jackrabbit.core.query.lucene.AbstractIndex.removeDocument(Abs
tractIndex.java:112)
at
org.apache.jackrabbit.core.query.lucene.MultiIndex.deleteNodePersistent(
MultiIndex.java:495)
at
org.apache.jackrabbit.core.query.lucene.MultiIndex.<init>(MultiIndex.jav
a:214)
at
org.apache.jackrabbit.core.query.lucene.SearchIndex.doInit(SearchIndex.j
ava:83)
at
org.apache.jackrabbit.core.query.AbstractQueryHandler.init(AbstractQuery
Handler.java:39)
at
org.apache.jackrabbit.core.SearchManager.<init>(SearchManager.java:122)
Re: indexing, jackrabbit & cqfs
Posted by Stefan Guggisberg <st...@gmail.com>.
On Tue, Jun 14, 2005 at 3:19 PM, Boris Kraft <bo...@obinary.com> wrote:
> On 14.06.2005, at 10:58, Marcel Reutegger wrote:
>
>> Boris Kraft wrote:
>>>
>>> Is it still possible to turn of indexing (and versioning while I am at
>>> it) with the current release of jackrabbit?
>>
>> If you comment out the SearchIndex tag in the workspace.xml you can
>> disable the QueryManager / Indexing.
>
> Thanks
>
>>> The reason why I am asking is that with my latest build (from last
>>> Saturday) I have serious problems to get a stable repository using cqfs.
>>> In particular, the repository breaks and the indexer writes out index.dat
>>> files with a size of ~100GB (yes, thats Gigabyte). Obviously, I am not
>>> really happy about that.
>>> Does anybody else experience similar behavior?
>>
>> Nope, haven't seen this before.
>> It seems that you are using CQFS as the underlying filesystem for the
>> search index. If this is true, I recommend to use LocalFileSystem.
>>
>> One reason for the huge index.dat file might be that the configuration for
>> CQFS is not apropriate for the use as a filesystem for search index. e.g.
>> the blocksize parameter has an influence on the maxmimum file size that can
>> be created in CQFS.
>
> Yes, that might be a good idea.
>
> I am currently moving from cqfs to filesystem and up to now this looks quite
> promising (except for the number of files I now have). The repository is now
> stable again. It might be an issue with CQFS on OSX, I'll let you know if
wrong list.
since cqfs is a commercial product, please contact your product support channel.
cheers
stefan
> problems go away when run on windows.
>
> Thanks again
> - Boris
>
>
Re: indexing, jackrabbit & cqfs
Posted by Boris Kraft <bo...@obinary.com>.
On 14.06.2005, at 10:58, Marcel Reutegger wrote:
> Boris Kraft wrote:
>> Is it still possible to turn of indexing (and versioning while I am
>> at it) with the current release of jackrabbit?
>
> If you comment out the SearchIndex tag in the workspace.xml you can
> disable the QueryManager / Indexing.
Thanks
>> The reason why I am asking is that with my latest build (from last
>> Saturday) I have serious problems to get a stable repository using
>> cqfs. In particular, the repository breaks and the indexer writes out
>> index.dat files with a size of ~100GB (yes, thats Gigabyte).
>> Obviously, I am not really happy about that.
>> Does anybody else experience similar behavior?
>
> Nope, haven't seen this before.
> It seems that you are using CQFS as the underlying filesystem for the
> search index. If this is true, I recommend to use LocalFileSystem.
>
> One reason for the huge index.dat file might be that the configuration
> for CQFS is not apropriate for the use as a filesystem for search
> index. e.g. the blocksize parameter has an influence on the maxmimum
> file size that can be created in CQFS.
Yes, that might be a good idea.
I am currently moving from cqfs to filesystem and up to now this looks
quite promising (except for the number of files I now have). The
repository is now stable again. It might be an issue with CQFS on OSX,
I'll let you know if problems go away when run on windows.
Thanks again
- Boris
Re: indexing, jackrabbit & cqfs
Posted by Marcel Reutegger <ma...@gmx.net>.
Boris Kraft wrote:
> Is it still possible to turn of indexing (and versioning while I am at
> it) with the current release of jackrabbit?
If you comment out the SearchIndex tag in the workspace.xml you can
disable the QueryManager / Indexing.
> The reason why I am asking is that with my latest build (from last
> Saturday) I have serious problems to get a stable repository using
> cqfs. In particular, the repository breaks and the indexer writes out
> index.dat files with a size of ~100GB (yes, thats Gigabyte). Obviously,
> I am not really happy about that.
>
> Does anybody else experience similar behavior?
Nope, haven't seen this before.
It seems that you are using CQFS as the underlying filesystem for the
search index. If this is true, I recommend to use LocalFileSystem.
One reason for the huge index.dat file might be that the configuration
for CQFS is not apropriate for the use as a filesystem for search index.
e.g. the blocksize parameter has an influence on the maxmimum file size
that can be created in CQFS.
regards
marcel
Re: indexing, jackrabbit & cqfs
Posted by mmahawar <mm...@quicksolutions.com>.
Hi Boris ,
I am little new to jackrabbit and having similar kind issue. We configured
jackrabbit in embedded mode with tomcat 6. Our catalina.out log file is
growing to gigabytes size with all the jackrabbit logging messages.
[TP-Processor8] DEBUG o.apache.jackrabbit.core.ItemManager - caching item
a3a7bcd9-82cd-48c7-a5a3-134487fb54ec/{http://www.jcp.org/jcr/1.0}uuid
DEBUG o.apache.jackrabbit.core.ItemManager - caching item
a3a7bcd9-82cd-48c7-a5a3-134487fb54ec/{http://www.jcp.org/jcr/1.0}mixinTypes
DEBUG o.apache.jackrabbit.core.ItemManager - caching item
a3a7bcd9-82cd-48c7-a5a3-134487fb54ec/{http://www.jcp.org/jcr/1.0}primaryType
[TP-Processor8] DEBUG o.apache.jackrabbit.core.ItemManager - caching item
514226c1-7199-4cd6-b770-04d536bd8aa2
[TP-Processor8] DEBUG o.apache.jackrabbit.core.ItemManager - caching item
68d5d185-7ea7-41f5-bfe7-0ef98d6bc85d
[TP-Processor8] DEBUG o.a.j.c.s.a.AbstractLoginModule - Initalize
LoginModule:
[TP-Processor8] DEBUG o.a.j.c.s.a.AbstractLoginModule - - PrincipalProvider
->
'org.apache.jackrabbit.core.security.simple.SimpleSecurityManager$SimplePrincipalProvider'
Do you know how can disable the logging or change the mode to Info. rather
than debug.
Thanks in advance for help.
Manisha
--
View this message in context: http://jackrabbit.510166.n4.nabble.com/indexing-jackrabbit-cqfs-tp523886p3259209.html
Sent from the Jackrabbit - Dev mailing list archive at Nabble.com.