[jira] [Resolved] (OAK-7614) Update Oak trunk to Jackrabbit 2.17.4

[Julian Reschke (JIRA)]

 [ 
https://issues.apache.org/jira/browse/OAK-7614?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Julian Reschke resolved OAK-7614.
-
   Resolution: Fixed
Fix Version/s: 1.9.6

> Update Oak trunk to Jackrabbit 2.17.4
> -
>
> Key: OAK-7614
> URL: https://issues.apache.org/jira/browse/OAK-7614
> Project: Jackrabbit Oak
>  Issue Type: Task
>  Components: parent
>Reporter: Julian Reschke
>Assignee: Julian Reschke
>Priority: Minor
> Fix For: 1.9.6
>
>




--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Created] (OAK-7631) Update Oak 1.0 to Jackrabbit 2.8.9

[Julian Reschke (JIRA)]

Julian Reschke created OAK-7631:
---

 Summary: Update Oak 1.0 to Jackrabbit 2.8.9
 Key: OAK-7631
 URL: https://issues.apache.org/jira/browse/OAK-7631
 Project: Jackrabbit Oak
  Issue Type: Task
  Components: parent
Reporter: Julian Reschke
Assignee: Julian Reschke






--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Created] (OAK-7632) remove JSR 305 annotations in Groovy code

[Julian Reschke (JIRA)]

Julian Reschke created OAK-7632:
---

 Summary: remove JSR 305 annotations in Groovy code
 Key: OAK-7632
 URL: https://issues.apache.org/jira/browse/OAK-7632
 Project: Jackrabbit Oak
  Issue Type: Technical task
  Components: oak-run, pojosr
Reporter: Julian Reschke
Assignee: Julian Reschke
 Fix For: 1.10


Replacing them with Jetbrains annotations compiles, but leads to test failures 
at runtime, potentially because of different retention behavior.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (OAK-7246) Improve cleanup of locally copied index files

[Vikas Saurabh (JIRA)]

[ 
https://issues.apache.org/jira/browse/OAK-7246?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16542897#comment-16542897
 ] 

Vikas Saurabh commented on OAK-7246:


Further investigation revealed that the issue can occur in even simpler 
timeline:
# CoW2 starts and finished with updating index at R2 - it adds fileX
# CoR is lagging just a little bit and hence CoR1 opens viewing R1 (rev before 
CoW2).
#* It sees fileX created by CoW2 on local disk
#* fileX is not visible at R1
#* since CoW2 is already done, the shared set of files being currently written 
is empty
# CoR2 opens at R2 and CoR1 closes
# While closing CoR1 would delete fileX as it had seen it on local disk while 
opening and it wasn't in shared set nor was it visible on R1

Deletions are asynchronous, so depending on when deletion gets scheduled, we 
can see differing behaviors (usually WARNs) due to incorrectly deleted local 
file

An actual log snipped depicting the above timeline looks like:
{noformat}
// CoW creates the file
03.07.2018 09:18:13.928 *DEBUG* [async-index-update-async] 
org.apache.jackrabbit.oak.plugins.index.lucene.directory.CopyOnWriteDirectory 
[COW][/oak:index/cqPageLucene] Creating output . segments_2k4e 
...
// CoW closes
03.07.2018 09:18:14.073 *TRACE* [async-index-update-async] 
org.apache.jackrabbit.oak.plugins.index.lucene.directory.CopyOnWriteDirectory 
[COW][/oak:index/cqPageLucene] File listing - Upon completion [, 
segments_2k4e]
// CoR1 opens and doesn't see segments_2k4e on the revision it's working on
03.07.2018 09:18:14.274 *TRACE* [oak-lucene-125] 
org.apache.jackrabbit.oak.plugins.index.lucene.directory.CopyOnReadDirectory 
[/oak:index/cqPageLucene] found local copy of file  
bunch.of.files.but.not.one.of.those.being.segments_2k4e 
...

// This is from async deletion likely from closing of old reader
03.07.2018 09:18:14.371 *DEBUG* [oak-lucene-125] 
org.apache.jackrabbit.oak.plugins.index.lucene.directory.CopyOnReadDirectory 
[/oak:index/cqPageLucene] Following files have been removed from Lucene index 
directory [  bunch.of.files.but.not.one.of.those.being.segments_2k4e ]
// CoR2 opens and sees segments_2k4e
03.07.2018 09:18:14.392 *TRACE* [oak-lucene-123] 
org.apache.jackrabbit.oak.plugins.index.lucene.directory.CopyOnReadDirectory 
[/oak:index/cqPageLucene] found local copy of file  segments_2k4e  


