Re: [VOTE] Release Apache Jackrabbit Oak Segment Tar version 0.0.6

[Alex Parvulescu]

[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

[Michael Dürig]

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

[Francesco Mari]

+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

[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.

Oak 1.5.6 release plan

[Davide Giannella]

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)

[Chetan Mehrotra]

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)

[Stefan Egli]

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)

[Vikas Saurabh]

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)

[Chetan Mehrotra]

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)

[Michael Dürig]

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

[Dominique Jaeggi]

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

[Dominique Jaeggi]

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)

[Chetan Mehrotra]

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)

[Michael Dürig]

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