[jira] [Created] (OAK-8091) Build Jackrabbit Oak #1979 failed

2019-02-27 Thread Hudson (JIRA)
Hudson created OAK-8091:
---

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


No description is provided

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



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


[jira] [Commented] (OAK-8090) Update baseline comparisonVersion to 1.10.1

2019-02-27 Thread Julian Reschke (JIRA)


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

Julian Reschke commented on OAK-8090:
-

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


> Update baseline comparisonVersion to 1.10.1
> ---
>
> Key: OAK-8090
> URL: https://issues.apache.org/jira/browse/OAK-8090
> Project: Jackrabbit Oak
>  Issue Type: Task
>  Components: parent
>Reporter: Julian Reschke
>Assignee: Julian Reschke
>Priority: Trivial
> Fix For: 1.12, 1.11.0
>
>




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


[jira] [Resolved] (OAK-8090) Update baseline comparisonVersion to 1.10.1

2019-02-27 Thread Julian Reschke (JIRA)


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

Julian Reschke resolved OAK-8090.
-
   Resolution: Fixed
Fix Version/s: 1.11.0

> Update baseline comparisonVersion to 1.10.1
> ---
>
> Key: OAK-8090
> URL: https://issues.apache.org/jira/browse/OAK-8090
> Project: Jackrabbit Oak
>  Issue Type: Task
>  Components: parent
>Reporter: Julian Reschke
>Assignee: Julian Reschke
>Priority: Trivial
> Fix For: 1.12, 1.11.0
>
>




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


[jira] [Updated] (OAK-8013) [Direct Binary Access] DataRecordDownloadOptions creates invalid Content-Disposition headers

2019-02-27 Thread Julian Reschke (JIRA)


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

Julian Reschke updated OAK-8013:

Fix Version/s: (was: 1.10.2)