// Most likely deletion due to close of CoR1 - note, CoR1 saw segments_2k4e on 
local disk but not on its revision. And since CoW was already close, shared 
working set was also empty
03.07.2018 09:18:14.559 *DEBUG* [oak-lucene-123] 
org.apache.jackrabbit.oak.plugins.index.lucene.directory.CopyOnReadDirectory 
[/oak:index/cqPageLucene] Following files have been removed from Lucene index 
directory [, segments_2k4e, ]
...
// Next CoW opens and complaints that it didn't find the file locally
03.07.2018 09:18:23.319 *TRACE* [async-index-update-async] 
org.apache.jackrabbit.oak.plugins.index.lucene.directory.CopyOnWriteDirectory 
[COW][/oak:index/cqPageLucene] File listing - At start [, segments_2k4e]
03.07.2018 09:18:23.319 *WARN* [async-index-update-async] 
org.apache.jackrabbit.oak.plugins.index.lucene.directory.CopyOnWriteDirectory 
COWRemoteFileReference::local file (segments_2k4e) doesn't exist
{noformat}
_Note_: The log is edited a bit for better readability... order of logs are 
consistent though.

> Improve cleanup of locally copied index files
> -
>
> Key: OAK-7246
> URL: https://issues.apache.org/jira/browse/OAK-7246
> Project: Jackrabbit Oak
>  Issue Type: Improvement
>  Components: lucene
>Reporter: Vikas Saurabh
>Assignee: Vikas Saurabh
>Priority: Major
>
> This task is to re-think how should we do clean up of locally copied index 
> files which are no longer in use.
> Current approach:
> # index writers, while creating index files, keep list of 
> currently-being-written files
> ## this list is cleared when a new index writer comes into play
> # index tracker opens new index (at new revision) via observation
> ## while being opened, we also track current dir listing of the local index 
> files
> # during opening new index, the tracker closes the old revision of index 
> reader
> ## during this close, local files noted above during open are purged if ( 
> they don't show up in remote view of the index && they aren't part of 
> currently being written list by index writer)
> This approach, at least in following timeline, would incur extra copying (and 
> as a side-effect also open some index files directly off of remote input 
> stream during CoWs):
> # CoW1 creates [a, b]
> # CoW2 starts and creates [c, d], removes [a, b] from remote
> # CoR1 opens an index due to CoW1
> ## local-list-CoR1 = [a, b, c, d], remote-index-l

[jira] [Commented] (OAK-7618) Build Jackrabbit Oak #1532 failed

[Hudson (JIRA)]

[ 
https://issues.apache.org/jira/browse/OAK-7618?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16542928#comment-16542928
 ] 

Hudson commented on OAK-7618:
-

