Re: [VOTE] Release Apache Jackrabbit Oak Segment Tar version 0.0.6
[X] +1 Approve the release alex On Tue, Jul 19, 2016 at 4:00 PM, Francesco Mari wrote: > Hi, > > We solved 5 issues in this release: > https://issues.apache.org/jira/browse/OAK/fixforversion/12337966 > > There are still some outstanding issues: > https://issues.apache.org/jira/browse/OAK/component/12329487 > > Staging repository: > https://repository.apache.org/content/repositories/orgapachejackrabbit-1162 > > You can use this UNIX script to download the release and verify the > signatures: > > http://svn.apache.org/repos/asf/jackrabbit/oak/trunk/check_staged_release.sh > > Usage: > sh check_staged_release.sh 1162 /tmp/oak-staging > > Please vote to approve this release: > > [ ] +1 Approve the release > [ ] 0 Don't care > [ ] -1 Don't release, because ... > > This majority vote is open for at least 72 hours. >
Re: [VOTE] Release Apache Jackrabbit Oak Segment Tar version 0.0.6
On 19.7.16 4:00 , Francesco Mari wrote: [X] +1 Approve the release Michael
Re: [VOTE] Release Apache Jackrabbit Oak Segment Tar version 0.0.6
+1 2016-07-19 16:00 GMT+02:00 Francesco Mari : > Hi, > > We solved 5 issues in this release: > https://issues.apache.org/jira/browse/OAK/fixforversion/12337966 > > There are still some outstanding issues: > https://issues.apache.org/jira/browse/OAK/component/12329487 > > Staging repository: > https://repository.apache.org/content/repositories/orgapachejackrabbit-1162 > > You can use this UNIX script to download the release and verify the > signatures: > > http://svn.apache.org/repos/asf/jackrabbit/oak/trunk/check_staged_release.sh > > Usage: > sh check_staged_release.sh 1162 /tmp/oak-staging > > Please vote to approve this release: > > [ ] +1 Approve the release > [ ] 0 Don't care > [ ] -1 Don't release, because ... > > This majority vote is open for at least 72 hours. > >
[VOTE] Release Apache Jackrabbit Oak Segment Tar version 0.0.6
Hi, We solved 5 issues in this release: https://issues.apache.org/jira/browse/OAK/fixforversion/12337966 There are still some outstanding issues: https://issues.apache.org/jira/browse/OAK/component/12329487 Staging repository: https://repository.apache.org/content/repositories/orgapachejackrabbit-1162 You can use this UNIX script to download the release and verify the signatures: http://svn.apache.org/repos/asf/jackrabbit/oak/trunk/check_staged_release.sh Usage: sh check_staged_release.sh 1162 /tmp/oak-staging Please vote to approve this release: [ ] +1 Approve the release [ ] 0 Don't care [ ] -1 Don't release, because ... This majority vote is open for at least 72 hours.
Oak 1.5.6 release plan
Hello team, I'm planning to cut Oak 1.5.6 today in the afternoon british time. If there are any objections please let me know. Otherwise I will re-schedule any non-resolved issue for the next iteration. Sorry for late notice. Thanks Davide
Re: Specifying threadpool name for periodic scheduled jobs (OAK-4563)
On Tue, Jul 19, 2016 at 1:44 PM, Stefan Egli wrote: > I'd go for #A to limit cross-effects between oak and other layers. Note that for #4 there can be multiple task scheduled. So if a system has 100 JCR Listeners than there would be 1 task/listener to manage the time series stats. These should be quick and non blocking though. All other task are much more critical for repository to function properly. Hence thoughts to go for #B where we have a dedicated pool for those 'n' tasks. Where n is much small i.e. number of async lanes + 2 from DocumentNodeStore so far. So its easy to size Chetan Mehrotra
Re: Specifying threadpool name for periodic scheduled jobs (OAK-4563)
I'd go for #A to limit cross-effects between oak and other layers. The reason one would want to use the default pool for #4 is probably the idea that you'd want to avoid "wasting" a thread in the oak-thread-pool and rather rely on a shared one. But arguably, that should be an optimization of the thread pool provider itself: that provider could be more intelligent and allocate threads from an under-used pool elsewhere - if that were more performant. But from a logical point of view, I'd argue it's better to have an oak-dedicated thread-pool. Cheers, Stefan On 19/07/16 10:06, "Chetan Mehrotra" wrote: >On Tue, Jul 19, 2016 at 1:21 PM, Michael Dürig wrote: >> Not sure as I'm confused by your description of that option. I don't >> understand which of 1, 2, 3 and 4 would run in the "default pool" and >>which >> should run in its own dedicated pool. > >#1, #2 and #3 would run in dedicated pool and each using same pool. >Pool name would be 'oak'. Also see OAK-4563 for the patch > >While for #4 default pool would be used as those are non blocking and >short tasks > >Chetan Mehrotra
Re: Specifying threadpool name for periodic scheduled jobs (OAK-4563)
Hi, > Now should we use > > A - one single pool for all of the above > B - use the pool only for 1-3. The default pool would be of 5. So even > if #2 #3 are running > it would not hamper #1 While I'd want option#B to a better option, but I'd like to add one quick bit - we'd need to also take care of that async indexing itself could "potentially" require multiple tasks (lanes?? in async indexing terminology). While 5 threads would still take care of 3 async indexing lanes + task#2 + task#3. But, I wonder, if we should further split as async-index-pool (tasks for #1), background-jobs-pool (#2, #3, maybe more??), #4 probably goes into default-pool. Thanks, Vikas PS: the assumption is that async indexing task can "potentially" take time (e.g. if there's binary extraction in the picture) + number of async indexing lanes is configurable at repository creation time
Re: Specifying threadpool name for periodic scheduled jobs (OAK-4563)
On Tue, Jul 19, 2016 at 1:21 PM, Michael Dürig wrote: > Not sure as I'm confused by your description of that option. I don't > understand which of 1, 2, 3 and 4 would run in the "default pool" and which > should run in its own dedicated pool. #1, #2 and #3 would run in dedicated pool and each using same pool. Pool name would be 'oak'. Also see OAK-4563 for the patch While for #4 default pool would be used as those are non blocking and short tasks Chetan Mehrotra
Re: Specifying threadpool name for periodic scheduled jobs (OAK-4563)
On 19.7.16 9:26 , Chetan Mehrotra wrote: On Tue, Jul 19, 2016 at 12:54 PM, Michael Dürig wrote: For blocking or time intensive tasks I would go for a dedicated thread pool. So wrt current issue that means option #B ? Not sure as I'm confused by your description of that option. I don't understand which of 1, 2, 3 and 4 would run in the "default pool" and which should run in its own dedicated pool. Michael Chetan Mehrotra
[ANNOUNCE] Apache Jackrabbit Oak 1.4.5 released
The Apache Jackrabbit community is pleased to announce the release of Apache Jackrabbit Oak 1.4.5 The release is available for download at: http://jackrabbit.apache.org/downloads.html See the full release notes below for details about this release: Release Notes -- Apache Jackrabbit Oak -- Version 1.4.5 Introduction Jackrabbit Oak is a scalable, high-performance hierarchical content repository designed for use as the foundation of modern world-class web sites and other demanding content applications. Jackrabbit Oak 1.4.5 is a patch release that contains fixes and improvements over Oak 1.4. Jackrabbit Oak 1.4.x releases are considered stable and targeted for production use. The Oak effort is a part of the Apache Jackrabbit project. Apache Jackrabbit is a project of the Apache Software Foundation. Changes in Oak 1.4.5 - Technical task [OAK-4509] - RDBDocumentStore: low-level read method should also support condition on MODIFIED value [OAK-4510] - RDBDocumentStore: can't persist _modified value of null Bug [OAK-4494] - Stale documents after revision GC in cluster [OAK-4502] - LucenePropertyIndex doesn't use filter's path for ACL checks of suggest queries [OAK-4515] - Catch NPE and log serverResult in MongoDocumentStore.determineServerTimeDifferenceMillis [OAK-4538] - IndexDefinition.createCodec class loading deadlock [OAK-4548] - SegmentDataStoreBlobGCIT failures Improvement [OAK-3797] - SegmentTracker#collectBlobReferences should retain fewer SegmentId instances [OAK-4514] - ResurrectNodeAfterRevisionGCTest's cleanup may interfere with DS disposal [OAK-4542] - PerfLogger should also allow a threshold to log at INFO [OAK-4545] - Configurable maxBackOffMillis In addition to the above-mentioned changes, this release contains all changes included up to the Apache Jackrabbit Oak 1.4.x release. For more detailed information about all the changes in this and other Oak releases, please see the Oak issue tracker at https://issues.apache.org/jira/browse/OAK Release Contents This release consists of a single source archive packaged as a zip file. The archive can be unpacked with the jar tool from your JDK installation. See the README.md file for instructions on how to build this release. The source archive is accompanied by SHA1 and MD5 checksums and a PGP signature that you can use to verify the authenticity of your download. The public key used for the PGP signature can be found at http://www.apache.org/dist/jackrabbit/KEYS. About Apache Jackrabbit Oak --- Jackrabbit Oak is a scalable, high-performance hierarchical content repository designed for use as the foundation of modern world-class web sites and other demanding content applications. The Oak effort is a part of the Apache Jackrabbit project. Apache Jackrabbit is a project of the Apache Software Foundation. For more information, visit http://jackrabbit.apache.org/oak About The Apache Software Foundation Established in 1999, The Apache Software Foundation provides organizational, legal, and financial support for more than 140 freely-available, collaboratively-developed Open Source projects. The pragmatic Apache License enables individual and commercial users to easily deploy Apache software; the Foundation's intellectual property framework limits the legal exposure of its 3,800+ contributors. For more information, visit http://www.apache.org/
[RESULT][VOTE] Release Apache Jackrabbit Oak 1.4.5
Hello Team, The vote passes as follows: +1 Marcel Reutegger +1 Vikas Saurabh +1 Dominique Jäggi Thanks for voting. I'll push the release out. -- Davide
Re: Specifying threadpool name for periodic scheduled jobs (OAK-4563)
On Tue, Jul 19, 2016 at 12:54 PM, Michael Dürig wrote: > For blocking or time intensive tasks I would go for a dedicated thread pool. So wrt current issue that means option #B ? Chetan Mehrotra
Re: Specifying threadpool name for periodic scheduled jobs (OAK-4563)
On 19.7.16 6:55 , Chetan Mehrotra wrote: Now currently in Oak we use following types of periodic jobs 1. Async indexing - (Cluster Singleton) 2. Document Store - Journal GC (Cluster Singleton) 3. Document Store - LastRevRecovery 4. Statistic Collection - For timeseries data update in ChangeProcessor, SegmentNodeStore GCMonitor Now should we use A - one single pool for all of the above B - use the pool only for 1-3. The default pool would be of 5. So even if #2 #3 are running it would not hamper #1 Assuming #4 is not that critical to run and may consist of lots of jobs. My suggestion would be to go for #B In general I would use a common single thread pool for short, non-blocking tasks. For blocking or time intensive tasks I would go for a dedicated thread pool. Even better I wouldn't waste threads for blocking tasks but structure the overall computation in a non blocking way. This is a different topic though... Michael