> [Direct Binary Access] DataRecordDownloadOptions creates invalid 
> Content-Disposition headers
> 
>
> Key: OAK-8013
> URL: https://issues.apache.org/jira/browse/OAK-8013
> Project: Jackrabbit Oak
>  Issue Type: Bug
>  Components: blob-plugins
>Reporter: Alexander Klimetschek
>Assignee: Matt Ryan
>Priority: Major
> Fix For: 1.12
>
>
> DataRecordDownloadOptions always adds the extended parameter filename* to the 
> header, [without any 
> escaping|https://github.com/apache/jackrabbit-oak/blob/trunk/oak-blob-plugins/src/main/java/org/apache/jackrabbit/oak/plugins/blob/datastore/directaccess/DataRecordDownloadOptions.java#L130].
> Such extended parameters must not include spaces (and only a small predefined 
> list of basic ascii chars), otherwise they have to be percent encoded. The 
> RFC is https://tools.ietf.org/html/rfc5987 and note the definition of 
> value-chars in the grammar.
> Because of this, if a filename includes a space or another character that 
> must be percent encoded, this currently creates an invalid header that fails 
> to be parsed by other clients.
> See also https://github.com/jshttp/content-disposition/issues/24
>  



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


[jira] [Commented] (OAK-8013) [Direct Binary Access] DataRecordDownloadOptions creates invalid Content-Disposition headers

2019-02-27 Thread Julian Reschke (JIRA)


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

Julian Reschke commented on OAK-8013:
-

Can this be  closed? What about the backport to 1.10?

> [Direct Binary Access] DataRecordDownloadOptions creates invalid 
> Content-Disposition headers
> 
>
> Key: OAK-8013
> URL: https://issues.apache.org/jira/browse/OAK-8013
> Project: Jackrabbit Oak
>  Issue Type: Bug
>  Components: blob-plugins
>Reporter: Alexander Klimetschek
>Assignee: Matt Ryan
>Priority: Major
> Fix For: 1.12
>
>
> DataRecordDownloadOptions always adds the extended parameter filename* to the 
> header, [without any 
> escaping|https://github.com/apache/jackrabbit-oak/blob/trunk/oak-blob-plugins/src/main/java/org/apache/jackrabbit/oak/plugins/blob/datastore/directaccess/DataRecordDownloadOptions.java#L130].
> Such extended parameters must not include spaces (and only a small predefined 
> list of basic ascii chars), otherwise they have to be percent encoded. The 
> RFC is https://tools.ietf.org/html/rfc5987 and note the definition of 
> value-chars in the grammar.
> Because of this, if a filename includes a space or another character that 
> must be percent encoded, this currently creates an invalid header that fails 
> to be parsed by other clients.
> See also https://github.com/jshttp/content-disposition/issues/24
>  



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


[jira] [Assigned] (OAK-8090) Update baseline comparisonVersion to 1.10.1

2019-02-27 Thread Julian Reschke (JIRA)


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

Julian Reschke reassigned OAK-8090:
---

Assignee: Julian Reschke

> Update baseline comparisonVersion to 1.10.1
> ---
>
> Key: OAK-8090
> URL: https://issues.apache.org/jira/browse/OAK-8090
> Project: Jackrabbit Oak
>  Issue Type: Task
>  Components: parent
>Reporter: Julian Reschke
>Assignee: Julian Reschke
>Priority: Trivial
> Fix For: 1.12
>
>




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


[jira] [Closed] (OAK-8054) RepMembersConflictHandler creates property with wrong type

2019-02-27 Thread Julian Reschke (JIRA)


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

Julian Reschke closed OAK-8054.
---

> RepMembersConflictHandler creates property with wrong type
> --
>
> Key: OAK-8054
> URL: https://issues.apache.org/jira/browse/OAK-8054
> Project: Jackrabbit Oak
>  Issue Type: Bug
>  Components: core, security
>Reporter: Alex Deparvu
>Assignee: Alex Deparvu
>Priority: Critical
>  Labels: candidate_oak_1_8
> Fix For: 1.12, 1.11.0, 1.10.1
>
> Attachments: OAK-8054-impact.patch, OAK-8054.patch
>
>
> The {{RepMembersConflictHandler}} handler uses type {{STRING}} instead of 
> {{WEAKREFERENCE}} [0] as per the property's definition, which will trigger 
> the type validation to fail the commit.
> Running external login tests I see that the type fails as soon as the handler 
> comes into play:
> {noformat}
> WARN  o.a.j.o.s.s.a.e.i.ExternalLoginModule - User synchronization failed 
> during commit: org.apache.jackrabbit.oak.api.CommitFailedException: 
> OakConstraint0004: 
> /rep:security/rep:authorizables/rep:groups/pathPrefix/g8/rep:membersList/9[[rep:MemberReferences]]:
>  No matching property definition found for rep:members = 
> [8e490910-17b6-30c1-8e11-6abdfa8a4ebc, 1a8e79f5-428e-39e9-88bb-2b86bd9b402e, 
> ... ]. (attempt 10/50)
> {noformat}
> This seems to be a pretty big issue, and I'm not yet sure why it wasn't 
> caught by the existing tests.
> // fyi [~anchela]
> [0] 
> https://github.com/apache/jackrabbit-oak/blob/trunk/oak-core/src/main/java/org/apache/jackrabbit/oak/security/user/RepMembersConflictHandler.java#L135



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


[jira] [Created] (OAK-8090) Update baseline comparisonVersion to 1.10.1

2019-02-27 Thread Julian Reschke (JIRA)
Julian Reschke created OAK-8090:
---

 Summary: Update baseline comparisonVersion to 1.10.1
 Key: OAK-8090
 URL: https://issues.apache.org/jira/browse/OAK-8090
 Project: Jackrabbit Oak
  Issue Type: Task
  Components: parent
Reporter: Julian Reschke
 Fix For: 1.12






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


[jira] [Resolved] (OAK-8075) Release Oak 1.10.1

2019-02-27 Thread Julian Reschke (JIRA)


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

Julian Reschke resolved OAK-8075.
-
Resolution: Fixed

> Release Oak 1.10.1
> --
>
> Key: OAK-8075
> URL: https://issues.apache.org/jira/browse/OAK-8075
> Project: Jackrabbit Oak
>  Issue Type: Task
>Reporter: Julian Reschke
>Assignee: Julian Reschke
>Priority: Minor
>




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


[jira] [Closed] (OAK-7984) Batch update documents in commit rollback

2019-02-27 Thread Julian Reschke (JIRA)


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

Julian Reschke closed OAK-7984.
---

> Batch update documents in commit rollback
> -
>
> Key: OAK-7984
> URL: https://issues.apache.org/jira/browse/OAK-7984
> Project: Jackrabbit Oak
>  Issue Type: Improvement
>  Components: documentmk
>Reporter: Marcel Reutegger
>Assignee: Marcel Reutegger
>Priority: Minor
> Fix For: 1.12, 1.11.0, 1.10.1
>
>
> As mentioned in OAK-7976 rolling back a commit updates the documents one by 
> one. This is inefficient and should rather use 
> {{DocumentStore.createOrUpdate(Collection, List)}}.



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


[jira] [Closed] (OAK-8076) in 1.10, adjust bundle baseline check comparisonVersion

2019-02-27 Thread Julian Reschke (JIRA)


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

Julian Reschke closed OAK-8076.
---

> in 1.10, adjust bundle baseline check comparisonVersion
> ---
>
> Key: OAK-8076
> URL: https://issues.apache.org/jira/browse/OAK-8076
> Project: Jackrabbit Oak
>  Issue Type: Task
>  Components: parent
>Affects Versions: 1.10.1
>Reporter: Julian Reschke
>Assignee: Julian Reschke
>Priority: Major
> Fix For: 1.10.1
>
>




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


[jira] [Closed] (OAK-8052) PersistentCache: failure during construction may lead to resource leak

2019-02-27 Thread Julian Reschke (JIRA)


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

Julian Reschke closed OAK-8052.
---

> PersistentCache: failure during construction may lead to resource leak
> --
>
> Key: OAK-8052
> URL: https://issues.apache.org/jira/browse/OAK-8052
> Project: Jackrabbit Oak
>  Issue Type: Bug
>  Components: documentmk
>Reporter: Julian Reschke
>Assignee: Julian Reschke
>Priority: Minor
>  Labels: candidate_oak_1_6, candidate_oak_1_8
> Fix For: 1.12, 1.11.0, 1.10.1
>
> Attachments: OAK-8052.diff
>
>
> In the constructor:
> {noformat}
> readGeneration = generations.size() > 1 ? generations.first() : -1;
> writeGeneration = generations.size() > 0 ? generations.last() : 0;
> if (readGeneration >= 0) {
> readStore = createMapFactory(readGeneration, true);
> }
> writeStore = createMapFactory(writeGeneration, false);
> initBroadcast(broadcast);
> {noformat}
> ...so if {{createMapFactory}} fails for {{writeStore}}, {{readStore}} will 
> not be closed.



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


[jira] [Closed] (OAK-8067) Measure fsync (called when closing the NRT index) and try to reduce disk I/O

2019-02-27 Thread Julian Reschke (JIRA)


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

Julian Reschke closed OAK-8067.
---

> Measure fsync (called when closing the NRT index) and try to reduce disk I/O
> 
>
> Key: OAK-8067
> URL: https://issues.apache.org/jira/browse/OAK-8067
> Project: Jackrabbit Oak
>  Issue Type: Improvement
>  Components: lucene
>Reporter: Thomas Mueller
>Assignee: Thomas Mueller
>Priority: Major
> Fix For: 1.10.1
>
>
> We have seen the following stack trace, and saw that fsync was seemingly very 
> slow on the system.
> Two issues: (1) fsync seems to be very slow here (2) fsync is called while 
> holding a lock.
> (2) should be resolved by lazy-loading indexes.
> {noformat}
> "oak-lucene-22" daemon prio=1 tid=0x6b1 nid=0x runnable
>java.lang.Thread.State: RUNNABLE
>   atjava.io.FileDescriptor.sync(Native Method)
>   at org.apache.lucene.store.FSDirectory.fsync(FSDirectory.java:505)
>   at org.apache.lucene.store.FSDirectory.sync(FSDirectory.java:307)
>   at 
> org.apache.lucene.store.NRTCachingDirectory.sync(NRTCachingDirectory.java:219)
>   at 
> org.apache.lucene.index.IndexWriter.startCommit(IndexWriter.java:4489)
>   at 
> org.apache.lucene.index.IndexWriter.prepareCommitInternal(IndexWriter.java:2953)
>   - locked <0x20595abf> (a java.lang.Object)
>   at 
> org.apache.lucene.index.IndexWriter.commitInternal(IndexWriter.java:3049)
>   - locked <0x20595abf> (a java.lang.Object)
>   at 
> org.apache.lucene.index.IndexWriter.closeInternal(IndexWriter.java:1041)
>   at org.apache.lucene.index.IndexWriter.close(IndexWriter.java:932)
>   - locked <0x20595abf> (a java.lang.Object)
>   at org.apache.lucene.index.IndexWriter.close(IndexWriter.java:894)
>   at 
> org.apache.jackrabbit.oak.plugins.index.lucene.hybrid.NRTIndex.close(NRTIndex.java:206)
>   at 
> org.apache.jackrabbit.oak.plugins.index.lucene.hybrid.NRTIndexFactory.closeLast(NRTIndexFactory.java:133)
>   at 
> org.apache.jackrabbit.oak.plugins.index.lucene.hybrid.NRTIndexFactory.createIndex(NRTIndexFactory.java:89)
>   - locked <0x85f9b65> (a 
> org.apache.jackrabbit.oak.plugins.index.lucene.hybrid.NRTIndexFactory)
>   at 
> org.apache.jackrabbit.oak.plugins.index.lucene.LuceneIndexNodeManager.open(LuceneIndexNodeManager.java:73)
>   at 
> org.apache.jackrabbit.oak.plugins.index.lucene.IndexTracker$1.leave(IndexTracker.java:154)
>   at 
> org.apache.jackrabbit.oak.spi.commit.EditorDiff.childNodeChanged(EditorDiff.java:152)
>   at 
> org.apache.jackrabbit.oak.composite.CompositeNodeState$WrappingDiff.childNodeChanged(CompositeNodeState.java:309)
>   at 
> org.apache.jackrabbit.oak.composite.CompositeNodeState$ChildrenDiffFilter.childNodeChanged(CompositeNodeState.java:256)
>   at 
> org.apache.jackrabbit.oak.plugins.document.JsopNodeStateDiffer.compareExisting(JsopNodeStateDiffer.java:100)
>   at 
> org.apache.jackrabbit.oak.plugins.document.JsopNodeStateDiffer.access$000(JsopNodeStateDiffer.java:27)
>   at 
> org.apache.jackrabbit.oak.plugins.document.JsopNodeStateDiffer$1.childNodeChanged(JsopNodeStateDiffer.java:65)
>   at 
> org.apache.jackrabbit.oak.plugins.document.DiffCache.parseJsopDiff(DiffCache.java:118)
>   at 
> org.apache.jackrabbit.oak.plugins.document.JsopNodeStateDiffer.compare(JsopNodeStateDiffer.java:51)
>   at 
> org.apache.jackrabbit.oak.plugins.document.DocumentNodeStore.compare(DocumentNodeStore.java:1766)
>   at 
> org.apache.jackrabbit.oak.plugins.document.AbstractDocumentNodeState.compareAgainstBaseState(AbstractDocumentNodeState.java:113)
>   at 
> org.apache.jackrabbit.oak.composite.CompositeNodeState.compareAgainstBaseState(CompositeNodeState.java:163)
>   at 
> org.apache.jackrabbit.oak.spi.commit.EditorDiff.childNodeChanged(EditorDiff.java:147)
>   at 
> org.apache.jackrabbit.oak.composite.CompositeNodeState$WrappingDiff.childNodeChanged(CompositeNodeState.java:309)
>   at 
> org.apache.jackrabbit.oak.composite.CompositeNodeState$ChildrenDiffFilter.childNodeChanged(CompositeNodeState.java:256)
>   at 
> org.apache.jackrabbit.oak.plugins.document.JsopNodeStateDiffer.compareExisting(JsopNodeStateDiffer.java:100)
>   at 
> org.apache.jackrabbit.oak.plugins.document.JsopNodeStateDiffer.access$000(JsopNodeStateDiffer.java:27)
>   at 
> org.apache.jackrabbit.oak.plugins.document.JsopNodeStateDiffer$1.childNodeChanged(JsopNodeStateDiffer.java:65)
>   at 
> org.apache.jackrabbit.oak.plugins.document.DiffCache.parseJsopDiff(DiffCache.java:118)
>   at 
> org.apache.jackrabbit.oak.plugins.document.JsopNodeStateDiffer.compare(JsopNodeStateDiffer.java:51)
>   at 
> 

[jira] [Closed] (OAK-7978) guava-latest profile defunct

2019-02-27 Thread Julian Reschke (JIRA)


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

Julian Reschke closed OAK-7978.
---

> guava-latest profile defunct
> 
>
> Key: OAK-7978
> URL: https://issues.apache.org/jira/browse/OAK-7978
> Project: Jackrabbit Oak
>  Issue Type: Technical task
>  Components: parent
>Reporter: Julian Reschke
>Assignee: Julian Reschke
>Priority: Minor
> Fix For: 1.12, 1.11.0, 1.10.1, 1.8.12
>
> Attachments: OAK-7978.diff
>
>
> The profile doesn't actually do what it's supposed to do (did it work 
> earlier)?



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


[jira] [Closed] (OAK-8033) Node states sometimes refer to more than a single generation of segments after a full compaction

2019-02-27 Thread Julian Reschke (JIRA)


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

Julian Reschke closed OAK-8033.
---

> Node states sometimes refer to more than a single generation of segments 
> after a full compaction
> 
>
> Key: OAK-8033
> URL: https://issues.apache.org/jira/browse/OAK-8033
> Project: Jackrabbit Oak
>  Issue Type: Bug
>  Components: segment-tar
>Affects Versions: 1.10.0, 1.8.10, 1.6.16, 1.8.11, 1.10
>Reporter: Michael Dürig
>Assignee: Michael Dürig
>Priority: Major
>  Labels: TarMK, candidate_oak_1_6
> Fix For: 1.6.17, 1.11.0, 1.10.1, 1.8.12
>
>
> Due to a regression introduced with OAK-7867 a full compaction can sometimes 
> cause nodes that are written concurrently to reference segments from more 
> than a single gc generation.
> This happens when the {{borrowWriter}} method needs to [create a new 
> writer|https://github.com/apache/jackrabbit-oak/blob/trunk/oak-segment-tar/src/main/java/org/apache/jackrabbit/oak/segment/SegmentBufferWriterPool.java#L197-L201].
>  In this case the new writer will be of the generation of the current head 
> state instead of the generation associated with the current write operation 
> in progress.
>  
> cc [~frm], [~ahanikel]
>  



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


[jira] [Closed] (OAK-8069) Log warning for too many transient modifications of direct child nodes

2019-02-27 Thread Julian Reschke (JIRA)


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

Julian Reschke closed OAK-8069.
---

> Log warning for too many transient modifications of direct child nodes
> --
>
> Key: OAK-8069
> URL: https://issues.apache.org/jira/browse/OAK-8069
> Project: Jackrabbit Oak
>  Issue Type: Technical task
>  Components: segment-tar
>Reporter: Michael Dürig
>Assignee: Michael Dürig
>Priority: Blocker
>  Labels: TarMK
> Fix For: 1.12, 1.11.0, 1.10.1, 1.8.12
>
>
> In a first step towards resolving OAK-8066, I want to add some logging 
> regarding the number of transiently modified direct child nodes in 
> {{DefaultSegmentWriter}} 



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


[jira] [Closed] (OAK-8030) oak-jcr NodeTypeTest improvements

2019-02-27 Thread Julian Reschke (JIRA)


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

Julian Reschke closed OAK-8030.
---

> oak-jcr NodeTypeTest improvements
> -
>
> Key: OAK-8030
> URL: https://issues.apache.org/jira/browse/OAK-8030
> Project: Jackrabbit Oak
>  Issue Type: Task
>  Components: jcr
>Reporter: Julian Reschke
>Assignee: Julian Reschke
>Priority: Minor
>  Labels: candidate_oak_1_6
> Fix For: 1.12, 1.11.0, 1.10.1, 1.8.12
>
>
> The check for trivial updates could use {{LogCustomizer}} to verify that the 
> right thing happens behind the scenes.



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


[jira] [Closed] (OAK-7960) RDB: add to Oak documentation

2019-02-27 Thread Julian Reschke (JIRA)


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

Julian Reschke closed OAK-7960.
---

> RDB: add to Oak documentation
> -
>
> Key: OAK-7960
> URL: https://issues.apache.org/jira/browse/OAK-7960
> Project: Jackrabbit Oak
>  Issue Type: Technical task
>  Components: doc, documentmk, rdbmk
>Reporter: Julian Reschke
>Assignee: Julian Reschke
>Priority: Minor
>  Labels: candidate_oak_1_6
> Fix For: 1.12, 1.11.0, 1.10.1, 1.8.12
>
> Attachments: OAK-7960.diff
>
>




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


[jira] [Closed] (OAK-8059) Update Jackson dependency to 2.9.8

2019-02-27 Thread Julian Reschke (JIRA)


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

Julian Reschke closed OAK-8059.
---

> Update Jackson dependency to 2.9.8
> --
>
> Key: OAK-8059
> URL: https://issues.apache.org/jira/browse/OAK-8059
> Project: Jackrabbit Oak
>  Issue Type: Task
>  Components: parent
>Reporter: Julian Reschke
>Assignee: Julian Reschke
>Priority: Major
>  Labels: candidate_oak_1_6
> Fix For: 1.12, 1.11.0, 1.10.1, 1.8.12
>
>




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


[jira] [Closed] (OAK-8016) RDBDocumentStore: minor improvements to GZIP compression of BLOB contents

2019-02-27 Thread Julian Reschke (JIRA)


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

Julian Reschke closed OAK-8016.
---

> RDBDocumentStore: minor improvements to GZIP compression of BLOB contents
> -
>
> Key: OAK-8016
> URL: https://issues.apache.org/jira/browse/OAK-8016
> Project: Jackrabbit Oak
>  Issue Type: Technical task
>  Components: rdbmk
>Reporter: Julian Reschke
>Assignee: Julian Reschke
>Priority: Minor
>  Labels: candidate_oak_1_8
> Fix For: 1.12, 1.11.0, 1.10.1
>
>
> 1. Ensure GZIPOutputStream is closed in the unlikely event of error when 
> writing to ByteArrayOutputStream
> 2. Optionally log sizes and ratios
> 3. Slightly improve initial size estimate for ByteArrayOutputStream



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


[jira] [Closed] (OAK-8003) MongoDocumentStore does not log server details

2019-02-27 Thread Julian Reschke (JIRA)


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

Julian Reschke closed OAK-8003.
---

> MongoDocumentStore does not log server details
> --
>
> Key: OAK-8003
> URL: https://issues.apache.org/jira/browse/OAK-8003
> Project: Jackrabbit Oak
>  Issue Type: Bug
>  Components: mongomk
>Affects Versions: 1.10.0
>Reporter: Marcel Reutegger
>Assignee: Marcel Reutegger
>Priority: Minor
> Fix For: 1.12, 1.10.1
>
>
> The MongoDocumentStore does not log the server details anymore on startup. 
> This is a regression introduced by changes for OAK-6087.



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


[jira] [Closed] (OAK-8017) Test failure: LastRevRecoveryRandomizedIT

2019-02-27 Thread Julian Reschke (JIRA)


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

Julian Reschke closed OAK-8017.
---

> Test failure: LastRevRecoveryRandomizedIT
> -
>
> Key: OAK-8017
> URL: https://issues.apache.org/jira/browse/OAK-8017
> Project: Jackrabbit Oak
>  Issue Type: Bug
>  Components: continuous integration, documentmk
>Affects Versions: 1.10
>Reporter: Hudson
>Assignee: Marcel Reutegger
>Priority: Major
> Fix For: 1.12, 1.11.0, 1.10.1
>
> Attachments: archive.zip
>
>
> No description is provided
> The build Jackrabbit Oak #1918 has failed.
> First failed run: [Jackrabbit Oak 
> #1918|https://builds.apache.org/job/Jackrabbit%20Oak/1918/] [console 
> log|https://builds.apache.org/job/Jackrabbit%20Oak/1918/console]



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


[jira] [Closed] (OAK-8070) The date-based copy-versions directive doesn't work correctly with include-paths

2019-02-27 Thread Julian Reschke (JIRA)


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

Julian Reschke closed OAK-8070.
---

> The date-based copy-versions directive doesn't work correctly with 
> include-paths
> 
>
> Key: OAK-8070
> URL: https://issues.apache.org/jira/browse/OAK-8070
> Project: Jackrabbit Oak
>  Issue Type: Bug
>  Components: upgrade
>Affects Versions: 1.6.7, 1.0.40, 1.4.19, 1.8.0, 1.2.28, 1.10.0
>Reporter: Tomek Rękawek
>Assignee: Tomek Rękawek
>Priority: Major
> Fix For: 1.12, 1.6.17, 1.11.0, 1.10.1, 1.8.12
>
>
> It seems that the OAK-6633 introduced a regression. Right now, if the 
> include-paths is used together with a date-based copy-versions, the second 
> copy-versions date is ignored and all the versions are removed.



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


[jira] [Closed] (OAK-7982) ACL.addEntry: check for mandatory restrictions only respects single value restrictions

2019-02-27 Thread Julian Reschke (JIRA)


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

Julian Reschke closed OAK-7982.
---

> ACL.addEntry: check for mandatory restrictions only respects single value 
> restrictions
> --
>
> Key: OAK-7982
> URL: https://issues.apache.org/jira/browse/OAK-7982
> Project: Jackrabbit Oak
>  Issue Type: Bug
>  Components: core, security
>Reporter: angela
>Assignee: angela
>Priority: Major
> Fix For: 1.12, 1.11.0, 1.10.1
>
> Attachments: OAK-7982.patch
>
>
> The validation of {{ACL.addEntry(Principal principal, Privilege[] privileges, 
> boolean isAllow, Map restrictions, Map 
> mvRestrictions)}}
> includes a check that mandatory restrictions are actually present.
> However, the code performing that check only tests if the mandatory 
> restrictions are included in the {{restrictions}} ignoring the fact that a 
> mandatory restriction might be multi-valued and thus provided in the 
> {{mvRestrictions}} param.
> cc: [~stillalex] fyi.



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


[jira] [Closed] (OAK-8074) RDB*Store: update mysql-connector-java dependency to 8.0.15

2019-02-27 Thread Julian Reschke (JIRA)


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

Julian Reschke closed OAK-8074.
---

> RDB*Store: update mysql-connector-java dependency to 8.0.15
> ---
>
> Key: OAK-8074
> URL: https://issues.apache.org/jira/browse/OAK-8074
> Project: Jackrabbit Oak
>  Issue Type: Technical task
>  Components: rdbmk
>Reporter: Julian Reschke
>Assignee: Julian Reschke
>Priority: Minor
>  Labels: candidate_oak_1_8
> Fix For: 1.12, 1.11.0, 1.10.1
>
>




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


[jira] [Closed] (OAK-8004) oak-run: support "recovery" command for RDBDocumentStore

2019-02-27 Thread Julian Reschke (JIRA)


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

Julian Reschke closed OAK-8004.
---

> oak-run: support "recovery" command for RDBDocumentStore
> 
>
> Key: OAK-8004
> URL: https://issues.apache.org/jira/browse/OAK-8004
> Project: Jackrabbit Oak
>  Issue Type: Technical task
>  Components: rdbmk, run
>Reporter: Julian Reschke
>Assignee: Julian Reschke
>Priority: Minor
>  Labels: candidate_oak_1_6
> Fix For: 1.12, 1.11.0, 1.10.1, 1.8.12
>
> Attachments: OAK-8004.diff
>
>




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


[jira] [Closed] (OAK-8041) IndexDefinitionBuilder should support facets and boost for property definitions

2019-02-27 Thread Julian Reschke (JIRA)


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

Julian Reschke closed OAK-8041.
---

> IndexDefinitionBuilder should support facets and boost for property 
> definitions
> ---
>
> Key: OAK-8041
> URL: https://issues.apache.org/jira/browse/OAK-8041
> Project: Jackrabbit Oak
>  Issue Type: Improvement
>  Components: lucene
>Reporter: Vikas Saurabh
>Assignee: Vikas Saurabh
>Priority: Minor
> Fix For: 1.12, 1.11.0, 1.10.1
>
>




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


[jira] [Closed] (OAK-8023) AccessControlManagerImpl can not handle repository level when editing policies by principal

2019-02-27 Thread Julian Reschke (JIRA)


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

Julian Reschke closed OAK-8023.
---

> AccessControlManagerImpl can not handle repository level when editing 
> policies by principal
> ---
>
> Key: OAK-8023
> URL: https://issues.apache.org/jira/browse/OAK-8023
> Project: Jackrabbit Oak
>  Issue Type: Bug
>  Components: core, security
>Reporter: angela
>Assignee: angela
>Priority: Minor
>  Labels: candidate_oak_1_8
> Fix For: 1.12, 1.11.0, 1.10.1
>
> Attachments: OAK-8023-2.patch, OAK-8023-3.patch, OAK-8023.patch
>
>
> [~stillalex], it seems that editing access control by principal in the 
> default implementation doesn't allow for applying entries to the 'null' path.
> initially i thought that we can use an empty string value instead for the 
> {{rep:nodePath}}, but that doesn't work as it gets converted to "." for some 
> reason. 



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


[jira] [Closed] (OAK-8006) SegmentBlob#readLongBlobId might cause SegmentNotFoundException on standby

2019-02-27 Thread Julian Reschke (JIRA)


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

Julian Reschke closed OAK-8006.
---

> SegmentBlob#readLongBlobId might cause SegmentNotFoundException on standby
> --
>
> Key: OAK-8006
> URL: https://issues.apache.org/jira/browse/OAK-8006
> Project: Jackrabbit Oak
>  Issue Type: Bug
>  Components: segment-tar, tarmk-standby
>Affects Versions: 1.6.0
>Reporter: Andrei Dulceanu
>Assignee: Andrei Dulceanu
>Priority: Major
>  Labels: cold-standby
> Fix For: 1.12, 1.11.0, 1.10.1
>
> Attachments: OAK-8006-02.patch, OAK-8006-test.patch, OAK-8006.patch
>
>
> When persisting a segment transferred from master, among others, the cold 
> standby needs to read the binary references from the segment. While this 
> usually doesn't involve any additional reads from any other segments, there 
> is a special case concerning binary IDs larger than 4092 bytes. These can 
> live in other segments (which got transferred prior to the current segment 
> and are already on the standby), but it might also be the case that the 
> binary ID is stored in the same segment. If this happens, the call to 
> {{blobId.getSegment()}}[0], triggers a new read of the current, un-persisted 
> segment . Thus, a {{SegmentNotFoundException}} is thrown:
> {noformat}
> 22.01.2019 09:35:59.345 *ERROR* [standby-run-1] 
> org.apache.jackrabbit.oak.segment.standby.client.StandbyClientSync Failed 
> synchronizing state.
> org.apache.jackrabbit.oak.segment.SegmentNotFoundException: Segment 
> d40a9da6-06a2-4dc0-ab91-5554a33c02b0 not found
> at 
> org.apache.jackrabbit.oak.segment.file.AbstractFileStore.readSegmentUncached(AbstractFileStore.java:284)
>  [org.apache.jackrabbit.oak-segment-tar:1.10.0]
> at 
> org.apache.jackrabbit.oak.segment.file.FileStore.lambda$readSegment$10(FileStore.java:498)
>  [org.apache.jackrabbit.oak-segment-tar:1.10.0]
> at 
> org.apache.jackrabbit.oak.segment.SegmentCache$NonEmptyCache.lambda$getSegment$0(SegmentCache.java:163)
>  [org.apache.jackrabbit.oak-segment-tar:1.10.0]
> at 
> com.google.common.cache.LocalCache$LocalManualCache$1.load(LocalCache.java:4724)
>  [com.adobe.granite.osgi.wrapper.guava:15.0.0.0002]
> at 
> com.google.common.cache.LocalCache$LoadingValueReference.loadFuture(LocalCache.java:3522)
>  [com.adobe.granite.osgi.wrapper.guava:15.0.0.0002]
> at 
> com.google.common.cache.LocalCache$Segment.loadSync(LocalCache.java:2315) 
> [com.adobe.granite.osgi.wrapper.guava:15.0.0.0002]
> at 
> com.google.common.cache.LocalCache$Segment.lockedGetOrLoad(LocalCache.java:2278)
>  [com.adobe.granite.osgi.wrapper.guava:15.0.0.0002]
> at 
> com.google.common.cache.LocalCache$Segment.get(LocalCache.java:2193) 
> [com.adobe.granite.osgi.wrapper.guava:15.0.0.0002]
> at com.google.common.cache.LocalCache.get(LocalCache.java:3932) 
> [com.adobe.granite.osgi.wrapper.guava:15.0.0.0002]
> at 
> com.google.common.cache.LocalCache$LocalManualCache.get(LocalCache.java:4721) 
> [com.adobe.granite.osgi.wrapper.guava:15.0.0.0002]
> at 
> org.apache.jackrabbit.oak.segment.SegmentCache$NonEmptyCache.getSegment(SegmentCache.java:160)
>  [org.apache.jackrabbit.oak-segment-tar:1.10.0]
> at 
> org.apache.jackrabbit.oak.segment.file.FileStore.readSegment(FileStore.java:498)
>  [org.apache.jackrabbit.oak-segment-tar:1.10.0]
> at 
> org.apache.jackrabbit.oak.segment.SegmentId.getSegment(SegmentId.java:153) 
> [org.apache.jackrabbit.oak-segment-tar:1.10.0]
> at 
> org.apache.jackrabbit.oak.segment.RecordId.getSegment(RecordId.java:98) 
> [org.apache.jackrabbit.oak-segment-tar:1.10.0]
> at 
> org.apache.jackrabbit.oak.segment.SegmentBlob.readLongBlobId(SegmentBlob.java:206)
>  [org.apache.jackrabbit.oak-segment-tar:1.10.0]
> at 
> org.apache.jackrabbit.oak.segment.SegmentBlob.readBlobId(SegmentBlob.java:163)
>  [org.apache.jackrabbit.oak-segment-tar:1.10.0]
> at 
> org.apache.jackrabbit.oak.segment.file.AbstractFileStore$3.consume(AbstractFileStore.java:262)
>  [org.apache.jackrabbit.oak-segment-tar:1.10.0]
> at 
> org.apache.jackrabbit.oak.segment.Segment.forEachRecord(Segment.java:601) 
> [org.apache.jackrabbit.oak-segment-tar:1.10.0]
> at 
> org.apache.jackrabbit.oak.segment.file.AbstractFileStore.readBinaryReferences(AbstractFileStore.java:257)
>  [org.apache.jackrabbit.oak-segment-tar:1.10.0]
> at 
> org.apache.jackrabbit.oak.segment.file.FileStore.writeSegment(FileStore.java:533)
>  [org.apache.jackrabbit.oak-segment-tar:1.10.0]
> at 
> org.apache.jackrabbit.oak.segment.standby.client.StandbyClientSyncExecution.copySegmentFromPrimary(StandbyClientSyncExecution.java:225)
> 

[jira] [Closed] (OAK-8042) IndexDefinitionBuilder should support deprecated properties on index definition

2019-02-27 Thread Julian Reschke (JIRA)


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

Julian Reschke closed OAK-8042.
---

> IndexDefinitionBuilder should support deprecated properties on index 
> definition
> ---
>
> Key: OAK-8042
> URL: https://issues.apache.org/jira/browse/OAK-8042
> Project: Jackrabbit Oak
>  Issue Type: Improvement
>  Components: lucene
>Reporter: Vikas Saurabh
>Assignee: Vikas Saurabh
>Priority: Minor
> Fix For: 1.12, 1.11.0, 1.10.1
>
>




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


[jira] [Closed] (OAK-7979) DeclaredMembershipPredicate does not compile with Guava 20

2019-02-27 Thread Julian Reschke (JIRA)


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

Julian Reschke closed OAK-7979.
---

> DeclaredMembershipPredicate does not compile with Guava 20
> --
>
> Key: OAK-7979
> URL: https://issues.apache.org/jira/browse/OAK-7979
> Project: Jackrabbit Oak
>  Issue Type: Technical task
>  Components: core
>Reporter: Julian Reschke
>Assignee: Julian Reschke
>Priority: Minor
> Fix For: 1.12, 1.11.0, 1.10.1
>
>




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


[jira] [Closed] (OAK-6749) Segment-Tar standby sync fails with "in-memory" blobs present in the source repo

2019-02-27 Thread Julian Reschke (JIRA)


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

Julian Reschke closed OAK-6749.
---

> Segment-Tar standby sync fails with "in-memory" blobs present in the source 
> repo
> 
>
> Key: OAK-6749
> URL: https://issues.apache.org/jira/browse/OAK-6749
> Project: Jackrabbit Oak
>  Issue Type: Bug
>  Components: blob, tarmk-standby
>Affects Versions: 1.6.2
>Reporter: Csaba Varga
>Assignee: Francesco Mari
>Priority: Major
> Fix For: 1.10.1, 1.8.12, 1.10
>
> Attachments: OAK-6749-01.patch, OAK-6749-02.patch, 
> repack_binaries.groovy
>
>
> We have run into some issue when trying to transition from an active/active 
> Mongo NodeStore cluster to a single Segment-Tar server with cold standby. The 
> issue itself manifests when the standby server tries to pull changes from the 
> primary after the first round of online revision GC.
> Let me summarize the way we ended up with the current state, and my 
> hypothesis about what happened, based on my debugging so far:
> # We started with a Mongo NodeStore and an external FileDataStore as the blob 
> store. The FileDataStore was set up with minRecordLength=4096. The Mongo 
> store stores blobs below minRecordLength as special "in-memory" blobIDs where 
> the data itself is baked into the ID string in hex.
> # We have executed a sidegrade of the Mongo store into a Segment-Tar store. 
> Our datastore is over 1TB in size, so copying the binaries wasn't an option. 
> The new repository is simply reusing the existing datastore. The "in-memory" 
> blobIDs still look like external blobIDs to the sidegrade process, so they 
> were copied into the Segment-Tar repository as-is, instead of being converted 
> into the efficient in-line format.
> # The server started up without issues on the new Segment-Tar store. The 
> migrated "in-memory" blob IDs seem to work fine, if a bit sub-optimal.
> # At this point, we have created a cold standby instance by copying the files 
> of the stopped primary instance and making the necessary config changes on 
> both servers.
> # Everything worked fine until the primary server started its first round of 
> online revision GC. After that process completed, the standby node started 
> throwing exceptions about missing segments, and eventually stopped 
> altogether. In the meantime, the following warning showed up in the primary 
> log:
> {code:java}
> 29.09.2017 06:12:08.088 *WARN* [nioEventLoopGroup-3-10] 
> org.apache.jackrabbit.oak.segment.standby.server.ExceptionHandler Exception 
> caught on the server
> io.netty.handler.codec.TooLongFrameException: frame length (8208) exceeds the 
> allowed maximum (8192)
> at 
> io.netty.handler.codec.LineBasedFrameDecoder.fail(LineBasedFrameDecoder.java:146)
> at 
> io.netty.handler.codec.LineBasedFrameDecoder.fail(LineBasedFrameDecoder.java:142)
> at 
> io.netty.handler.codec.LineBasedFrameDecoder.decode(LineBasedFrameDecoder.java:99)
> at 
> io.netty.handler.codec.LineBasedFrameDecoder.decode(LineBasedFrameDecoder.java:75)
> at 
> io.netty.handler.codec.ByteToMessageDecoder.callDecode(ByteToMessageDecoder.java:411)
> at 
> io.netty.handler.codec.ByteToMessageDecoder.channelRead(ByteToMessageDecoder.java:248)
> at 
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:366)
> at 
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:352)
> at 
> io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:345)
> at 
> io.netty.channel.ChannelInboundHandlerAdapter.channelRead(ChannelInboundHandlerAdapter.java:86)
> at 
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:366)
> at 
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:352)
> at 
> io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:345)
> at 
> io.netty.channel.DefaultChannelPipeline$HeadContext.channelRead(DefaultChannelPipeline.java:1294)
> at 
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:366)
> at 
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:352)
> at 
> io.netty.channel.DefaultChannelPipeline.fireChannelRead(DefaultChannelPipeline.java:911)
> at 
> io.netty.channel.nio.AbstractNioByteChannel$NioByteUnsafe.read(AbstractNioByteChannel.java:131)
> at 
> 