Previously failing build now is OK.
 Passed run: [Jackrabbit Oak 
#1542|https://builds.apache.org/job/Jackrabbit%20Oak/1542/] [console 
log|https://builds.apache.org/job/Jackrabbit%20Oak/1542/console]

> Build Jackrabbit Oak #1532 failed
> -
>
> Key: OAK-7618
> URL: https://issues.apache.org/jira/browse/OAK-7618
> Project: Jackrabbit Oak
>  Issue Type: Bug
>  Components: continuous integration
>Reporter: Hudson
>Priority: Major
>
> No description is provided
> The build Jackrabbit Oak #1532 has failed.
> First failed run: [Jackrabbit Oak 
> #1532|https://builds.apache.org/job/Jackrabbit%20Oak/1532/] [console 
> log|https://builds.apache.org/job/Jackrabbit%20Oak/1532/console]



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (OAK-7632) remove JSR 305 annotations in Groovy code

[Julian Reschke (JIRA)]

[ 
https://issues.apache.org/jira/browse/OAK-7632?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16542945#comment-16542945
 ] 

Julian Reschke commented on OAK-7632:
-

trunk: [r1835819|http://svn.apache.org/r1835819]

> remove JSR 305 annotations in Groovy code
> -
>
> Key: OAK-7632
> URL: https://issues.apache.org/jira/browse/OAK-7632
> Project: Jackrabbit Oak
>  Issue Type: Technical task
>  Components: oak-run, pojosr
>Reporter: Julian Reschke
>Assignee: Julian Reschke
>Priority: Minor
> Fix For: 1.10
>
>
> Replacing them with Jetbrains annotations compiles, but leads to test 
> failures at runtime, potentially because of different retention behavior.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (OAK-7246) Improve cleanup of locally copied index files

[Vikas Saurabh (JIRA)]

[ 
https://issues.apache.org/jira/browse/OAK-7246?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16542944#comment-16542944
 ] 

Vikas Saurabh commented on OAK-7246:


Discussed this a bit with [~tmueller] and [~chetanm] for a simpler and safer 
approach to fix clean up. We need this constraint to hold - only files which 
would not longer be required should be deleted

Given how files are created on local disk (due to CoR or CoW), we'd (probably 
fairly) assume these:
* creation timestamps of local files would follow the same sequence as 
revisions being observed(CoR)/created(CoW)
* files created before any of the files visible to a closing reader won't be 
required in the future (it's basically a corollary of the point above - but is 
still important to state explicitly)

Given these, a simple approach for clean up could be that the closing readers, 
while being closed, schedules deletion of files resulting from following steps:
# get timestamps of local files which are visible on its revision - set max of 
these timestamps as T ~max~
# get set of local files as S ~local~
# subtract files visible on its revision from S ~local~ to get S ~candidate~
# filter S ~candidate~ by "keep if {{creation timestamp}} < T ~max~ to get S 
~delete~
# schedule files listed in S ~delete~ to be deleted

With this approach, we can entirely get rid of shared set being maintained by 
writers. Similarly, we don't need to maintain {{localFileNames}} in 
{{CopyOnReadDirectory}} as a snapshot of files available locally when the 
reader was being opened.

> Improve cleanup of locally copied index files
> -
>
> Key: OAK-7246
> URL: https://issues.apache.org/jira/browse/OAK-7246
> Project: Jackrabbit Oak
>  Issue Type: Improvement
>  Components: lucene
>Reporter: Vikas Saurabh
>Assignee: Vikas Saurabh
>Priority: Major
>
> This task is to re-think how should we do clean up of locally copied index 
> files which are no longer in use.
> Current approach:
> # index writers, while creating index files, keep list of 
> currently-being-written files
> ## this list is cleared when a new index writer comes into play
> # index tracker opens new index (at new revision) via observation
> ## while being opened, we also track current dir listing of the local index 
> files
> # during opening new index, the tracker closes the old revision of index 
> reader
> ## during this close, local files noted above during open are purged if ( 
> they don't show up in remote view of the index && they aren't part of 
> currently being written list by index writer)
> This approach, at least in following timeline, would incur extra copying (and 
> as a side-effect also open some index files directly off of remote input 
> stream during CoWs):
> # CoW1 creates [a, b]
> # CoW2 starts and creates [c, d], removes [a, b] from remote
> # CoR1 opens an index due to CoW1
> ## local-list-CoR1 = [a, b, c, d], remote-index-list=[a, b]
> # CoW2 finishes
> # CoW3 creates [e, f], removes [a,b] from remote
> ## CoW-currently-being-written-list=[e,f]
> # CoR2 opens due to CoW2
> ## local-list-CoR2=[a,b,c,d,e,f], remote-index-list=[c,d]
> # CoR1 closes
> ## deletes [c,d] as they aren't in its list of index files ([a,b]) AND aren't 
> part of shared list ([e,f])
> Disclaimer: the timeline might be off a bit (haven't written a test yet... 
> but the basic point is that CoR could be working with a index file set and 
> the new files might have come in twice after CoR - thus shared list doesn't 
> have complete information of new files written in.
> [~chetanm], can you please check the timeline above - I'd try to work on a 
> test case in the mean time.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Comment Edited] (OAK-7246) Improve cleanup of locally copied index files

[Vikas Saurabh (JIRA)]

[ 
https://issues.apache.org/jira/browse/OAK-7246?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16542944#comment-16542944
 ] 

Vikas Saurabh edited comment on OAK-7246 at 7/13/18 11:52 AM:
--

Discussed this a bit with [~tmueller] and [~chetanm] for a simpler and safer 
approach to fix clean up. We need this constraint to hold - only files which 
would not longer be required should be deleted

Given how files are created on local disk (due to CoR or CoW), we'd (probably 
fairly) assume these:
* filesystems have a trustworthy notion of time that gets put in creation 
timestamp
* creation timestamps of local files would follow the same sequence as 
revisions being observed(CoR)/created(CoW)
* files created before any of the files visible to a closing reader won't be 
required in the future (it's basically a corollary of the point above - but is 
still important to state explicitly)

Given these, a simple approach for clean up could be that the closing readers, 
while being closed, schedules deletion of files resulting from following steps:
# get timestamps of local files which are visible on its revision - set max of 
these timestamps as T ~max~
# get set of local files as S ~local~
# subtract files visible on its revision from S ~local~ to get S ~candidate~
# filter S ~candidate~ by "keep if {{creation timestamp}} < T ~max~ to get S 
~delete~
# schedule files listed in S ~delete~ to be deleted

With this approach, we can entirely get rid of shared set being maintained by 
writers. Similarly, we don't need to maintain {{localFileNames}} in 
{{CopyOnReadDirectory}} as a snapshot of files available locally when the 
reader was being opened.


was (Author: catholicon):
Discussed this a bit with [~tmueller] and [~chetanm] for a simpler and safer 
approach to fix clean up. We need this constraint to hold - only files which 
would not longer be required should be deleted

