You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@jackrabbit.apache.org by danield <da...@b-s-s.de> on 2012/05/11 10:00:49 UTC
spi2davex.RepositoryServiceImpl -> idUriCache raises until heap
overflow
Hello @all,
i'm using a JCR with an underlying DB.
While querying the JCR, it seems that the queryPath of each result property
of each node is cached within the idUriCache. I thought, that setting the
maxIdleTime="10" will reinstanciate the RepositoryServiceImpl and the cache
will be resetted, but unfortunately it doesn't.
Looking at the heapdump shows me lot of entries like the following:
org.apache.jackrabbit.spi2davex.RepositoryServiceImpl @ 0x7b39aaee8
-org.apache.jackrabbit.spi2dav.URIResolverImpl @ 0x7b399f4e8
--java.util.HashMap @ 0x7b3c3e168
---java.util.HashMap$Entry[16] @ 0x7b39ad4d8
----java.util.HashMap$Entry @ 0x7b3c6a3d8
-----org.apache.jackrabbit.spi2dav.IdURICache @ 0x7b33992a8
------java.util.HashMap @ 0x7b3c3e0d8
-------java.util.HashMap$Entry[32768] @ 0x7b54de1e0
--------java.util.HashMap$Entry @ 0x7b5696b10
value:
http://localhost:8090/jackrabbit-webapp-2.2.2/server/workspace/jcr%3aroot/level1/level2/level3/nodeName/docdatetime
Is there a possiblity to configure the cache or to access the
RepositoryServiceImpl via the JCRSession or Repository instance? I thought
of setting a maxsize to the cache or clearing the cache after a specific
time.
I hope you can help me.
Best regards, Daniel
--
View this message in context: http://jackrabbit.510166.n4.nabble.com/spi2davex-RepositoryServiceImpl-idUriCache-raises-until-heap-overflow-tp4625776.html
Sent from the Jackrabbit - Dev mailing list archive at Nabble.com.
Re: spi2davex.RepositoryServiceImpl -> idUriCache raises until heap
overflow
Posted by danield <da...@b-s-s.de>.
I've created the ticket
https://issues.apache.org/jira/browse/JCR-3305
Daniel
--
View this message in context: http://jackrabbit.510166.n4.nabble.com/spi2davex-RepositoryServiceImpl-idUriCache-raises-until-heap-overflow-tp4625776p4626376.html
Sent from the Jackrabbit - Dev mailing list archive at Nabble.com.
Re: spi2davex.RepositoryServiceImpl -> idUriCache raises until heap
overflow
Posted by danield <da...@b-s-s.de>.
Ok,
then I will create that issue in JIRA and change the uriresolver.
many thanks
greetings Daniel
--
View this message in context: http://jackrabbit.510166.n4.nabble.com/spi2davex-RepositoryServiceImpl-idUriCache-raises-until-heap-overflow-tp4625776p4626274.html
Sent from the Jackrabbit - Dev mailing list archive at Nabble.com.
Re: spi2davex.RepositoryServiceImpl -> idUriCache raises until heap
overflow
Posted by Angela Schreiber <an...@adobe.com>.
hi daniel
> I'm using the JCR as storage for documents with hundreds of new documents per
> day.
> Can it be that JCR is not the right solution for this use case?
well, my assumption was that it should be the right solution.
as far as the uri/id-cache is concerned this just never got a
proper cleanup after the first draft (as the TODOs show).
kind regards
angela
Re: spi2davex.RepositoryServiceImpl -> idUriCache raises until heap
overflow
Posted by danield <da...@b-s-s.de>.
I'm using the JCR as storage for documents with hundreds of new documents per
day.
Can it be that JCR is not the right solution for this use case?
--
View this message in context: http://jackrabbit.510166.n4.nabble.com/spi2davex-RepositoryServiceImpl-idUriCache-raises-until-heap-overflow-tp4625776p4626188.html
Sent from the Jackrabbit - Dev mailing list archive at Nabble.com.
Re: spi2davex.RepositoryServiceImpl -> idUriCache raises until heap
overflow
Posted by Angela Schreiber <an...@adobe.com>.
hi daniel
> thank you for the fast reply.
> I can open this as an issue in JIRA, but I hoped for a quick workaround.
:)
> Can you tell, if it is possible to get the instance of the
> RepositoryServiceImpl to use its clearItemUriCache-method.
> Maybe this can be achieved by the right cast of the Repository/Session
> instance or something like that.
i don't recall that by heart... if i was you i would checkout the
source and change the uriresolver. that fix is overdue anyway.
it has the same TODOs since ages just didn't get enough focus to
be fixed. the quickest solution was probably to limit the size
of that id/uri cache that is just there to avoid too many round
trips (as far as i remember).
the constructor or the repositoryserviceimpl currently doesn't allow
to pass a map of config options... that makes it a bit cumbersome
for extensions :(
regards
angela
>
> This would help me to handle this problem until the cache configuration will
> be available.
>
> greetings Daniel
>
> --
> View this message in context: http://jackrabbit.510166.n4.nabble.com/spi2davex-RepositoryServiceImpl-idUriCache-raises-until-heap-overflow-tp4625776p4625931.html
> Sent from the Jackrabbit - Dev mailing list archive at Nabble.com.
Re: spi2davex.RepositoryServiceImpl -> idUriCache raises until heap
overflow
Posted by danield <da...@b-s-s.de>.
Hi Angela,
thank you for the fast reply.
I can open this as an issue in JIRA, but I hoped for a quick workaround.
Can you tell, if it is possible to get the instance of the
RepositoryServiceImpl to use its clearItemUriCache-method.
Maybe this can be achieved by the right cast of the Repository/Session
instance or something like that.
This would help me to handle this problem until the cache configuration will
be available.
greetings Daniel
--
View this message in context: http://jackrabbit.510166.n4.nabble.com/spi2davex-RepositoryServiceImpl-idUriCache-raises-until-heap-overflow-tp4625776p4625931.html
Sent from the Jackrabbit - Dev mailing list archive at Nabble.com.
Re: spi2davex.RepositoryServiceImpl -> idUriCache raises until heap
overflow
Posted by Angela Schreiber <an...@adobe.com>.
hi daniel
there is currently no possibility to limit the size by
configuration.
may i ask you to file an issue in JIRA for this?
that's the easiest way to have this addressed. even better
if you had a patch at hand. :)
thanks in advance
angela
On 5/11/12 10:00 AM, danield wrote:
> Hello @all,
>
> i'm using a JCR with an underlying DB.
>
> While querying the JCR, it seems that the queryPath of each result property
> of each node is cached within the idUriCache. I thought, that setting the
> maxIdleTime="10" will reinstanciate the RepositoryServiceImpl and the cache
> will be resetted, but unfortunately it doesn't.
>
> Looking at the heapdump shows me lot of entries like the following:
>
> org.apache.jackrabbit.spi2davex.RepositoryServiceImpl @ 0x7b39aaee8
> -org.apache.jackrabbit.spi2dav.URIResolverImpl @ 0x7b399f4e8
> --java.util.HashMap @ 0x7b3c3e168
> ---java.util.HashMap$Entry[16] @ 0x7b39ad4d8
> ----java.util.HashMap$Entry @ 0x7b3c6a3d8
> -----org.apache.jackrabbit.spi2dav.IdURICache @ 0x7b33992a8
> ------java.util.HashMap @ 0x7b3c3e0d8
> -------java.util.HashMap$Entry[32768] @ 0x7b54de1e0
> --------java.util.HashMap$Entry @ 0x7b5696b10
>
> value:
> http://localhost:8090/jackrabbit-webapp-2.2.2/server/workspace/jcr%3aroot/level1/level2/level3/nodeName/docdatetime
>
> Is there a possiblity to configure the cache or to access the
> RepositoryServiceImpl via the JCRSession or Repository instance? I thought
> of setting a maxsize to the cache or clearing the cache after a specific
> time.
>
> I hope you can help me.
> Best regards, Daniel
>
> --
> View this message in context: http://jackrabbit.510166.n4.nabble.com/spi2davex-RepositoryServiceImpl-idUriCache-raises-until-heap-overflow-tp4625776.html
> Sent from the Jackrabbit - Dev mailing list archive at Nabble.com.