[jira] [Closed] (OAK-8037) add test case for making a node type referenceable

2019-02-27 Thread Julian Reschke (JIRA)


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

Julian Reschke closed OAK-8037.
---

> add test case for making a node type referenceable
> --
>
> Key: OAK-8037
> URL: https://issues.apache.org/jira/browse/OAK-8037
> Project: Jackrabbit Oak
>  Issue Type: Task
>  Components: jcr
>Reporter: Julian Reschke
>Assignee: Julian Reschke
>Priority: Minor
> Fix For: 1.12, 1.11.0, 1.10.1, 1.8.12
>
>




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


[jira] [Closed] (OAK-8012) Unmerged branch changes visible after restart

2019-02-27 Thread Julian Reschke (JIRA)


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

Julian Reschke closed OAK-8012.
---

> Unmerged branch changes visible after restart
> -
>
> Key: OAK-8012
> URL: https://issues.apache.org/jira/browse/OAK-8012
> Project: Jackrabbit Oak
>  Issue Type: Bug
>  Components: documentmk
>Affects Versions: 1.4, 1.6.0, 1.8.0, 1.10.0
>Reporter: Marcel Reutegger
>Assignee: Marcel Reutegger
>Priority: Critical
>  Labels: candidate_oak_1_4, candidate_oak_1_6, candidate_oak_1_8
> Fix For: 1.12, 1.11.0, 1.10.1
>
>
> Changes persisted to a branch are visible after a restart even when the 
> branch has not been merged.



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