Given how files are created on local disk (due to CoR or CoW), we'd (probably 
fairly) assume these:
* creation timestamps of local files would follow the same sequence as 
revisions being observed(CoR)/created(CoW)
* files created before any of the files visible to a closing reader won't be 
required in the future (it's basically a corollary of the point above - but is 
still important to state explicitly)

Given these, a simple approach for clean up could be that the closing readers, 
while being closed, schedules deletion of files resulting from following steps:
# get timestamps of local files which are visible on its revision - set max of 
these timestamps as T ~max~
# get set of local files as S ~local~
# subtract files visible on its revision from S ~local~ to get S ~candidate~
# filter S ~candidate~ by "keep if {{creation timestamp}} < T ~max~ to get S 
~delete~
# schedule files listed in S ~delete~ to be deleted

With this approach, we can entirely get rid of shared set being maintained by 
writers. Similarly, we don't need to maintain {{localFileNames}} in 
{{CopyOnReadDirectory}} as a snapshot of files available locally when the 
reader was being opened.

> Improve cleanup of locally copied index files
> -
>
> Key: OAK-7246
> URL: https://issues.apache.org/jira/browse/OAK-7246
> Project: Jackrabbit Oak
>  Issue Type: Improvement
>  Components: lucene
>Reporter: Vikas Saurabh
>Assignee: Vikas Saurabh
>Priority: Major
>
> This task is to re-think how should we do clean up of locally copied index 
> files which are no longer in use.
> Current approach:
> # index writers, while creating index files, keep list of 
> currently-being-written files
> ## this list is cleared when a new index writer comes into play
> # index tracker opens new index (at new revision) via observation
> ## while being opened, we also track current dir listing of the local index 
> files
> # during opening new index, the tracker closes the old revision of index 
> reader
> ## during this close, local files noted above during open are purged if ( 
> they don't show up in remote view of the index && they aren't part of 
> currently being written list by index writer)
> This approach, at least in following timeline, would incur extra copying (and 
> as a side-effect also open some index files directly off of remote input 
> stream during CoWs):
> # CoW1 creates [a, b]
> # CoW2 starts and creates [c, d], removes [a, b] from remote
> # CoR1 opens an index due to CoW1
> ## local-list-CoR1 = [a, b, c, d], remote-index-list=[a, b]
> # CoW2 finishes
> # CoW3 creates [e, f], removes [a,b] from remote
> ## CoW-currently-being-written-list=[e,f]
> # CoR2 opens due to CoW2
> ## local-list-CoR2=[a,b,c,d,e,f], remote-index-list=[c,d]
> # CoR1 closes
> ## deletes [c,d] as they aren't in its list of index files ([a,b]) AND aren't 
> part of 

[jira] [Comment Edited] (OAK-7246) Improve cleanup of locally copied index files

[Vikas Saurabh (JIRA)]

[ 
https://issues.apache.org/jira/browse/OAK-7246?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16542944#comment-16542944
 ] 

Vikas Saurabh edited comment on OAK-7246 at 7/13/18 11:57 AM:
--

Discussed this a bit with [~tmueller] and [~chetanm] for a simpler and safer 
approach to fix clean up. We need this constraint to hold - only files which 
would not longer be required should be deleted

Given how files are created on local disk (due to CoR or CoW), we'd (probably 
fairly) assume these:
* filesystems have a trustworthy notion of time that gets put in creation 
timestamp
* creation timestamps of local files would follow the same sequence as 
revisions being observed(CoR)/created(CoW)
* files created before any of the files visible to a closing reader won't be 
required in the future (it's basically a corollary of the point above - but is 
still important to state explicitly)

Given these, a simple approach for clean up could be that the closing readers, 
while being closed, schedules deletion of files resulting from following steps:
# get timestamps of local files which are visible on its revision - set max of 
these timestamps as T ~max~
# get set of local files as S ~local~
# subtract files visible on its revision from S ~local~ to get S ~candidate~
# filter S ~candidate~ as keep if {{creation timestamp}} < ( T ~max~ - 5 
minutes) to get S ~delete~
#* The 5 minute buffer time is just for safely... and maybe we'd want it to be 
tunable by command line parameter
# schedule files listed in S ~delete~ to be deleted

With this approach, we can entirely get rid of shared set being maintained by 
writers. Similarly, we don't need to maintain {{localFileNames}} in 
{{CopyOnReadDirectory}} as a snapshot of files available locally when the 
reader was being opened.


was (Author: catholicon):
Discussed this a bit with [~tmueller] and [~chetanm] for a simpler and safer 
approach to fix clean up. We need this constraint to hold - only files which 
would not longer be required should be deleted

