[jira] Updated: (JCR-2106) SystemSessions created for GarbageCollector are not logged out of
[
https://issues.apache.org/jira/browse/JCR-2106?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Peter Dettman updated JCR-2106:
---
Attachment: JCR-2106-3rd.patch
Ignore the 2nd patch, I've attached a 3rd that incorporates close/finalize as
suggested.
> SystemSessions created for GarbageCollector are not logged out of
> -
>
> Key: JCR-2106
> URL: https://issues.apache.org/jira/browse/JCR-2106
> Project: Jackrabbit Content Repository
> Issue Type: Improvement
> Components: jackrabbit-core
>Affects Versions: 1.5.5
>Reporter: Peter Dettman
>Assignee: Thomas Mueller
>Priority: Minor
> Attachments: JCR-2106-2nd.patch, JCR-2106-3rd.patch, JCR-2106.patch
>
> Original Estimate: 2h
> Remaining Estimate: 2h
>
> I have a simple garbage collection task that runs periodically. After
> upgrading to 1.5.5 it started logging a warning shortly after each run:
> 2009-05-09 03:44:45,480 WARN [org.apache.jackrabbit.core.SessionImpl] -
>
> java.lang.Exception: Stack Trace
> at org.apache.jackrabbit.core.SessionImpl.(SessionImpl.java:239)
> at
> org.apache.jackrabbit.core.SystemSession.(SystemSession.java:76)
> at
> org.apache.jackrabbit.core.SystemSession.create(SystemSession.java:64)
> at
> org.apache.jackrabbit.core.SessionImpl.createDataStoreGarbageCollector(SessionImpl.java:649)
> So it's not my session, but an internally created SystemSession.
> Code I'm using:
> getTemplate().execute(new JcrCallback()
> {
> public Object doInJcr(Session session)
> throws IOException, RepositoryException {
> SessionImpl sessionImpl = (SessionImpl)session;
> GarbageCollector gc =
> sessionImpl.createDataStoreGarbageCollector();
> gc.scan();
> gc.stopScan();
> gc.deleteUnused();
> return null;
> }
> }, true);
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
Semantic distance search
Hi everybody, after having some time of indirect contact with JCR throught sling and day crx/cq I now think it's time to get in touch with jackrabbit directly. As the subject says I do this after having an idea which I'd like to share and need some help to realize (since my lucene experiences are close to nothing but pure usage & theory). I did try to start with a proof of concept but as I looked in the current implementations of search in jcr I had to realize I need someone who could give me a jumpstart and does the first steps together with me. So here I go with my idea: I recently had some thoughts about something I'd call sementic distance in multidimensional hierachies (content structures + hierarchical tagging like in CQ 5 [1]). The task I would like to fullfill: Find the semantically closest nodes for a given node. I postulate that structure represents the semantic relation as well as the referenced tags are in a hierarchie that represents semantic relations. Furthermore I postulate subnodes are semanticaly a subset of the "type" of the parentnode (not thinking of jcr-types but in semantical classifications) This leads into the following thesis: The distance to the closest shared parentnode represents the unidirectional distance of a node to another node. The result is that a whole branch has the same distance to a node. (which should be correct since the subnode in the branch belongs to the parent node which connects the branches we have to look at). My try to figure out a good way to produce an index for this really seams to be hard so I rethought my assumptions and came up with the following way of determining the distance without indexing the explicit distance (came up with this thought after reading a bit about the Analyzers and Stemming). 1. For indexing all referenced taghandles and the own handle will be taken into account for indexing 2. an analyzer produces stringtokens out of each handle. Each handle will be split up in multiple handles by removing the last node till the rootnode is reached (so the node and every parentnode is indexed for this node as well as for each referenced tag) 3. The query has to built based on a given handle since I want to search for the semantically closest nodes. 4. The query is built the same way as the Analyzer has to split the handle in all parent handles. Result: A 100% match can only be produced for the same node (for all other nodes at least the own handle of the node is missing). The "semantically" closer a node is the more handles will match wich will result in an ordering as I intended. Et Voilá we have all we need to search for search semantically close pages in a proper sorting order. I might have a gap in my conclusions but didn't realise it yet, Id love to have some feedback and would appreciate some help to get startet with the mentioned proof of concept. WDYT? Best regards, Dominik [1] http://dev.day.com/microsling/content/blogs/main/cq5tags.html
Semantic distance search
Hi everybody, after having some time of indirect contact with JCR throught sling and day crx/cq I now think it's time to get in touch with jackrabbit directly. As the subject says I do this after having an idea which I'd like to share and need some help to realize (since my lucene experiences are close to nothing but pure usage & theory). I did try to start with a proof of concept but as I looked in the current implementations of search in jcr I had to realize I need someone who could give me a jumpstart and does the first steps together with me. So here I go with my idea: I recently had some thoughts about something I'd call sementic distance in multidimensional hierachies (content structures + hierarchical tagging like in CQ 5 [1]). The task I would like to fullfill: Find the semantically closest nodes for a given node. I postulate that structure represents the semantic relation as well as the referenced tags are in a hierarchie that represents semantic relations. Furthermore I postulate subnodes are semanticaly a subset of the "type" of the parentnode (not thinking of jcr-types but in semantical classifications) This leads into the following thesis: The distance to the closest shared parentnode represents the unidirectional distance of a node to another node. The result is that a whole branch has the same distance to a node. (which should be correct since the subnode in the branch belongs to the parent node which connects the branches we have to look at). My try to figure out a good way to produce an index for this really seams to be hard so I rethought my assumptions and came up with the following way of determining the distance without indexing the explicit distance (came up with this thought after reading a bit about the Analyzers and Stemming). 1. For indexing all referenced taghandles and the own handle will be taken into account for indexing 2. an analyzer produces stringtokens out of each handle. Each handle will be split up in multiple handles by removing the last node till the rootnode is reached (so the node and every parentnode is indexed for this node as well as for each referenced tag) 3. The query has to built based on a given handle since I want to search for the semantically closest nodes. 4. The query is built the same way as the Analyzer has to split the handle in all parent handles. Result: A 100% match can only be produced for the same node (for all other nodes at least the own handle of the node is missing). The "semantically" closer a node is the more handles will match wich will result in an ordering as I intended. Et Voilá we have all we need to search for search semantically close pages in a proper sorting order. I might have a gap in my conclusions but didn't realise it yet, Id love to have some feedback and would appreciate some help to get startet with the mentioned proof of concept. WDYT? Best regards, Dominik [1] http://dev.day.com/microsling/content/blogs/main/cq5tags.html
Hudson build is back to normal: Chemistry-jcr-c mis » Jackrabbit CMIS Web Services Binding #139
See http://hudson.zones.apache.org/hudson/job/Chemistry-jcr-cmis/org.apache.jackrabbit$jcr-cmis-server-ws/139/
Re: Build failed in Hudson: Chemistry-jcr-cmis » Ja ckrabbit CMIS Web Services Binding #136
Hi, On Wed, May 20, 2009 at 8:41 PM, Apache Hudson Server wrote: > http://hudson.zones.apache.org/hudson/job/Chemistry-jcr-cmis/org.apache.jackrabbit$jcr-cmis-server-ws/ws/src/test/java/org/apache/jackrabbit/cmis/ws/repository/RepositoryServiceTest.java > :[58,18] exception java.io.IOException is never thrown in body of > corresponding try statement This was caused by my changes in JCR-2119. I've fixed the 1.x branch accordingly. PS. I'll update the Hudson job to rather send notifications to chemistry-...@. BR, Jukka Zitting