[jira] [Closed] (OAK-8001) Lucene index can be empty (no :data node) in composite node store setup

2019-02-27 Thread Julian Reschke (JIRA)


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

Julian Reschke closed OAK-8001.
---

> Lucene index can be empty (no :data node) in composite node store setup
> ---
>
> Key: OAK-8001
> URL: https://issues.apache.org/jira/browse/OAK-8001
> Project: Jackrabbit Oak
>  Issue Type: Bug
>  Components: lucene
>Reporter: Vikas Saurabh
>Assignee: Vikas Saurabh
>Priority: Major
> Fix For: 1.12, 1.11.0, 1.10.1
>
>
> In normal setups, even if no data is written to the index, an empty (valid) 
> lucene index is created - that's useful to take care of checking 
> if-index-exists everywhere before opening the index.
> {{DefaultIndexWriter#close}} has an explicit comment stating this to be an 
> explicit intent.
> In composite node stores though, if an index doesn't get any data to be 
> indexed then {{MultiplexingIndexWriter}} never opens a {{DefaultIndexWriter}} 
> (for one or all mounts - depending on if there were some writes then which 
> mount did they hit).
> {{MultiplexingIndexWriter}} does delegate {{close}} to its opened writers but 
> that doesn't give the opportunity to {{DefaultIndexWriter#close}} into play 
> if there was no writer opened for a given mount.
> This then leads to situation in composite node stores where very empty 
> indexes can have missing {{:data}} node. In fact this was one of the causes 
> that we hit OAK-7983 in one of AEM based project.



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


[jira] [Closed] (OAK-8043) RDB: expose DDL generation functionality in oak-run

2019-02-27 Thread Julian Reschke (JIRA)


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

Julian Reschke closed OAK-8043.
---

> RDB: expose DDL generation functionality in oak-run
> ---
>
> Key: OAK-8043
> URL: https://issues.apache.org/jira/browse/OAK-8043
> Project: Jackrabbit Oak
>  Issue Type: Technical task
>  Components: oak-run, rdbmk
>Reporter: Julian Reschke
>Assignee: Julian Reschke
>Priority: Minor
>  Labels: candidate_oak_1_6
> Fix For: 1.12, 1.11.0, 1.10.1, 1.8.12
>
>




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


[jira] [Closed] (OAK-8058) RDB*Store: update Tomcat JDBC pool dependency to 8.5.38

2019-02-27 Thread Julian Reschke (JIRA)


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

Julian Reschke closed OAK-8058.
---

> RDB*Store: update Tomcat JDBC pool dependency to 8.5.38
> ---
>
> Key: OAK-8058
> URL: https://issues.apache.org/jira/browse/OAK-8058
> Project: Jackrabbit Oak
>  Issue Type: Technical task
>  Components: documentmk, rdbmk
>Reporter: Julian Reschke
>Assignee: Julian Reschke
>Priority: Minor
>  Labels: candidate_oak_1_6
> Fix For: 1.12, 1.11.0, 1.10.1, 1.8.12
>
>




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


[jira] [Closed] (OAK-8007) RDBDocumentStore: potential off-heap memory leakage due to unclosed GzipInputStream

2019-02-27 Thread Julian Reschke (JIRA)


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

Julian Reschke closed OAK-8007.
---

> RDBDocumentStore: potential off-heap memory leakage due to unclosed 
> GzipInputStream
> ---
>
> Key: OAK-8007
> URL: https://issues.apache.org/jira/browse/OAK-8007
> Project: Jackrabbit Oak
>  Issue Type: Bug
>  Components: rdbmk
>Reporter: Julian Reschke
>Assignee: Julian Reschke
>Priority: Minor
> Fix For: 1.12, 1.6.17, 1.11.0, 1.10.1, 1.8.12
>
> Attachments: OAK-8007.diff, OAK-8007.diff
>
>
> {{RDBDocumentSerializer}} does not close an instance of {{GZIPInputStream}}. 
> This may cause leakage off off-heap memory until the object is finalized (see 
> http://www.evanjones.ca/java-native-leak-bug.html, and thanks to [~jhoh] for 
> pointing this out).



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


[jira] [Closed] (OAK-8046) Result items are not always correctly counted against the configured read limit if a query uses a lucene index

2019-02-27 Thread Julian Reschke (JIRA)


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

Julian Reschke closed OAK-8046.
---

> Result items are not always correctly counted against the configured read 
> limit if a query uses a lucene index 
> ---
>
> Key: OAK-8046
> URL: https://issues.apache.org/jira/browse/OAK-8046
> Project: Jackrabbit Oak
>  Issue Type: Improvement
>  Components: lucene
>Affects Versions: 1.8.7
>Reporter: Georg Henzler
>Assignee: Vikas Saurabh
>Priority: Major
> Fix For: 1.12, 1.11.0, 1.10.1, 1.8.12
>
> Attachments: OAK-8046-take2.patch, OAK-8046.patch
>
>
> There are cases where an index is re-opened during query execution. In that 
> case, already returned entries are read again and skipped, so basically 
> counted twice. This should be fixed to only count entries once (see also [1])
> The issue most likely exists since the read limit was introduced with OAK-6875
> [1] 
> https://lists.apache.org/thread.html/dddf9834fee0bccb6e48f61ba2a01430e34fc0b464b12809f7dfe2eb@%3Coak-dev.jackrabbit.apache.org%3E



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


[jira] [Closed] (OAK-8068) Update slf4j dependency to 1.7.26

2019-02-27 Thread Julian Reschke (JIRA)


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

Julian Reschke closed OAK-8068.
---

> Update slf4j dependency to 1.7.26
> -
>
> Key: OAK-8068
> URL: https://issues.apache.org/jira/browse/OAK-8068
> Project: Jackrabbit Oak
>  Issue Type: Task
>  Components: parent
>Reporter: Julian Reschke
>Assignee: Julian Reschke
>Priority: Minor
>  Labels: candidate_oak_1_6
> Fix For: 1.12, 1.11.0, 1.10.1, 1.8.12
>
>




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


[jira] [Commented] (OAK-8086) Build Jackrabbit Oak #1974 failed

2019-02-27 Thread Hudson (JIRA)


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

Hudson commented on OAK-8086:
-

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

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



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


[jira] [Commented] (OAK-8013) [Direct Binary Access] DataRecordDownloadOptions creates invalid Content-Disposition headers

2019-02-27 Thread Matt Ryan (JIRA)


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

Matt Ryan commented on OAK-8013:


Workaround committed in revision [r1854489|https://svn.apache.org/r1854489].

> [Direct Binary Access] DataRecordDownloadOptions creates invalid 
> Content-Disposition headers
> 
>
> Key: OAK-8013
> URL: https://issues.apache.org/jira/browse/OAK-8013
> Project: Jackrabbit Oak
>  Issue Type: Bug
>  Components: blob-plugins
>Reporter: Alexander Klimetschek
>Assignee: Matt Ryan
>Priority: Major
> Fix For: 1.12
>
>
> DataRecordDownloadOptions always adds the extended parameter filename* to the 
> header, [without any 
> escaping|https://github.com/apache/jackrabbit-oak/blob/trunk/oak-blob-plugins/src/main/java/org/apache/jackrabbit/oak/plugins/blob/datastore/directaccess/DataRecordDownloadOptions.java#L130].
> Such extended parameters must not include spaces (and only a small predefined 
> list of basic ascii chars), otherwise they have to be percent encoded. The 
> RFC is https://tools.ietf.org/html/rfc5987 and note the definition of 
> value-chars in the grammar.
> Because of this, if a filename includes a space or another character that 
> must be percent encoded, this currently creates an invalid header that fails 
> to be parsed by other clients.
> See also https://github.com/jshttp/content-disposition/issues/24
>  



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


[jira] [Updated] (OAK-8013) [Direct Binary Access] DataRecordDownloadOptions creates invalid Content-Disposition headers

2019-02-27 Thread Matt Ryan (JIRA)


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

Matt Ryan updated OAK-8013:
---
Fix Version/s: 1.10.2

> [Direct Binary Access] DataRecordDownloadOptions creates invalid 
> Content-Disposition headers
> 
>
> Key: OAK-8013
> URL: https://issues.apache.org/jira/browse/OAK-8013
> Project: Jackrabbit Oak
>  Issue Type: Bug
>  Components: blob-plugins
>Reporter: Alexander Klimetschek
>Assignee: Matt Ryan
>Priority: Major
> Fix For: 1.12, 1.10.2
>
>
> DataRecordDownloadOptions always adds the extended parameter filename* to the 
> header, [without any 
> escaping|https://github.com/apache/jackrabbit-oak/blob/trunk/oak-blob-plugins/src/main/java/org/apache/jackrabbit/oak/plugins/blob/datastore/directaccess/DataRecordDownloadOptions.java#L130].
> Such extended parameters must not include spaces (and only a small predefined 
> list of basic ascii chars), otherwise they have to be percent encoded. The 
> RFC is https://tools.ietf.org/html/rfc5987 and note the definition of 
> value-chars in the grammar.
> Because of this, if a filename includes a space or another character that 
> must be percent encoded, this currently creates an invalid header that fails 
> to be parsed by other clients.
> See also https://github.com/jshttp/content-disposition/issues/24
>  



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


[jira] [Commented] (OAK-8013) [Direct Binary Access] DataRecordDownloadOptions creates invalid Content-Disposition headers

2019-02-27 Thread Matt Ryan (JIRA)


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

Matt Ryan commented on OAK-8013:


[~reschke] yes - at least two.  For this issue I will implement the workaround, 
and we will worry about handling this correctly in a different issue that I 
will create later.

> [Direct Binary Access] DataRecordDownloadOptions creates invalid 
> Content-Disposition headers
> 
>
> Key: OAK-8013
> URL: https://issues.apache.org/jira/browse/OAK-8013
> Project: Jackrabbit Oak
>  Issue Type: Bug
>  Components: blob-plugins
>Reporter: Alexander Klimetschek
>Assignee: Matt Ryan
>Priority: Major
> Fix For: 1.12
>
>
> DataRecordDownloadOptions always adds the extended parameter filename* to the 
> header, [without any 
> escaping|https://github.com/apache/jackrabbit-oak/blob/trunk/oak-blob-plugins/src/main/java/org/apache/jackrabbit/oak/plugins/blob/datastore/directaccess/DataRecordDownloadOptions.java#L130].
> Such extended parameters must not include spaces (and only a small predefined 
> list of basic ascii chars), otherwise they have to be percent encoded. The 
> RFC is https://tools.ietf.org/html/rfc5987 and note the definition of 
> value-chars in the grammar.
> Because of this, if a filename includes a space or another character that 
> must be percent encoded, this currently creates an invalid header that fails 
> to be parsed by other clients.
> See also https://github.com/jshttp/content-disposition/issues/24
>  



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


[jira] [Updated] (OAK-8013) [Direct Binary Access] DataRecordDownloadOptions creates invalid Content-Disposition headers

2019-02-27 Thread Matt Ryan (JIRA)


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

Matt Ryan updated OAK-8013:
---
Fix Version/s: 1.12

> [Direct Binary Access] DataRecordDownloadOptions creates invalid 
> Content-Disposition headers
> 
>
> Key: OAK-8013
> URL: https://issues.apache.org/jira/browse/OAK-8013
> Project: Jackrabbit Oak
>  Issue Type: Bug
>  Components: blob-plugins
>Reporter: Alexander Klimetschek
>Assignee: Matt Ryan
>Priority: Major
> Fix For: 1.12
>
>
> DataRecordDownloadOptions always adds the extended parameter filename* to the 
> header, [without any 
> escaping|https://github.com/apache/jackrabbit-oak/blob/trunk/oak-blob-plugins/src/main/java/org/apache/jackrabbit/oak/plugins/blob/datastore/directaccess/DataRecordDownloadOptions.java#L130].
> Such extended parameters must not include spaces (and only a small predefined 
> list of basic ascii chars), otherwise they have to be percent encoded. The 
> RFC is https://tools.ietf.org/html/rfc5987 and note the definition of 
> value-chars in the grammar.
> Because of this, if a filename includes a space or another character that 
> must be percent encoded, this currently creates an invalid header that fails 
> to be parsed by other clients.
> See also https://github.com/jshttp/content-disposition/issues/24
>  



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


[jira] [Commented] (OAK-8086) Build Jackrabbit Oak #1974 failed

2019-02-27 Thread Hudson (JIRA)


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

Hudson commented on OAK-8086:
-

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

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



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


[jira] [Commented] (OAK-8086) Build Jackrabbit Oak #1974 failed

2019-02-27 Thread Hudson (JIRA)


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

Hudson commented on OAK-8086:
-

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

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



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


[jira] [Commented] (OAK-8087) RDB*Store: update mssql-jdbc driver reference to 7.2.1.jre8

2019-02-27 Thread Julian Reschke (JIRA)


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

Julian Reschke commented on OAK-8087:
-

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

> RDB*Store: update mssql-jdbc driver reference to 7.2.1.jre8
> ---
>
> Key: OAK-8087
> URL: https://issues.apache.org/jira/browse/OAK-8087
> Project: Jackrabbit Oak
>  Issue Type: Technical task
>  Components: parent, rdbmk
>Reporter: Julian Reschke
>Assignee: Julian Reschke
>Priority: Minor
>  Labels: candidate_oak_1_10
> Fix For: 1.12, 1.11.0
>
>




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


[jira] [Updated] (OAK-8087) RDB*Store: update mssql-jdbc driver reference to 7.2.1.jre8

2019-02-27 Thread Julian Reschke (JIRA)


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

Julian Reschke updated OAK-8087:

Labels: candidate_oak_1_10  (was: )

> RDB*Store: update mssql-jdbc driver reference to 7.2.1.jre8
> ---
>
> Key: OAK-8087
> URL: https://issues.apache.org/jira/browse/OAK-8087
> Project: Jackrabbit Oak
>  Issue Type: Technical task
>  Components: parent, rdbmk
>Reporter: Julian Reschke
>Assignee: Julian Reschke
>Priority: Minor
>  Labels: candidate_oak_1_10
> Fix For: 1.12, 1.11.0
>
>




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


[jira] [Resolved] (OAK-8087) RDB*Store: update mssql-jdbc driver reference to 7.2.1.jre8

2019-02-27 Thread Julian Reschke (JIRA)


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

Julian Reschke resolved OAK-8087.
-
   Resolution: Fixed
Fix Version/s: 1.11.0

> RDB*Store: update mssql-jdbc driver reference to 7.2.1.jre8
> ---
>
> Key: OAK-8087
> URL: https://issues.apache.org/jira/browse/OAK-8087
> Project: Jackrabbit Oak
>  Issue Type: Technical task
>  Components: parent, rdbmk
>Reporter: Julian Reschke
>Assignee: Julian Reschke
>Priority: Minor
> Fix For: 1.12, 1.11.0
>
>




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


[jira] [Updated] (OAK-8088) Add refresh head revision time to background update stats

2019-02-27 Thread Julian Reschke (JIRA)


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

Julian Reschke updated OAK-8088:

Labels: candidate_oak_1_10  (was: )

> Add refresh head revision time to background update stats
> -
>
> Key: OAK-8088
> URL: https://issues.apache.org/jira/browse/OAK-8088
> Project: Jackrabbit Oak
>  Issue Type: Improvement
>  Components: documentmk
>Reporter: Marcel Reutegger
>Assignee: Marcel Reutegger
>Priority: Minor
>  Labels: candidate_oak_1_10
> Fix For: 1.12, 1.11.0
>
>
> The background update stats does not have timing information for refreshing 
> the head revision.



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


[jira] [Resolved] (OAK-8088) Add refresh head revision time to background update stats

2019-02-27 Thread Marcel Reutegger (JIRA)


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

Marcel Reutegger resolved OAK-8088.
---
   Resolution: Fixed
Fix Version/s: 1.11.0

Done in trunk: http://svn.apache.org/r1854466

> Add refresh head revision time to background update stats
> -
>
> Key: OAK-8088
> URL: https://issues.apache.org/jira/browse/OAK-8088
> Project: Jackrabbit Oak
>  Issue Type: Improvement
>  Components: documentmk
>Reporter: Marcel Reutegger
>Assignee: Marcel Reutegger
>Priority: Minor
> Fix For: 1.12, 1.11.0
>
>
> The background update stats does not have timing information for refreshing 
> the head revision.



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


[jira] [Created] (OAK-8089) DocumentNodeStore dispose can fail when duration of final background ops exceeds lease time

2019-02-27 Thread Julian Reschke (JIRA)
Julian Reschke created OAK-8089:
---

 Summary: DocumentNodeStore dispose can fail when duration of final 
background ops exceeds lease time
 Key: OAK-8089
 URL: https://issues.apache.org/jira/browse/OAK-8089
 Project: Jackrabbit Oak
  Issue Type: Bug
  Components: documentmk
Reporter: Julian Reschke
Assignee: Julian Reschke
 Fix For: 1.12


The problem is that {{dispose()}} let's the {{BackgroundLeaseUpdateThread}} 
once.

If the duration of the remaining operations then exceeds the lease update 
interval, these operations will fail with a {{DocumentStoreException}}.




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


[jira] [Commented] (OAK-8089) DocumentNodeStore dispose can fail when duration of final background ops exceeds lease time

2019-02-27 Thread Julian Reschke (JIRA)


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

Julian Reschke commented on OAK-8089:
-

Potential fix: introduce a separate {{AtomicBoolean}} to handle the disposure 
of the lease update thread.

> DocumentNodeStore dispose can fail when duration of final background ops 
> exceeds lease time
> ---
>
> Key: OAK-8089
> URL: https://issues.apache.org/jira/browse/OAK-8089
> Project: Jackrabbit Oak
>  Issue Type: Bug
>  Components: documentmk
>Reporter: Julian Reschke
>Assignee: Julian Reschke
>Priority: Minor
> Fix For: 1.12
>
>
> The problem is that {{dispose()}} let's the {{BackgroundLeaseUpdateThread}} 
> once.
> If the duration of the remaining operations then exceeds the lease update 
> interval, these operations will fail with a {{DocumentStoreException}}.



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


[jira] [Created] (OAK-8088) Add refresh head revision time to background update stats

2019-02-27 Thread Marcel Reutegger (JIRA)
Marcel Reutegger created OAK-8088:
-

 Summary: Add refresh head revision time to background update stats
 Key: OAK-8088
 URL: https://issues.apache.org/jira/browse/OAK-8088
 Project: Jackrabbit Oak
  Issue Type: Improvement
  Components: documentmk
Reporter: Marcel Reutegger
Assignee: Marcel Reutegger
 Fix For: 1.12


The background update stats does not have timing information for refreshing the 
head revision.



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


[jira] [Commented] (OAK-8071) Logging to detect commits carrying over from previous GC generation can block other threads from committing

2019-02-27 Thread Axel Hanikel (JIRA)


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

Axel Hanikel commented on OAK-8071:
---

[~mduerig] Sorry for the delay, I had to deal with some upgrade-related issues. 
The patch looks good to me.

> Logging to detect commits carrying over from previous GC generation can block 
> other threads from committing
> ---
>
> Key: OAK-8071
> URL: https://issues.apache.org/jira/browse/OAK-8071
> Project: Jackrabbit Oak
>  Issue Type: Technical task
>  Components: segment-tar
>Reporter: Michael Dürig
>Assignee: Michael Dürig
>Priority: Blocker
> Fix For: 1.12, 1.11.0, 1.8.12, 1.10.2
>
>
> Add logging / monitoring to detect the situation from OAK-8014.



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


[jira] [Created] (OAK-8087) RDB*Store: update mssql-jdbc driver reference to 7.2.1.jre8

2019-02-27 Thread Julian Reschke (JIRA)
Julian Reschke created OAK-8087:
---

 Summary: RDB*Store: update mssql-jdbc driver reference to 
7.2.1.jre8
 Key: OAK-8087
 URL: https://issues.apache.org/jira/browse/OAK-8087
 Project: Jackrabbit Oak
  Issue Type: Technical task
  Components: parent, rdbmk
Reporter: Julian Reschke
Assignee: Julian Reschke
 Fix For: 1.12






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


[jira] [Created] (OAK-8086) Build Jackrabbit Oak #1974 failed

2019-02-27 Thread Hudson (JIRA)
Hudson created OAK-8086:
---

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


No description is provided

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



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


[jira] [Commented] (OAK-8085) Upgrade spotbugs to 3.1.11

2019-02-27 Thread Julian Reschke (JIRA)


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

Julian Reschke commented on OAK-8085:
-

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

> Upgrade spotbugs to 3.1.11
> --
>
> Key: OAK-8085
> URL: https://issues.apache.org/jira/browse/OAK-8085
> Project: Jackrabbit Oak
>  Issue Type: Task
>  Components: parent
>Reporter: Julian Reschke
>Assignee: Julian Reschke
>Priority: Minor
>  Labels: candidate_oak_1_10, jdk11
> Fix For: 1.12, 1.11.0
>
>
> ...due to a Java 11 incompatibility:
> {noformat}
>  [java] The following errors occurred during analysis:
>  [java]   Error scanning java/lang/Throwable for referenced classes
>  [java] java.lang.UnsupportedOperationException
>  [java]   At 
> org.objectweb.asm.ClassVisitor.visitNestMemberExperimental(ClassVisitor.java:248)
>  [java]   At 
> org.objectweb.asm.ClassReader.accept(ClassReader.java:651)
>  [java]   At 
> edu.umd.cs.findbugs.asm.FBClassReader.accept(FBClassReader.java:44)
>  [java]   At 
> org.objectweb.asm.ClassReader.accept(ClassReader.java:391)
>  [java]   At 
> edu.umd.cs.findbugs.classfile.engine.ClassParserUsingASM.parse(ClassParserUsingASM.java:519)
>  [java]   At 
> edu.umd.cs.findbugs.classfile.engine.ClassParserUsingASM.parse(ClassParserUsingASM.java:703)
>  [java]   At 
> edu.umd.cs.findbugs.classfile.engine.ClassInfoAnalysisEngine.analyze(ClassInfoAnalysisEngine.java:79)
>  [java]   At 
> edu.umd.cs.findbugs.classfile.engine.ClassInfoAnalysisEngine.analyze(ClassInfoAnalysisEngine.java:38)
>  [java]   At 
> edu.umd.cs.findbugs.classfile.impl.AnalysisCache.getClassAnalysis(AnalysisCache.java:262)
>  [java]   At 
> edu.umd.cs.findbugs.FindBugs2.buildReferencedClassSet(FindBugs2.java:774)
>  [java]   At edu.umd.cs.findbugs.FindBugs2.execute(FindBugs2.java:220)
>  [java]   At edu.umd.cs.findbugs.FindBugs.runMain(FindBugs.java:401)
>  [java]   At edu.umd.cs.findbugs.FindBugs2.main(FindBugs2.java:1185)
> {noformat}



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


[jira] [Created] (OAK-8085) Upgrade spotbugs to 3.1.11

2019-02-27 Thread Julian Reschke (JIRA)
Julian Reschke created OAK-8085:
---

 Summary: Upgrade spotbugs to 3.1.11
 Key: OAK-8085
 URL: https://issues.apache.org/jira/browse/OAK-8085
 Project: Jackrabbit Oak
  Issue Type: Task
  Components: parent
Reporter: Julian Reschke
 Fix For: 1.12


...due to a Java 11 incompatibility:

{noformat}
 [java] The following errors occurred during analysis:
 [java]   Error scanning java/lang/Throwable for referenced classes
 [java] java.lang.UnsupportedOperationException
 [java]   At 
org.objectweb.asm.ClassVisitor.visitNestMemberExperimental(ClassVisitor.java:248)
 [java]   At org.objectweb.asm.ClassReader.accept(ClassReader.java:651)
 [java]   At 
edu.umd.cs.findbugs.asm.FBClassReader.accept(FBClassReader.java:44)
 [java]   At org.objectweb.asm.ClassReader.accept(ClassReader.java:391)
 [java]   At 
edu.umd.cs.findbugs.classfile.engine.ClassParserUsingASM.parse(ClassParserUsingASM.java:519)
 [java]   At 
edu.umd.cs.findbugs.classfile.engine.ClassParserUsingASM.parse(ClassParserUsingASM.java:703)
 [java]   At 
edu.umd.cs.findbugs.classfile.engine.ClassInfoAnalysisEngine.analyze(ClassInfoAnalysisEngine.java:79)
 [java]   At 
edu.umd.cs.findbugs.classfile.engine.ClassInfoAnalysisEngine.analyze(ClassInfoAnalysisEngine.java:38)
 [java]   At 
edu.umd.cs.findbugs.classfile.impl.AnalysisCache.getClassAnalysis(AnalysisCache.java:262)
 [java]   At 
edu.umd.cs.findbugs.FindBugs2.buildReferencedClassSet(FindBugs2.java:774)
 [java]   At edu.umd.cs.findbugs.FindBugs2.execute(FindBugs2.java:220)
 [java]   At edu.umd.cs.findbugs.FindBugs.runMain(FindBugs.java:401)
 [java]   At edu.umd.cs.findbugs.FindBugs2.main(FindBugs2.java:1185)

{noformat}




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


[jira] [Resolved] (OAK-8085) Upgrade spotbugs to 3.1.11

2019-02-27 Thread Julian Reschke (JIRA)


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

Julian Reschke resolved OAK-8085.
-
   Resolution: Fixed
Fix Version/s: 1.11.0

> Upgrade spotbugs to 3.1.11
> --
>
> Key: OAK-8085
> URL: https://issues.apache.org/jira/browse/OAK-8085
> Project: Jackrabbit Oak
>  Issue Type: Task
>  Components: parent
>Reporter: Julian Reschke
>Assignee: Julian Reschke
>Priority: Minor
>  Labels: candidate_oak_1_10, jdk11
> Fix For: 1.12, 1.11.0
>
>
> ...due to a Java 11 incompatibility:
> {noformat}
>  [java] The following errors occurred during analysis:
>  [java]   Error scanning java/lang/Throwable for referenced classes
>  [java] java.lang.UnsupportedOperationException
>  [java]   At 
> org.objectweb.asm.ClassVisitor.visitNestMemberExperimental(ClassVisitor.java:248)
>  [java]   At 
> org.objectweb.asm.ClassReader.accept(ClassReader.java:651)
>  [java]   At 
> edu.umd.cs.findbugs.asm.FBClassReader.accept(FBClassReader.java:44)
>  [java]   At 
> org.objectweb.asm.ClassReader.accept(ClassReader.java:391)
>  [java]   At 
> edu.umd.cs.findbugs.classfile.engine.ClassParserUsingASM.parse(ClassParserUsingASM.java:519)
>  [java]   At 
> edu.umd.cs.findbugs.classfile.engine.ClassParserUsingASM.parse(ClassParserUsingASM.java:703)
>  [java]   At 
> edu.umd.cs.findbugs.classfile.engine.ClassInfoAnalysisEngine.analyze(ClassInfoAnalysisEngine.java:79)
>  [java]   At 
> edu.umd.cs.findbugs.classfile.engine.ClassInfoAnalysisEngine.analyze(ClassInfoAnalysisEngine.java:38)
>  [java]   At 
> edu.umd.cs.findbugs.classfile.impl.AnalysisCache.getClassAnalysis(AnalysisCache.java:262)
>  [java]   At 
> edu.umd.cs.findbugs.FindBugs2.buildReferencedClassSet(FindBugs2.java:774)
>  [java]   At edu.umd.cs.findbugs.FindBugs2.execute(FindBugs2.java:220)
>  [java]   At edu.umd.cs.findbugs.FindBugs.runMain(FindBugs.java:401)
>  [java]   At edu.umd.cs.findbugs.FindBugs2.main(FindBugs2.java:1185)
> {noformat}



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


[jira] [Updated] (OAK-8085) Upgrade spotbugs to 3.1.11

2019-02-27 Thread Julian Reschke (JIRA)


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

Julian Reschke updated OAK-8085:

Labels: candidate_oak_1_10 jdk11  (was: )

> Upgrade spotbugs to 3.1.11
> --
>
> Key: OAK-8085
> URL: https://issues.apache.org/jira/browse/OAK-8085
> Project: Jackrabbit Oak
>  Issue Type: Task
>  Components: parent
>Reporter: Julian Reschke
>Priority: Minor
>  Labels: candidate_oak_1_10, jdk11
> Fix For: 1.12
>
>
> ...due to a Java 11 incompatibility:
> {noformat}
>  [java] The following errors occurred during analysis:
>  [java]   Error scanning java/lang/Throwable for referenced classes
>  [java] java.lang.UnsupportedOperationException
>  [java]   At 
> org.objectweb.asm.ClassVisitor.visitNestMemberExperimental(ClassVisitor.java:248)
>  [java]   At 
> org.objectweb.asm.ClassReader.accept(ClassReader.java:651)
>  [java]   At 
> edu.umd.cs.findbugs.asm.FBClassReader.accept(FBClassReader.java:44)
>  [java]   At 
> org.objectweb.asm.ClassReader.accept(ClassReader.java:391)
>  [java]   At 
> edu.umd.cs.findbugs.classfile.engine.ClassParserUsingASM.parse(ClassParserUsingASM.java:519)
>  [java]   At 
> edu.umd.cs.findbugs.classfile.engine.ClassParserUsingASM.parse(ClassParserUsingASM.java:703)
>  [java]   At 
> edu.umd.cs.findbugs.classfile.engine.ClassInfoAnalysisEngine.analyze(ClassInfoAnalysisEngine.java:79)
>  [java]   At 
> edu.umd.cs.findbugs.classfile.engine.ClassInfoAnalysisEngine.analyze(ClassInfoAnalysisEngine.java:38)
>  [java]   At 
> edu.umd.cs.findbugs.classfile.impl.AnalysisCache.getClassAnalysis(AnalysisCache.java:262)
>  [java]   At 
> edu.umd.cs.findbugs.FindBugs2.buildReferencedClassSet(FindBugs2.java:774)
>  [java]   At edu.umd.cs.findbugs.FindBugs2.execute(FindBugs2.java:220)
>  [java]   At edu.umd.cs.findbugs.FindBugs.runMain(FindBugs.java:401)
>  [java]   At edu.umd.cs.findbugs.FindBugs2.main(FindBugs2.java:1185)
> {noformat}



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


[jira] [Assigned] (OAK-8085) Upgrade spotbugs to 3.1.11

2019-02-27 Thread Julian Reschke (JIRA)


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

Julian Reschke reassigned OAK-8085:
---

Assignee: Julian Reschke

> Upgrade spotbugs to 3.1.11
> --
>
> Key: OAK-8085
> URL: https://issues.apache.org/jira/browse/OAK-8085
> Project: Jackrabbit Oak
>  Issue Type: Task
>  Components: parent
>Reporter: Julian Reschke
>Assignee: Julian Reschke
>Priority: Minor
>  Labels: candidate_oak_1_10, jdk11
> Fix For: 1.12
>
>
> ...due to a Java 11 incompatibility:
> {noformat}
>  [java] The following errors occurred during analysis:
>  [java]   Error scanning java/lang/Throwable for referenced classes
>  [java] java.lang.UnsupportedOperationException
>  [java]   At 
> org.objectweb.asm.ClassVisitor.visitNestMemberExperimental(ClassVisitor.java:248)
>  [java]   At 
> org.objectweb.asm.ClassReader.accept(ClassReader.java:651)
>  [java]   At 
> edu.umd.cs.findbugs.asm.FBClassReader.accept(FBClassReader.java:44)
>  [java]   At 
> org.objectweb.asm.ClassReader.accept(ClassReader.java:391)
>  [java]   At 
> edu.umd.cs.findbugs.classfile.engine.ClassParserUsingASM.parse(ClassParserUsingASM.java:519)
>  [java]   At 
> edu.umd.cs.findbugs.classfile.engine.ClassParserUsingASM.parse(ClassParserUsingASM.java:703)
>  [java]   At 
> edu.umd.cs.findbugs.classfile.engine.ClassInfoAnalysisEngine.analyze(ClassInfoAnalysisEngine.java:79)
>  [java]   At 
> edu.umd.cs.findbugs.classfile.engine.ClassInfoAnalysisEngine.analyze(ClassInfoAnalysisEngine.java:38)
>  [java]   At 
> edu.umd.cs.findbugs.classfile.impl.AnalysisCache.getClassAnalysis(AnalysisCache.java:262)
>  [java]   At 
> edu.umd.cs.findbugs.FindBugs2.buildReferencedClassSet(FindBugs2.java:774)
>  [java]   At edu.umd.cs.findbugs.FindBugs2.execute(FindBugs2.java:220)
>  [java]   At edu.umd.cs.findbugs.FindBugs.runMain(FindBugs.java:401)
>  [java]   At edu.umd.cs.findbugs.FindBugs2.main(FindBugs2.java:1185)
> {noformat}



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


[jira] [Resolved] (OAK-8084) LogCustomizer should allow instantiation with Java class (in addition to class name)

2019-02-27 Thread Julian Reschke (JIRA)


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

Julian Reschke resolved OAK-8084.
-
   Resolution: Fixed
Fix Version/s: 1.11.0

> LogCustomizer should allow instantiation with Java class (in addition to 
> class name)
> 
>
> Key: OAK-8084
> URL: https://issues.apache.org/jira/browse/OAK-8084
> Project: Jackrabbit Oak
>  Issue Type: Improvement
>  Components: commons
>Reporter: Julian Reschke
>Assignee: Julian Reschke
>Priority: Trivial
> Fix For: 1.12, 1.11.0
>
>




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


[jira] [Commented] (OAK-8084) LogCustomizer should allow instantiation with Java class (in addition to class name)

2019-02-27 Thread Julian Reschke (JIRA)


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

Julian Reschke commented on OAK-8084:
-

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

> LogCustomizer should allow instantiation with Java class (in addition to 
> class name)
> 
>
> Key: OAK-8084
> URL: https://issues.apache.org/jira/browse/OAK-8084
> Project: Jackrabbit Oak
>  Issue Type: Improvement
>  Components: commons
>Reporter: Julian Reschke
>Assignee: Julian Reschke
>Priority: Trivial
>  Labels: candidate_oak_1_10
> Fix For: 1.12, 1.11.0
>
>




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


[jira] [Updated] (OAK-8084) LogCustomizer should allow instantiation with Java class (in addition to class name)

2019-02-27 Thread Julian Reschke (JIRA)


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

Julian Reschke updated OAK-8084:

Labels: candidate_oak_1_10  (was: )

> LogCustomizer should allow instantiation with Java class (in addition to 
> class name)
> 
>
> Key: OAK-8084
> URL: https://issues.apache.org/jira/browse/OAK-8084
> Project: Jackrabbit Oak
>  Issue Type: Improvement
>  Components: commons
>Reporter: Julian Reschke
>Assignee: Julian Reschke
>Priority: Trivial
>  Labels: candidate_oak_1_10
> Fix For: 1.12, 1.11.0
>
>




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


[jira] [Created] (OAK-8084) LogCustomizer should allow instantiation with Java class (in addition to class name)

2019-02-27 Thread Julian Reschke (JIRA)
Julian Reschke created OAK-8084:
---

 Summary: LogCustomizer should allow instantiation with Java class 
(in addition to class name)
 Key: OAK-8084
 URL: https://issues.apache.org/jira/browse/OAK-8084
 Project: Jackrabbit Oak
  Issue Type: Improvement
  Components: commons
Reporter: Julian Reschke
Assignee: Julian Reschke
 Fix For: 1.12






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


[jira] [Commented] (OAK-7182) Make it possible to update Guava

2019-02-27 Thread Julian Sedding (JIRA)


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

Julian Sedding commented on OAK-7182:
-

bq. That would be similar to having an oak bundle that just wraps & shades 
Guava, right?

Yes, except you wouldn't shade Guava but deploy it instead. Thus Oak could stay 
slim. Furthermore, embedding (and not exporting) Guava may lead to class loader 
issues for cases where Guava classes are used in API signatures. I.e. class 
GuavaA inside Oak would be loaded from embedded/shaded classes, whereas client 
bundles may load it from another buzndle. Thus GuavaA != GuavaA as far as Java 
is concerned, because their class loaders mismatch.

bq. ... biggest roadblock ...

Agreed. That's were the most urgent action is needed and probably the biggest 
effort.



> Make it possible to update Guava
> 
>
> Key: OAK-7182
> URL: https://issues.apache.org/jira/browse/OAK-7182
> Project: Jackrabbit Oak
>  Issue Type: Wish
>Reporter: Julian Reschke
>Assignee: Julian Reschke
>Priority: Minor
> Attachments: GuavaTests.java, OAK-7182-guava-21-3.diff, 
> OAK-7182-guava-21-4.diff, OAK-7182-guava-21.diff, OAK-7182-guava-23.6.1.diff, 
> guava.diff
>
>
> We currently rely on Guava 15, and this affects all users of Oak because they 
> essentially need to use the same version.
> This is an overall issue to investigate what would need to be done in Oak in 
> order to make updates possible.



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


[jira] [Commented] (OAK-8051) PersistentCache: error during open can lead to incomplete initialization and subsequent NPEs

2019-02-27 Thread Julian Reschke (JIRA)


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

Julian Reschke commented on OAK-8051:
-

https://issues.apache.org/jira/secure/attachment/12960355/OAK-8051.diff

- adds the change proposed by [~tmueller]
- adds to the Javadoc
- adds to the existing test, inspecting the WARN level log

[~tmueller] - can you review?

> PersistentCache: error during open can lead to incomplete initialization and 
> subsequent NPEs
> 
>
> Key: OAK-8051
> URL: https://issues.apache.org/jira/browse/OAK-8051
> Project: Jackrabbit Oak
>  Issue Type: Bug
>  Components: documentmk
>Affects Versions: 1.6.6
>Reporter: Julian Reschke
>Priority: Major
>  Labels: candidate_oak_1_10, candidate_oak_1_6, 
> candidate_oak_1_8, patch-available
> Fix For: 1.12
>
> Attachments: OAK-8051.diff, OAK-8051.diff
>
>
> Seen in the wild (in 1.6.6):
> {noformat}
> 22.01.2019 08:45:13.153 *WARN* [http-/0.0.0.0:80-3] 
> org.apache.jackrabbit.oak.plugins.document.persistentCache.MapFactory Could 
> not open the store _path_/cache-4.data
> java.lang.IllegalStateException: The file is locked: nio:_path_/cache-4.data 
> [1.4.193/7]
>   at org.h2.mvstore.DataUtils.newIllegalStateException(DataUtils.java:765)
>   at org.h2.mvstore.FileStore.open(FileStore.java:168)
>   at org.h2.mvstore.MVStore.(MVStore.java:348)
>   at org.h2.mvstore.MVStore$Builder.open(MVStore.java:2923)
>   at 
> org.apache.jackrabbit.oak.plugins.document.persistentCache.PersistentCache$1.openStore(PersistentCache.java:288)
>   at 
> org.apache.jackrabbit.oak.plugins.document.persistentCache.PersistentCache.createMapFactory(PersistentCache.java:361)
>   at 
> org.apache.jackrabbit.oak.plugins.document.persistentCache.PersistentCache.(PersistentCache.java:210)
>   at 
> org.apache.jackrabbit.oak.plugins.document.DocumentMK$Builder.getPersistentCache(DocumentMK.java:1232)
>   at 
> org.apache.jackrabbit.oak.plugins.document.DocumentMK$Builder.buildCache(DocumentMK.java:1211)
> {noformat}
> Later on:
> {noformat}
> 22.01.2019 08:45:13.155 *WARN* [http-/0.0.0.0:80-3] 
> org.apache.jackrabbit.oak.plugins.document.persistentCache.MapFactory Could 
> not open the map
> java.lang.NullPointerException: null
>   at 
> org.apache.jackrabbit.oak.plugins.document.persistentCache.PersistentCache$1.openMap(PersistentCache.java:335)
>   at 
> org.apache.jackrabbit.oak.plugins.document.persistentCache.CacheMap.openMap(CacheMap.java:135)
>   at 
> org.apache.jackrabbit.oak.plugins.document.persistentCache.CacheMap.(CacheMap.java:48)
>   at 
> org.apache.jackrabbit.oak.plugins.document.persistentCache.PersistentCache.openMap(PersistentCache.java:468)
>   at 
> org.apache.jackrabbit.oak.plugins.document.persistentCache.NodeCache.addGeneration(NodeCache.java:115)
>   at 
> org.apache.jackrabbit.oak.plugins.document.persistentCache.PersistentCache.initGenerationCache(PersistentCache.java:452)
>   at 
> org.apache.jackrabbit.oak.plugins.document.persistentCache.PersistentCache.wrap(PersistentCache.java:443)
>   at 
> org.apache.jackrabbit.oak.plugins.document.DocumentMK$Builder.buildCache(DocumentMK.java:1214)
>   at 
> org.apache.jackrabbit.oak.plugins.document.DocumentMK$Builder.buildPrevDocumentsCache(DocumentMK.java:1182)
>   at 
> org.apache.jackrabbit.oak.plugins.document.DocumentMK$Builder.buildNodeDocumentCache(DocumentMK.java:1189)
>   at 
> org.apache.jackrabbit.oak.plugins.document.rdb.RDBDocumentStore.initialize(RDBDocumentStore.java:798)
>   at 
> org.apache.jackrabbit.oak.plugins.document.rdb.RDBDocumentStore.(RDBDocumentStore.java:212)
>   at 
> org.apache.jackrabbit.oak.plugins.document.rdb.RDBDocumentStore.(RDBDocumentStore.java:224)
>   at 
> org.apache.jackrabbit.oak.plugins.document.DocumentMK$Builder.setRDBConnection(DocumentMK.java:757)
>   at 
> org.apache.jackrabbit.oak.plugins.document.DocumentNodeStoreService.registerNodeStore(DocumentNodeStoreService.java:508)
>   at 
> org.apache.jackrabbit.oak.plugins.document.DocumentNodeStoreService.registerNodeStoreIfPossible(DocumentNodeStoreService.java:430)
>   at 
> org.apache.jackrabbit.oak.plugins.document.DocumentNodeStoreService.activate(DocumentNodeStoreService.java:414)
> {noformat}
> and then
> {noformat}
> 22.01.2019 08:45:16.808 *WARN* [http-/0.0.0.0:80-3] 
> org.apache.jackrabbit.oak.plugins.document.persistentCache.CacheMap 
> Re-opening map PREV_DOCUMENT
> java.lang.NullPointerException: null
>   at 
> org.apache.jackrabbit.oak.plugins.document.persistentCache.CacheMap.get(CacheMap.java:87)
>   at 
> 

[jira] [Updated] (OAK-8051) PersistentCache: error during open can lead to incomplete initialization and subsequent NPEs

2019-02-27 Thread Julian Reschke (JIRA)


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

Julian Reschke updated OAK-8051:

Attachment: OAK-8051.diff

> PersistentCache: error during open can lead to incomplete initialization and 
> subsequent NPEs
> 
>
> Key: OAK-8051
> URL: https://issues.apache.org/jira/browse/OAK-8051
> Project: Jackrabbit Oak
>  Issue Type: Bug
>  Components: documentmk
>Affects Versions: 1.6.6
>Reporter: Julian Reschke
>Priority: Major
>  Labels: candidate_oak_1_10, candidate_oak_1_6, 
> candidate_oak_1_8, patch-available
> Fix For: 1.12
>
> Attachments: OAK-8051.diff, OAK-8051.diff
>
>
> Seen in the wild (in 1.6.6):
> {noformat}
> 22.01.2019 08:45:13.153 *WARN* [http-/0.0.0.0:80-3] 
> org.apache.jackrabbit.oak.plugins.document.persistentCache.MapFactory Could 
> not open the store _path_/cache-4.data
> java.lang.IllegalStateException: The file is locked: nio:_path_/cache-4.data 
> [1.4.193/7]
>   at org.h2.mvstore.DataUtils.newIllegalStateException(DataUtils.java:765)
>   at org.h2.mvstore.FileStore.open(FileStore.java:168)
>   at org.h2.mvstore.MVStore.(MVStore.java:348)
>   at org.h2.mvstore.MVStore$Builder.open(MVStore.java:2923)
>   at 
> org.apache.jackrabbit.oak.plugins.document.persistentCache.PersistentCache$1.openStore(PersistentCache.java:288)
>   at 
> org.apache.jackrabbit.oak.plugins.document.persistentCache.PersistentCache.createMapFactory(PersistentCache.java:361)
>   at 
> org.apache.jackrabbit.oak.plugins.document.persistentCache.PersistentCache.(PersistentCache.java:210)
>   at 
> org.apache.jackrabbit.oak.plugins.document.DocumentMK$Builder.getPersistentCache(DocumentMK.java:1232)
>   at 
> org.apache.jackrabbit.oak.plugins.document.DocumentMK$Builder.buildCache(DocumentMK.java:1211)
> {noformat}
> Later on:
> {noformat}
> 22.01.2019 08:45:13.155 *WARN* [http-/0.0.0.0:80-3] 
> org.apache.jackrabbit.oak.plugins.document.persistentCache.MapFactory Could 
> not open the map
> java.lang.NullPointerException: null
>   at 
> org.apache.jackrabbit.oak.plugins.document.persistentCache.PersistentCache$1.openMap(PersistentCache.java:335)
>   at 
> org.apache.jackrabbit.oak.plugins.document.persistentCache.CacheMap.openMap(CacheMap.java:135)
>   at 
> org.apache.jackrabbit.oak.plugins.document.persistentCache.CacheMap.(CacheMap.java:48)
>   at 
> org.apache.jackrabbit.oak.plugins.document.persistentCache.PersistentCache.openMap(PersistentCache.java:468)
>   at 
> org.apache.jackrabbit.oak.plugins.document.persistentCache.NodeCache.addGeneration(NodeCache.java:115)
>   at 
> org.apache.jackrabbit.oak.plugins.document.persistentCache.PersistentCache.initGenerationCache(PersistentCache.java:452)
>   at 
> org.apache.jackrabbit.oak.plugins.document.persistentCache.PersistentCache.wrap(PersistentCache.java:443)
>   at 
> org.apache.jackrabbit.oak.plugins.document.DocumentMK$Builder.buildCache(DocumentMK.java:1214)
>   at 
> org.apache.jackrabbit.oak.plugins.document.DocumentMK$Builder.buildPrevDocumentsCache(DocumentMK.java:1182)
>   at 
> org.apache.jackrabbit.oak.plugins.document.DocumentMK$Builder.buildNodeDocumentCache(DocumentMK.java:1189)
>   at 
> org.apache.jackrabbit.oak.plugins.document.rdb.RDBDocumentStore.initialize(RDBDocumentStore.java:798)
>   at 
> org.apache.jackrabbit.oak.plugins.document.rdb.RDBDocumentStore.(RDBDocumentStore.java:212)
>   at 
> org.apache.jackrabbit.oak.plugins.document.rdb.RDBDocumentStore.(RDBDocumentStore.java:224)
>   at 
> org.apache.jackrabbit.oak.plugins.document.DocumentMK$Builder.setRDBConnection(DocumentMK.java:757)
>   at 
> org.apache.jackrabbit.oak.plugins.document.DocumentNodeStoreService.registerNodeStore(DocumentNodeStoreService.java:508)
>   at 
> org.apache.jackrabbit.oak.plugins.document.DocumentNodeStoreService.registerNodeStoreIfPossible(DocumentNodeStoreService.java:430)
>   at 
> org.apache.jackrabbit.oak.plugins.document.DocumentNodeStoreService.activate(DocumentNodeStoreService.java:414)
> {noformat}
> and then
> {noformat}
> 22.01.2019 08:45:16.808 *WARN* [http-/0.0.0.0:80-3] 
> org.apache.jackrabbit.oak.plugins.document.persistentCache.CacheMap 
> Re-opening map PREV_DOCUMENT
> java.lang.NullPointerException: null
>   at 
> org.apache.jackrabbit.oak.plugins.document.persistentCache.CacheMap.get(CacheMap.java:87)
>   at 
> org.apache.jackrabbit.oak.plugins.document.persistentCache.MultiGenerationMap.readValue(MultiGenerationMap.java:71)
>   at 
> org.apache.jackrabbit.oak.plugins.document.persistentCache.NodeCache.asyncReadIfPresent(NodeCache.java:147)
>   at 
> 

[jira] [Comment Edited] (OAK-7182) Make it possible to update Guava

2019-02-27 Thread Julian Sedding (JIRA)


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

Julian Sedding edited comment on OAK-7182 at 2/27/19 12:14 PM:
---

bq. That would be similar to having an oak bundle that just wraps & shades 
Guava, right?

Yes, except you wouldn't shade Guava but deploy it instead. Thus Oak could stay 
slim. Furthermore, embedding (and not exporting) Guava may lead to class loader 
issues for cases where Guava classes are used in API signatures. I.e. class 
GuavaA inside Oak would be loaded from embedded/shaded classes, whereas client 
bundles may load it from another buzndle. Thus GuavaA != GuavaA as far as Java 
is concerned, because their class loaders mismatch. If Guava classes keep 
static internal state that may also be problematic. I don't know if this is the 
case and whether it would be a problem in Oak.

bq. ... biggest roadblock ...

Agreed. That's were the most urgent action is needed and probably the biggest 
effort.




was (Author: jsedding):
bq. That would be similar to having an oak bundle that just wraps & shades 
Guava, right?

Yes, except you wouldn't shade Guava but deploy it instead. Thus Oak could stay 
slim. Furthermore, embedding (and not exporting) Guava may lead to class loader 
issues for cases where Guava classes are used in API signatures. I.e. class 
GuavaA inside Oak would be loaded from embedded/shaded classes, whereas client 
bundles may load it from another buzndle. Thus GuavaA != GuavaA as far as Java 
is concerned, because their class loaders mismatch.

bq. ... biggest roadblock ...

Agreed. That's were the most urgent action is needed and probably the biggest 
effort.



> Make it possible to update Guava
> 
>
> Key: OAK-7182
> URL: https://issues.apache.org/jira/browse/OAK-7182
> Project: Jackrabbit Oak
>  Issue Type: Wish
>Reporter: Julian Reschke
>Assignee: Julian Reschke
>Priority: Minor
> Attachments: GuavaTests.java, OAK-7182-guava-21-3.diff, 
> OAK-7182-guava-21-4.diff, OAK-7182-guava-21.diff, OAK-7182-guava-23.6.1.diff, 
> guava.diff
>
>
> We currently rely on Guava 15, and this affects all users of Oak because they 
> essentially need to use the same version.
> This is an overall issue to investigate what would need to be done in Oak in 
> order to make updates possible.



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


[jira] [Comment Edited] (OAK-8051) PersistentCache: error during open can lead to incomplete initialization and subsequent NPEs

2019-02-27 Thread Julian Reschke (JIRA)


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

Julian Reschke edited comment on OAK-8051 at 2/27/19 12:06 PM:
---

bq. What's wrong with the current code is that:
bq. 
bq. A NPE is logged in CacheMap, which can be confusing
bq. It would be better if 10 retries are attempted immediately in the 
constructor of CacheMap, instead of later on when trying to use the CacheMap

Actually what's wrong is that if the first attempt to open the map fails, the 
object fill have a null map and will not be in status closed, thus causing an 
NPE when calling {{get()}}. Changing the constructor to enforce {{map}} not be 
{{null}} or {{closed}} to be {{true}} indeed should fix this.


was (Author: reschke):
bq. What's wrong with the current code is that:
bq. 
bq. A NPE is logged in CacheMap, which can be confusing
bq. It would be better if 10 retries are attempted immediately in the 
constructor of CacheMap, instead of later on when trying to use the CacheMap

Actually what's wrong is that if the first attempt to open the map fails, the 
object fill have a null map and will not be in status closed, thus causing an 
NPE when calling {{get()}}. Changing the constructor to enforce {{map}} not be 
{null}} or {{closed}} to be {{true}} indeed should fix this.

> PersistentCache: error during open can lead to incomplete initialization and 
> subsequent NPEs
> 
>
> Key: OAK-8051
> URL: https://issues.apache.org/jira/browse/OAK-8051
> Project: Jackrabbit Oak
>  Issue Type: Bug
>  Components: documentmk
>Affects Versions: 1.6.6
>Reporter: Julian Reschke
>Priority: Major
>  Labels: candidate_oak_1_10, candidate_oak_1_6, 
> candidate_oak_1_8, patch-available
> Fix For: 1.12
>
> Attachments: OAK-8051.diff
>
>
> Seen in the wild (in 1.6.6):
> {noformat}
> 22.01.2019 08:45:13.153 *WARN* [http-/0.0.0.0:80-3] 
> org.apache.jackrabbit.oak.plugins.document.persistentCache.MapFactory Could 
> not open the store _path_/cache-4.data
> java.lang.IllegalStateException: The file is locked: nio:_path_/cache-4.data 
> [1.4.193/7]
>   at org.h2.mvstore.DataUtils.newIllegalStateException(DataUtils.java:765)
>   at org.h2.mvstore.FileStore.open(FileStore.java:168)
>   at org.h2.mvstore.MVStore.(MVStore.java:348)
>   at org.h2.mvstore.MVStore$Builder.open(MVStore.java:2923)
>   at 
> org.apache.jackrabbit.oak.plugins.document.persistentCache.PersistentCache$1.openStore(PersistentCache.java:288)
>   at 
> org.apache.jackrabbit.oak.plugins.document.persistentCache.PersistentCache.createMapFactory(PersistentCache.java:361)
>   at 
> org.apache.jackrabbit.oak.plugins.document.persistentCache.PersistentCache.(PersistentCache.java:210)
>   at 
> org.apache.jackrabbit.oak.plugins.document.DocumentMK$Builder.getPersistentCache(DocumentMK.java:1232)
>   at 
> org.apache.jackrabbit.oak.plugins.document.DocumentMK$Builder.buildCache(DocumentMK.java:1211)
> {noformat}
> Later on:
> {noformat}
> 22.01.2019 08:45:13.155 *WARN* [http-/0.0.0.0:80-3] 
> org.apache.jackrabbit.oak.plugins.document.persistentCache.MapFactory Could 
> not open the map
> java.lang.NullPointerException: null
>   at 
> org.apache.jackrabbit.oak.plugins.document.persistentCache.PersistentCache$1.openMap(PersistentCache.java:335)
>   at 
> org.apache.jackrabbit.oak.plugins.document.persistentCache.CacheMap.openMap(CacheMap.java:135)
>   at 
> org.apache.jackrabbit.oak.plugins.document.persistentCache.CacheMap.(CacheMap.java:48)
>   at 
> org.apache.jackrabbit.oak.plugins.document.persistentCache.PersistentCache.openMap(PersistentCache.java:468)
>   at 
> org.apache.jackrabbit.oak.plugins.document.persistentCache.NodeCache.addGeneration(NodeCache.java:115)
>   at 
> org.apache.jackrabbit.oak.plugins.document.persistentCache.PersistentCache.initGenerationCache(PersistentCache.java:452)
>   at 
> org.apache.jackrabbit.oak.plugins.document.persistentCache.PersistentCache.wrap(PersistentCache.java:443)
>   at 
> org.apache.jackrabbit.oak.plugins.document.DocumentMK$Builder.buildCache(DocumentMK.java:1214)
>   at 
> org.apache.jackrabbit.oak.plugins.document.DocumentMK$Builder.buildPrevDocumentsCache(DocumentMK.java:1182)
>   at 
> org.apache.jackrabbit.oak.plugins.document.DocumentMK$Builder.buildNodeDocumentCache(DocumentMK.java:1189)
>   at 
> org.apache.jackrabbit.oak.plugins.document.rdb.RDBDocumentStore.initialize(RDBDocumentStore.java:798)
>   at 
> org.apache.jackrabbit.oak.plugins.document.rdb.RDBDocumentStore.(RDBDocumentStore.java:212)
>   at 
> 

[jira] [Commented] (OAK-7182) Make it possible to update Guava

2019-02-27 Thread Julian Reschke (JIRA)


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

Julian Reschke commented on OAK-7182:
-

That would be similar to having an oak bundle that just wraps & shades Guava, 
right?

Right now the biggest roadblock is to identify the cases where we have exposed 
Guava interfaces in Oak APIs - because we will have to break those.

> Make it possible to update Guava
> 
>
> Key: OAK-7182
> URL: https://issues.apache.org/jira/browse/OAK-7182
> Project: Jackrabbit Oak
>  Issue Type: Wish
>Reporter: Julian Reschke
>Assignee: Julian Reschke
>Priority: Minor
> Attachments: GuavaTests.java, OAK-7182-guava-21-3.diff, 
> OAK-7182-guava-21-4.diff, OAK-7182-guava-21.diff, OAK-7182-guava-23.6.1.diff, 
> guava.diff
>
>
> We currently rely on Guava 15, and this affects all users of Oak because they 
> essentially need to use the same version.
> This is an overall issue to investigate what would need to be done in Oak in 
> order to make updates possible.



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


[jira] [Commented] (OAK-7182) Make it possible to update Guava

2019-02-27 Thread Julian Sedding (JIRA)


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

Julian Sedding commented on OAK-7182:
-

It might be an option to create a custom API (owned by Oak) in a separate 
bundle. This bundle would be the only one alloed to import Guava. Furthermore, 
there may be multiple implementations of the API. E.g. one using Guava 15, 
another using Guava 25 and possibly later an implementation owned entirely by 
Oak.

In order to be able to update Guava in an OSGi container only the matching 
implementation of this Oak API would need to be deployed.

This solution would allow for a gradual transition away from Guava while easing 
the pain immediately.

WDYT?

> Make it possible to update Guava
> 
>
> Key: OAK-7182
> URL: https://issues.apache.org/jira/browse/OAK-7182
> Project: Jackrabbit Oak
>  Issue Type: Wish
>Reporter: Julian Reschke
>Assignee: Julian Reschke
>Priority: Minor
> Attachments: GuavaTests.java, OAK-7182-guava-21-3.diff, 
> OAK-7182-guava-21-4.diff, OAK-7182-guava-21.diff, OAK-7182-guava-23.6.1.diff, 
> guava.diff
>
>
> We currently rely on Guava 15, and this affects all users of Oak because they 
> essentially need to use the same version.
> This is an overall issue to investigate what would need to be done in Oak in 
> order to make updates possible.



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