Given how files are created on local disk (due to CoR or CoW), we'd (probably 
fairly) assume these:
* filesystems have a trustworthy notion of time that gets put in creation 
timestamp
* creation timestamps of local files would follow the same sequence as 
revisions being observed(CoR)/created(CoW)
* files created before any of the files visible to a closing reader won't be 
required in the future (it's basically a corollary of the point above - but is 
still important to state explicitly)

Given these, a simple approach for clean up could be that the closing readers, 
while being closed, schedules deletion of files resulting from following steps:
# get timestamps of local files which are visible on its revision - set max of 
these timestamps as T ~max~
# get set of local files as S ~local~
# subtract files visible on its revision from S ~local~ to get S ~candidate~
# filter S ~candidate~ by "keep if {{creation timestamp}} < T ~max~ to get S 
~delete~
# schedule files listed in S ~delete~ to be deleted

With this approach, we can entirely get rid of shared set being maintained by 
writers. Similarly, we don't need to maintain {{localFileNames}} in 
{{CopyOnReadDirectory}} as a snapshot of files available locally when the 
reader was being opened.

> Improve cleanup of locally copied index files
> -
>
> Key: OAK-7246
> URL: https://issues.apache.org/jira/browse/OAK-7246
> Project: Jackrabbit Oak
>  Issue Type: Improvement
>  Components: lucene
>Reporter: Vikas Saurabh
>Assignee: Vikas Saurabh
>Priority: Major
>
> This task is to re-think how should we do clean up of locally copied index 
> files which are no longer in use.
> Current approach:
> # index writers, while creating index files, keep list of 
> currently-being-written files
> ## this list is cleared when a new index writer comes into play
> # index tracker opens new index (at new revision) via observation
> ## while being opened, we also track current dir listing of the local index 
> files
> # during opening new index, the tracker closes the old revision of index 
> reader
> ## during this close, local files noted above during open are purged if ( 
> they don't show up in remote view of the index && they aren't part of 
> currently being written list by index writer)
> This approach, at least in following timeline, would incur extra copying (and 
> as a side-effect also open some index files directly off of remote input 
> stream during CoWs):
> # CoW1 creates [a, b]
> # CoW2 starts and creates [c, d], removes [a, b] from remote
> # CoR1 opens an index due to CoW1
> ## local-list-CoR1 = [a, b, c, d], remote-index-list=[a, b]
> # CoW2 finishes
> # CoW3 creates [e, f], removes [a,b] from remote
> ## CoW-currently-being-

[jira] [Updated] (OAK-6770) Convert oak-segment-tar to OSGi R6 annotations

[Francesco Mari (JIRA)]

 [ 
https://issues.apache.org/jira/browse/OAK-6770?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Francesco Mari updated OAK-6770:

Attachment: OAK-6770-01.patch

> Convert oak-segment-tar to OSGi R6 annotations
> --
>
> Key: OAK-6770
> URL: https://issues.apache.org/jira/browse/OAK-6770
> Project: Jackrabbit Oak
>  Issue Type: Technical task
>  Components: segment-tar
>Reporter: Robert Munteanu
>Assignee: Francesco Mari
>Priority: Minor
>  Labels: osgi, technical_debt
> Fix For: 1.10
>
> Attachments: OAK-6770-01.patch
>
>




--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Resolved] (OAK-6770) Convert oak-segment-tar to OSGi R6 annotations

