[jira] [Comment Edited] (OAK-6419) unique id generator
[ https://issues.apache.org/jira/browse/OAK-6419?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16080085#comment-16080085 ] Torgeir Veimo edited comment on OAK-6419 at 7/10/17 10:34 AM: -- Would it be possible to have someone with intimate knowledge of the clustering setup provide an example method implemented with the Clusterable api? The instanceId available through the Clusterable api seems only to be guaranteed to be non-null, and is not necessarily persisted between restarts, so it cannot really be used in a meaningful way to generate ids that are unique in time. was (Author: torg...@pobox.com): Would it be possible to have someone with intimate knowledge of the clustering setup provide an example method implemented with the clusterable api? > unique id generator > --- > > Key: OAK-6419 > URL: https://issues.apache.org/jira/browse/OAK-6419 > Project: Jackrabbit Oak > Issue Type: New Feature >Reporter: Torgeir Veimo >Priority: Minor > Labels: counters, locking, sequence > > It would be great to have a way to safely generate unique id's for node > names, with oak configured in a cluster configuration. > This is useful for creating unique slug names for documents, and ensuring > unique names for node siblings, or node names repository wide. > It could be implemented as a sequence generator, or similar to how mongodb > generates object ids; https://docs.mongodb.org/manual/reference/object-id/. > With the older jackrabbit implementation it is possible to have a sequence > guaranteed to provide unique id's, using enforceable locks. With oak theres > no such guarantee when used in a clustered configuration. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (OAK-6419) unique id generator
[ https://issues.apache.org/jira/browse/OAK-6419?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16080085#comment-16080085 ] Torgeir Veimo commented on OAK-6419: Would it be possible to have someone with intimate knowledge of the clustering setup provide an example method implemented with the clusterable api? > unique id generator > --- > > Key: OAK-6419 > URL: https://issues.apache.org/jira/browse/OAK-6419 > Project: Jackrabbit Oak > Issue Type: New Feature >Reporter: Torgeir Veimo >Priority: Minor > Labels: counters, locking, sequence > > It would be great to have a way to safely generate unique id's for node > names, with oak configured in a cluster configuration. > This is useful for creating unique slug names for documents, and ensuring > unique names for node siblings, or node names repository wide. > It could be implemented as a sequence generator, or similar to how mongodb > generates object ids; https://docs.mongodb.org/manual/reference/object-id/. > With the older jackrabbit implementation it is possible to have a sequence > guaranteed to provide unique id's, using enforceable locks. With oak theres > no such guarantee when used in a clustered configuration. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (OAK-6419) unique id generator
[ https://issues.apache.org/jira/browse/OAK-6419?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16074222#comment-16074222 ] Torgeir Veimo commented on OAK-6419: It depends on what the id looks like. If it's a uuid style id, then it's no better than just using the id of the node in question. When you generate a document slug, you want an id that is short, eg. 5-12 digits. > unique id generator > --- > > Key: OAK-6419 > URL: https://issues.apache.org/jira/browse/OAK-6419 > Project: Jackrabbit Oak > Issue Type: New Feature >Reporter: Torgeir Veimo >Priority: Minor > Labels: counters, locking, sequence > > It would be great to have a way to safely generate unique id's for node > names, with oak configured in a cluster configuration. > This is useful for creating unique slug names for documents, and ensuring > unique names for node siblings, or node names repository wide. > It could be implemented as a sequence generator, or similar to how mongodb > generates object ids; https://docs.mongodb.org/manual/reference/object-id/. > With the older jackrabbit implementation it is possible to have a sequence > guaranteed to provide unique id's, using enforceable locks. With oak theres > no such guarantee when used in a clustered configuration. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (OAK-6419) unique id generator
Torgeir Veimo created OAK-6419: -- Summary: unique id generator Key: OAK-6419 URL: https://issues.apache.org/jira/browse/OAK-6419 Project: Jackrabbit Oak Issue Type: New Feature Reporter: Torgeir Veimo Priority: Minor It would be great to have a way to safely generate unique id's for node names, with oak configured in a cluster configuration. This is useful for creating unique slug names for documents, and ensuring unique names for node siblings, or node names repository wide. It could be implemented as a sequence generator, or similar to how mongodb generates object ids; https://docs.mongodb.org/manual/reference/object-id/. With the older jackrabbit implementation it is possible to have a sequence guaranteed to provide unique id's, using enforceable locks. With oak theres no such guarantee when used in a clustered configuration. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (OAK-5591) oak-upgrade implicitly assume segmentstore subdirectory when performing repository migration
Torgeir Veimo created OAK-5591: -- Summary: oak-upgrade implicitly assume segmentstore subdirectory when performing repository migration Key: OAK-5591 URL: https://issues.apache.org/jira/browse/OAK-5591 Project: Jackrabbit Oak Issue Type: Bug Components: upgrade Affects Versions: 1.6.0 Reporter: Torgeir Veimo Priority: Minor Example oak-run command java -jar ./target/oak-upgrade-1.5.18.jar --copy-binaries \ segment-old:/Users/tor/content/oak/ \ /Users/tor/content/karriere/oak-16/ The tar files for the old repository is now assumed to be residing in /Users/tor/content/oak/segmentstore/, which isn't always the case. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (OAK-5215) remove use of deprecated guava methods
[ https://issues.apache.org/jira/browse/OAK-5215?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15742177#comment-15742177 ] Torgeir Veimo commented on OAK-5215: Does an issue remain a candidate for inclusion in a future 1.4.* release with the cadidate_oak_1_4 tag even when closed? > remove use of deprecated guava methods > -- > > Key: OAK-5215 > URL: https://issues.apache.org/jira/browse/OAK-5215 > Project: Jackrabbit Oak > Issue Type: Bug >Affects Versions: 1.4.10, 1.5.14 >Reporter: Torgeir Veimo >Assignee: Alex Parvulescu >Priority: Minor > Labels: candidate_oak_1_4 > Fix For: 1.6, 1.5.15 > > Attachments: OAK-5115.patch, guava.patch > > > When running in a non-osgi environment it's sometimes necessary to use a more > recent version of the guava dependency due to requirements of other > components. By changing the use of methods that are deprecated in later > version of guava, eg. v 19.0, it is possible to use any guava version between > 15.0 (current) and 19.0. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (OAK-5215) remove use of deprecated guava methods
[ https://issues.apache.org/jira/browse/OAK-5215?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15722293#comment-15722293 ] Torgeir Veimo commented on OAK-5215: Tried the patch on 1.4.10 and the tests all ran successfull, also with guava v19.0. CompositeDataStoreCacheTest and UploadStagingCacheTest are absent from 1.4.10 of course. Could this patch please be applied to the 1.4 series as well? > remove use of deprecated guava methods > -- > > Key: OAK-5215 > URL: https://issues.apache.org/jira/browse/OAK-5215 > Project: Jackrabbit Oak > Issue Type: Bug >Affects Versions: 1.4.10, 1.5.14 >Reporter: Torgeir Veimo >Priority: Minor > Attachments: OAK-5115.patch, guava.patch > > > When running in a non-osgi environment it's sometimes necessary to use a more > recent version of the guava dependency due to requirements of other > components. By changing the use of methods that are deprecated in later > version of guava, eg. v 19.0, it is possible to use any guava version between > 15.0 (current) and 19.0. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (OAK-5215) remove use of deprecated guava methods
[ https://issues.apache.org/jira/browse/OAK-5215?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Torgeir Veimo updated OAK-5215: --- Attachment: guava.patch Patch to remove use of deprecated methods. Can be tested by also changing the guava version to version 19.0; diff --git a/oak-parent/pom.xml b/oak-parent/pom.xml index fa4d47e..403302d 100644 --- a/oak-parent/pom.xml +++ b/oak-parent/pom.xml @@ -512,7 +512,7 @@ com.google.guava guava -15.0 +19.0 org.easymock > remove use of deprecated guava methods > -- > > Key: OAK-5215 > URL: https://issues.apache.org/jira/browse/OAK-5215 > Project: Jackrabbit Oak > Issue Type: Bug >Affects Versions: 1.4.10, 1.5.14 >Reporter: Torgeir Veimo >Priority: Minor > Attachments: guava.patch > > > When running in a non-osgi environment it's sometimes necessary to use a more > recent version of the guava dependency due to requirements of other > components. By changing the use of methods that are deprecated in later > version of guava, eg. v 19.0, it is possible to use any guava version between > 15.0 (current) and 19.0. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (OAK-5215) remove use of deprecated guava methods
Torgeir Veimo created OAK-5215: -- Summary: remove use of deprecated guava methods Key: OAK-5215 URL: https://issues.apache.org/jira/browse/OAK-5215 Project: Jackrabbit Oak Issue Type: Bug Affects Versions: 1.5.14, 1.4.10 Reporter: Torgeir Veimo Priority: Minor When running in a non-osgi environment it's sometimes necessary to use a more recent version of the guava dependency due to requirements of other components. By changing the use of methods that are deprecated in later version of guava, eg. v 19.0, it is possible to use any guava version between 15.0 (current) and 19.0. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (OAK-3150) Update Lucene to 5.x series
[ https://issues.apache.org/jira/browse/OAK-3150?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15351291#comment-15351291 ] Torgeir Veimo commented on OAK-3150: This would be extremely helpful in a non-osgi environment. Please don't resolve simply because noone asks about it on the ML. > Update Lucene to 5.x series > --- > > Key: OAK-3150 > URL: https://issues.apache.org/jira/browse/OAK-3150 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: lucene >Reporter: Chetan Mehrotra >Assignee: Chetan Mehrotra > Labels: technical_debt > > We should look into updating the Lucene version to 5.x. > Note this is to be done for trunk only -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (OAK-2736) Oak instance does not close the executors created upon ContentRepository creation
[ https://issues.apache.org/jira/browse/OAK-2736?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14661832#comment-14661832 ] Torgeir Veimo commented on OAK-2736: Sorry, spoke too soon; got 07-Aug-2015 23:32:33.061 WARNING [http-nio-8080-exec-8] org.apache.catalina.loader.WebappClassLoaderBase.clearReferencesThreads The web application [frontend] appears to have started a thread named [oak-repository-executor-1] but has failed to stop it. This is very likely to create a memory leak. Stack trace of thread: sun.misc.Unsafe.park(Native Method) java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:215) java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.awaitNanos(AbstractQueuedSynchronizer.java:2078) java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:1093) java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:809) java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1067) java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1127) java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) java.lang.Thread.run(Thread.java:745) I'll check again when the RepositoryImpl change is in the 1.4-snapshot. Oak instance does not close the executors created upon ContentRepository creation - Key: OAK-2736 URL: https://issues.apache.org/jira/browse/OAK-2736 Project: Jackrabbit Oak Issue Type: Bug Components: core Reporter: Chetan Mehrotra Assignee: Chetan Mehrotra Priority: Minor Labels: CI, Jenkins Fix For: 1.3.5 Attachments: OAK-2736-2.patch, OAK-2736.patch Oak.createContentRepository does not closes the executors it creates upon close. It should close the executor if that is created by itself and not passed by outside Also see recent [thread|http://markmail.org/thread/rryydj7vpua5qbub]. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (OAK-2736) Oak instance does not close the executors created upon ContentRepository creation
[ https://issues.apache.org/jira/browse/OAK-2736?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14662038#comment-14662038 ] Torgeir Veimo commented on OAK-2736: Looks good now with 1.4-SNAPSHOT. Oak instance does not close the executors created upon ContentRepository creation - Key: OAK-2736 URL: https://issues.apache.org/jira/browse/OAK-2736 Project: Jackrabbit Oak Issue Type: Bug Components: core Reporter: Chetan Mehrotra Assignee: Chetan Mehrotra Priority: Minor Labels: CI, Jenkins Fix For: 1.3.5 Attachments: OAK-2736-2.patch, OAK-2736.patch Oak.createContentRepository does not closes the executors it creates upon close. It should close the executor if that is created by itself and not passed by outside Also see recent [thread|http://markmail.org/thread/rryydj7vpua5qbub]. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (OAK-2736) Oak instance does not close the executors created upon ContentRepository creation
[ https://issues.apache.org/jira/browse/OAK-2736?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14661784#comment-14661784 ] Torgeir Veimo commented on OAK-2736: Just tried 1.4-SNAPSHOT now and there's no unclosed threads on webapp redeployment now, thx! Oak instance does not close the executors created upon ContentRepository creation - Key: OAK-2736 URL: https://issues.apache.org/jira/browse/OAK-2736 Project: Jackrabbit Oak Issue Type: Bug Components: core Reporter: Chetan Mehrotra Assignee: Chetan Mehrotra Priority: Minor Labels: CI, Jenkins Fix For: 1.3.5 Attachments: OAK-2736-2.patch, OAK-2736.patch Oak.createContentRepository does not closes the executors it creates upon close. It should close the executor if that is created by itself and not passed by outside Also see recent [thread|http://markmail.org/thread/rryydj7vpua5qbub]. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (OAK-2736) Oak instance does not close the executors created upon ContentRepository creation
[ https://issues.apache.org/jira/browse/OAK-2736?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14640091#comment-14640091 ] Torgeir Veimo commented on OAK-2736: Running oak 1.3.3 now results in much less warnings during webapp restart. There is one remaining thread though that is not closed, 24-Jul-2015 17:41:06.727 WARNING [http-nio-8080-exec-1] org.apache.catalina.loader.WebappClassLoaderBase.clearReferencesThreads The web application [frontend] appears to have started a thread named [oak-repository-executor-1] but has failed to stop it. This is very likely to create a memory leak. Stack trace of thread: sun.misc.Unsafe.park(Native Method) java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:215) Am not sure if this one would be covered by this fix, or if something needs to be configured differently to get this thread to be stopped. Oak instance does not close the executors created upon ContentRepository creation - Key: OAK-2736 URL: https://issues.apache.org/jira/browse/OAK-2736 Project: Jackrabbit Oak Issue Type: Bug Components: core Reporter: Chetan Mehrotra Assignee: Chetan Mehrotra Priority: Minor Labels: CI, Jenkins Fix For: 1.3.5 Attachments: OAK-2736-2.patch, OAK-2736.patch Oak.createContentRepository does not closes the executors it creates upon close. It should close the executor if that is created by itself and not passed by outside Also see recent [thread|http://markmail.org/thread/rryydj7vpua5qbub]. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (OAK-2736) Oak instance does not close the executors created upon ContentRepository creation
[ https://issues.apache.org/jira/browse/OAK-2736?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14493036#comment-14493036 ] Torgeir Veimo commented on OAK-2736: Any chance for a backport to the stable 1.2.* branch? Oak instance does not close the executors created upon ContentRepository creation - Key: OAK-2736 URL: https://issues.apache.org/jira/browse/OAK-2736 Project: Jackrabbit Oak Issue Type: Bug Components: core Reporter: Chetan Mehrotra Assignee: Chetan Mehrotra Priority: Minor Fix For: 1.3.0 Attachments: OAK-2736-2.patch, OAK-2736.patch Oak.createContentRepository does not closes the executors it creates upon close. It should close the executor if that is created by itself and not passed by outside Also see recent [thread|http://markmail.org/thread/rryydj7vpua5qbub]. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (OAK-2741) oak shutdown, unstopped threads
Torgeir Veimo created OAK-2741: -- Summary: oak shutdown, unstopped threads Key: OAK-2741 URL: https://issues.apache.org/jira/browse/OAK-2741 Project: Jackrabbit Oak Issue Type: Bug Environment: tomcat 7.0.59, 8.0.21, OSX, Reporter: Torgeir Veimo I run oak in a non-osgi environment (tomcat) and am seeing these on webapp reload; SEVERE: The web application [/frontend] appears to have started a thread named [oak-scheduled-executor-274] but has failed to stop it. This is very likely to create a memory leak. Apr 07, 2015 2:27:20 PM org.apache.catalina.loader.WebappClassLoader clearReferencesThreads [...] There's 32 of them, which roughly corresponds to the number of indexes I've configured (27 custom indexes + 5). The repository is constructed as private Repository oakRepository; private SegmentStore segmentStore; segmentStore = new FileStore(new File(oakRepositoryPath), 256); NodeStore nodeStore = new SegmentNodeStore(segmentStore); oakRepository = new Jcr(nodeStore) .with(new LocalInitialContent()) .withAsyncIndexing() .createRepository(); and shut down using ((RepositoryImpl)oakRepository).shutdown(); segmentStore.close(); Chetan Mehrotra says: This looks like the pool of 32 threads created in Oak.defaultScheduledExecutor which is not shutdown when content repository is closed (L587 in Oak class). In many cases the executor is provided from outside so close logic needs to take care if the executor is created by itself then it should be closed also. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (OAK-1930) New method RangeIterator.getSize(int max)
[ https://issues.apache.org/jira/browse/OAK-1930?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14312267#comment-14312267 ] Torgeir Veimo commented on OAK-1930: Having a method where oak internally can optimally getting the size would probably be faster than doing a lot of object instantiation, just to count then and then discard them. New method RangeIterator.getSize(int max) - Key: OAK-1930 URL: https://issues.apache.org/jira/browse/OAK-1930 Project: Jackrabbit Oak Issue Type: New Feature Components: core, jcr, query Affects Versions: 1.0 Reporter: Thomas Mueller Assignee: Thomas Mueller Priority: Minor Fix For: 1.2 The method RangeIterator.getSize() is part of the JCR API, and returns the number of items, but can also return -1 if not known. Currently, Oak doesn't return -1, but counts the items. This is slow (potentially very slow) if there are many items, for example, in a query result. I propose to add a new method RangeIterator.getSize(long max) that limits counting the entries. That way, an application can use a reasonable limit, and Oak doesn't need to count. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (OAK-1996) let 'order by @jcr:score' trigger automatic result set size calculation
[ https://issues.apache.org/jira/browse/OAK-1996?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14099497#comment-14099497 ] Torgeir Veimo commented on OAK-1996: Maybe there could be a flag to set at repository init that triggered better compatibility with jackrabbit apps? let 'order by @jcr:score' trigger automatic result set size calculation --- Key: OAK-1996 URL: https://issues.apache.org/jira/browse/OAK-1996 Project: Jackrabbit Oak Issue Type: Improvement Components: query Affects Versions: 1.0.3 Reporter: Torgeir Veimo It would probably be a good idea to make the order by @jcr:score suffix trigger automatic result set size calculation in getSize() for better backwards compatibility. This would make oak more compatible with applications relying on this behaviour from jackrabbit 2.8 and earlier. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Created] (OAK-1996) let 'order by @jcr:score' trigger automatic result set size calculation
Torgeir Veimo created OAK-1996: -- Summary: let 'order by @jcr:score' trigger automatic result set size calculation Key: OAK-1996 URL: https://issues.apache.org/jira/browse/OAK-1996 Project: Jackrabbit Oak Issue Type: Improvement Components: query Affects Versions: 1.0.3 Reporter: Torgeir Veimo It would probably be a good idea to make the order by @jcr:score suffix trigger automatic result set size calculation in getSize() for better backwards compatibility. This would make oak more compatible with applications relying on this behaviour from jackrabbit 2.8 and earlier. -- This message was sent by Atlassian JIRA (v6.2#6252)