[Francesco Mari (JIRA)]

 [ 
https://issues.apache.org/jira/browse/OAK-6770?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Francesco Mari resolved OAK-6770.
-
   Resolution: Fixed
Fix Version/s: 1.9.6

Fixed at r1835837.

> Convert oak-segment-tar to OSGi R6 annotations
> --
>
> Key: OAK-6770
> URL: https://issues.apache.org/jira/browse/OAK-6770
> Project: Jackrabbit Oak
>  Issue Type: Technical task
>  Components: segment-tar
>Reporter: Robert Munteanu
>Assignee: Francesco Mari
>Priority: Minor
>  Labels: osgi, technical_debt
> Fix For: 1.10, 1.9.6
>
> Attachments: OAK-6770-01.patch
>
>




--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (OAK-7629) Lucene index: hide the settings COR and COW

[Thomas Mueller (JIRA)]

 [ 
https://issues.apache.org/jira/browse/OAK-7629?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Thomas Mueller updated OAK-7629:

Fix Version/s: 1.9.6

> Lucene index: hide the settings COR and COW 
> 
>
> Key: OAK-7629
> URL: https://issues.apache.org/jira/browse/OAK-7629
> Project: Jackrabbit Oak
>  Issue Type: Improvement
>  Components: lucene
>Reporter: Thomas Mueller
>Assignee: Thomas Mueller
>Priority: Major
> Fix For: 1.10, 1.9.6
>
>
> I have seen people disabling copy-on-read or copy-on-write hoping to improve 
> performance or save space. We know about problems if those are disabled, for 
> example it can result in many open file handles, OAK-7460.
> So best if we hide these features, so that people don't change them.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Resolved] (OAK-7629) Lucene index: hide the settings COR and COW

[Thomas Mueller (JIRA)]

 [ 
https://issues.apache.org/jira/browse/OAK-7629?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Thomas Mueller resolved OAK-7629.
-
Resolution: Fixed

> Lucene index: hide the settings COR and COW 
> 
>
> Key: OAK-7629
> URL: https://issues.apache.org/jira/browse/OAK-7629
> Project: Jackrabbit Oak
>  Issue Type: Improvement
>  Components: lucene
>Reporter: Thomas Mueller
>Assignee: Thomas Mueller
>Priority: Major
> Fix For: 1.10
>
>
> I have seen people disabling copy-on-read or copy-on-write hoping to improve 
> performance or save space. We know about problems if those are disabled, for 
> example it can result in many open file handles, OAK-7460.
> So best if we hide these features, so that people don't change them.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (OAK-7629) Lucene index: hide the settings COR and COW

[Thomas Mueller (JIRA)]

[ 
https://issues.apache.org/jira/browse/OAK-7629?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16543189#comment-16543189
 ] 

Thomas Mueller commented on OAK-7629:
-

http://svn.apache.org/r1835838
https://github.com/tteofili/jackrabbit-oak/commit/229afb3affc307d809d300e249065f5cfa9b0ef2

> Lucene index: hide the settings COR and COW 
> 
>
> Key: OAK-7629
> URL: https://issues.apache.org/jira/browse/OAK-7629
> Project: Jackrabbit Oak
>  Issue Type: Improvement
>  Components: lucene
>Reporter: Thomas Mueller
>Assignee: Thomas Mueller
>Priority: Major
> Fix For: 1.10, 1.9.6
>
>
> I have seen people disabling copy-on-read or copy-on-write hoping to improve 
> performance or save space. We know about problems if those are disabled, for 
> example it can result in many open file handles, OAK-7460.
> So best if we hide these features, so that people don't change them.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (OAK-7511) get rid of JSR 305 dependency

[Julian Reschke (JIRA)]

 [ 
https://issues.apache.org/jira/browse/OAK-7511?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Julian Reschke updated OAK-7511:

Attachment: (was: convert-annotations.sh)

> get rid of JSR 305 dependency
> -
>
> Key: OAK-7511
> URL: https://issues.apache.org/jira/browse/OAK-7511
> Project: Jackrabbit Oak
>  Issue Type: Task
>Reporter: Julian Reschke
>Assignee: Julian Reschke
>Priority: Major
> Attachments: convert-annotations.sh
>
>
> We should consider getting rid of the JSR 305 dependency (see 
> ).



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (OAK-7511) get rid of JSR 305 dependency

[Julian Reschke (JIRA)]

 [ 
https://issues.apache.org/jira/browse/OAK-7511?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Julian Reschke updated OAK-7511:

Attachment: convert-annotations.sh

> get rid of JSR 305 dependency
> -
>
> Key: OAK-7511
> URL: https://issues.apache.org/jira/browse/OAK-7511
> Project: Jackrabbit Oak
>  Issue Type: Task
>Reporter: Julian Reschke
>Assignee: Julian Reschke
>Priority: Major
> Attachments: convert-annotations.sh
>
>
> We should consider getting rid of the JSR 305 dependency (see 
> ).



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (OAK-7511) get rid of JSR 305 dependency

[Julian Reschke (JIRA)]

 [ 
https://issues.apache.org/jira/browse/OAK-7511?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Julian Reschke updated OAK-7511:

Attachment: (was: example.diff)

> get rid of JSR 305 dependency
> -
>
> Key: OAK-7511
> URL: https://issues.apache.org/jira/browse/OAK-7511
> Project: Jackrabbit Oak
>  Issue Type: Task
>Reporter: Julian Reschke
>Assignee: Julian Reschke
>Priority: Major
> Attachments: convert-annotations.sh
>
>
> We should consider getting rid of the JSR 305 dependency (see 
> ).



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (OAK-7511) get rid of JSR 305 dependency

[Julian Reschke (JIRA)]

 [ 
https://issues.apache.org/jira/browse/OAK-7511?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Julian Reschke updated OAK-7511:

Attachment: (was: OAK-7511.diff)

> get rid of JSR 305 dependency
> -
>
> Key: OAK-7511
> URL: https://issues.apache.org/jira/browse/OAK-7511
> Project: Jackrabbit Oak
>  Issue Type: Task
>Reporter: Julian Reschke
>Assignee: Julian Reschke
>Priority: Major
> Attachments: convert-annotations.sh
>
>
> We should consider getting rid of the JSR 305 dependency (see 
> ).



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (OAK-7511) get rid of JSR 305 dependency

[Julian Reschke (JIRA)]

 [ 
https://issues.apache.org/jira/browse/OAK-7511?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Julian Reschke updated OAK-7511:

Attachment: OAK-7511.diff

> get rid of JSR 305 dependency
> -
>
> Key: OAK-7511
> URL: https://issues.apache.org/jira/browse/OAK-7511
> Project: Jackrabbit Oak
>  Issue Type: Task
>Reporter: Julian Reschke
>Assignee: Julian Reschke
>Priority: Major
> Attachments: OAK-7511.diff, convert-annotations.sh
>
>
> We should consider getting rid of the JSR 305 dependency (see 
> ).



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Resolved] (OAK-7632) remove JSR 305 annotations in Groovy code

[Julian Reschke (JIRA)]

 [ 
https://issues.apache.org/jira/browse/OAK-7632?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Julian Reschke resolved OAK-7632.
-
   Resolution: Fixed
Fix Version/s: 1.9.6

> remove JSR 305 annotations in Groovy code
> -
>
> Key: OAK-7632
> URL: https://issues.apache.org/jira/browse/OAK-7632
> Project: Jackrabbit Oak
>  Issue Type: Technical task
>  Components: oak-run, pojosr
>Reporter: Julian Reschke
>Assignee: Julian Reschke
>Priority: Minor
> Fix For: 1.10, 1.9.6
>
>
> Replacing them with Jetbrains annotations compiles, but leads to test 
> failures at runtime, potentially because of different retention behavior.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (OAK-7511) get rid of JSR 305 dependency

[Julian Reschke (JIRA)]

[ 
https://issues.apache.org/jira/browse/OAK-7511?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16543208#comment-16543208
 ] 

Julian Reschke commented on OAK-7511:
-

Ok, current status...:

* I assume we migrate to Jetbrains annotations (see discussion in 
https://issues.apache.org/jira/browse/JCR-4301)
* wrote (destructive) script 
https://issues.apache.org/jira/secure/attachment/12931560/convert-annotations.sh
 which converts Java files and pom.xml
* found minor issues, such as OAK-7624, OAK-7625, and OAK-7632 and fixed them
* there's also one file to will let javac (in JDK18, not JDK10) with an NPE, 
for which the conversion script has a special case

This compiles and tests with baseline.skip, and baseline wants us to increase 
micro version numbers.

How do we proceed here? Should I go ahead? Should we do this in multiple steps 
(one per subproject)?

Feedback appreciated.

> get rid of JSR 305 dependency
> -
>
> Key: OAK-7511
> URL: https://issues.apache.org/jira/browse/OAK-7511
> Project: Jackrabbit Oak
>  Issue Type: Task
>Reporter: Julian Reschke
>Assignee: Julian Reschke
>Priority: Major
> Attachments: OAK-7511.diff, convert-annotations.sh
>
>
> We should consider getting rid of the JSR 305 dependency (see 
> ).



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (OAK-7618) Build Jackrabbit Oak #1532 failed

[Hudson (JIRA)]

[ 
https://issues.apache.org/jira/browse/OAK-7618?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16543276#comment-16543276
 ] 

Hudson commented on OAK-7618:
-

Previously failing build now is OK.
 Passed run: [Jackrabbit Oak 
#1543|https://builds.apache.org/job/Jackrabbit%20Oak/1543/] [console 
log|https://builds.apache.org/job/Jackrabbit%20Oak/1543/console]

> Build Jackrabbit Oak #1532 failed
> -
>
> Key: OAK-7618
> URL: https://issues.apache.org/jira/browse/OAK-7618
> Project: Jackrabbit Oak
>  Issue Type: Bug
>  Components: continuous integration
>Reporter: Hudson
>Priority: Major
>
> No description is provided
> The build Jackrabbit Oak #1532 has failed.
> First failed run: [Jackrabbit Oak 
> #1532|https://builds.apache.org/job/Jackrabbit%20Oak/1532/] [console 
> log|https://builds.apache.org/job/Jackrabbit%20Oak/1532/console]



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Created] (OAK-7633) Build Jackrabbit Oak #1544 failed

[Hudson (JIRA)]

Hudson created OAK-7633:
---

 Summary: Build Jackrabbit Oak #1544 failed
 Key: OAK-7633
 URL: https://issues.apache.org/jira/browse/OAK-7633
 Project: Jackrabbit Oak
  Issue Type: Bug
  Components: continuous integration
Reporter: Hudson


No description is provided

The build Jackrabbit Oak #1544 has failed.
First failed run: [Jackrabbit Oak 
#1544|https://builds.apache.org/job/Jackrabbit%20Oak/1544/] [console 
log|https://builds.apache.org/job/Jackrabbit%20Oak/1544/console]



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (OAK-7589) [DirectBinaryAccess][DISCUSS] Client facing API

[Matt Ryan (JIRA)]

[ 
https://issues.apache.org/jira/browse/OAK-7589?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16543718#comment-16543718
 ] 

Matt Ryan commented on OAK-7589:


[~mreutegg] the PR has been updated based on your feedback regarding changes to 
pass the token in order to avoid server-side state as was done in the initial 
proposal.  URL to URI changes are being done in a [different 
PR|https://github.com/apache/jackrabbit-oak/pull/96] I've created to collect 
all of the changes into one.

> [DirectBinaryAccess][DISCUSS] Client facing API
> ---
>
> Key: OAK-7589
> URL: https://issues.apache.org/jira/browse/OAK-7589
> Project: Jackrabbit Oak
>  Issue Type: Technical task
>Reporter: Matt Ryan
>Assignee: Matt Ryan
>Priority: Major
>
> From a discussion w/ [~mreutegg]:  Suggested that we move the API changes out 
> of oak-jcr (i.e. org.apache.jackrabbit.oak.jcr.api.binary.HttpBinaryProvider 
> and org.apache.jackrabbit.oak.jcr.api.binary.HttpBinaryDownload to a 
> different package to avoid unnecessary API changes to oak-jcr.
> This issue should also be used to discuss how exactly the client facing API 
> is designed. 



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (OAK-7574) [DirectBinaryAccess][DISCUSS] use URI instead of URL

[Matt Ryan (JIRA)]

[ 
https://issues.apache.org/jira/browse/OAK-7574?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16543721#comment-16543721
 ] 

Matt Ryan commented on OAK-7574:


[~reschke] I've made this change in [PR 
#96|https://github.com/apache/jackrabbit-oak/pull/96] which is intended to 
collect all the feedback for final review.  Please take a look and see if your 
concerns are met and whether this issue can be closed, thanks!

> [DirectBinaryAccess][DISCUSS] use URI instead of URL
> 
>
> Key: OAK-7574
> URL: https://issues.apache.org/jira/browse/OAK-7574
> Project: Jackrabbit Oak
>  Issue Type: Technical task
>  Components: api
>Reporter: Julian Reschke
>Assignee: Matt Ryan
>Priority: Major
>
> Please do not use {{java.net.URL}}:
> 1. It predates java.net.URI and sort of implies concrete client implications
>  2. It has historic baggage such as the incorrect and surprising behavior of 
> {{equals()}} and {{hashCode()}}
>  -3. It's inconsistent with the JCR API which uses {{java.net.URI}}-



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (OAK-7572) [DirectBinaryAccess][DISCUSS] Support direct access via enhanced binary capabilities

[Matt Ryan (JIRA)]

[ 
https://issues.apache.org/jira/browse/OAK-7572?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16543722#comment-16543722
 ] 

Matt Ryan commented on OAK-7572:


I believe this issue is addressed via OAK-7589 so we can probably close this 
one.

> [DirectBinaryAccess][DISCUSS] Support direct access via enhanced binary 
> capabilities
> 
>
> Key: OAK-7572
> URL: https://issues.apache.org/jira/browse/OAK-7572
> Project: Jackrabbit Oak
>  Issue Type: Technical task
>Reporter: Matt Ryan
>Assignee: Matt Ryan
>Priority: Major
>
> The proposal in OAK-7569 enables direct upload and download capabilities via 
> API enhancements.  Would it be better instead to take an approach similar to 
> that in OAK-6575 and enable this via enhanced capabilities of a Binary 
> subclass or extension interface?



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (OAK-7573) [DirectBinaryAccess][DISCUSS] Interchangeability directly between ReferenceBinary and Blob

[Matt Ryan (JIRA)]

[ 
https://issues.apache.org/jira/browse/OAK-7573?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16543723#comment-16543723
 ] 

Matt Ryan commented on OAK-7573:


I think this can be closed.

> [DirectBinaryAccess][DISCUSS] Interchangeability directly between 
> ReferenceBinary and Blob
> --
>
> Key: OAK-7573
> URL: https://issues.apache.org/jira/browse/OAK-7573
> Project: Jackrabbit Oak
>  Issue Type: Technical task
>Reporter: Matt Ryan
>Assignee: Matt Ryan
>Priority: Major
>
> The [original pull request|https://github.com/apache/jackrabbit-oak/pull/88] 
> adds functionality to ValueFactoryImpl to convert between ReferenceBinary and 
> Blob instances as code paths move through different layers of the 
> application.  Instead of making changes to ValueFactoryImpl should we just 
> enhance the classes themselves, to easily convert from e.g. ReferenceBinary 
> directly to Blob?



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)