[jira] [Updated] (OAK-2405) Monitoring to track old NodeStates

2015-10-02 Thread JIRA 

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

Michael Dürig updated OAK-2405:
---
Fix Version/s: (was: 1.3.8)
   1.4

> Monitoring to track old NodeStates
> --
>
> Key: OAK-2405
> URL: https://issues.apache.org/jira/browse/OAK-2405
> Project: Jackrabbit Oak
>  Issue Type: Sub-task
>  Components: segmentmk
>Reporter: Michael Dürig
>Assignee: Michael Dürig
>  Labels: gc, monitoring, tooling
> Fix For: 1.4
>
>
> We should add some monitoring that allows us to track "old" node states, 
> which potentially block revision gc. 
> Possible approaches:
> * Add monitoring too old revisions (root node states) along with the stack 
> traces from where they have been acquired.
> * Include RecordId of root node state in the {{SessionMBean}}.
> * Add additional tooling on top of the {{SessionMBean}} to make it easier to 
> make sense of the wealth of information provided. 



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (OAK-3468) Replace BackgroundThread with Scheduler

2015-10-02 Thread JIRA 

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

Michael Dürig updated OAK-3468:
---
Labels: technical_debt  (was: )

> Replace BackgroundThread with Scheduler
> ---
>
> Key: OAK-3468
> URL: https://issues.apache.org/jira/browse/OAK-3468
> Project: Jackrabbit Oak
>  Issue Type: Technical task
>  Components: segmentmk
>Reporter: Michael Dürig
>  Labels: technical_debt
> Fix For: 1.4
>
>
> I think we should replace the background thread with some kind of a 
> scheduler. The goal would be to decouple threading from scheduling. IMO 
> threads should not be managed by the application but by the container. 



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (OAK-3468) Replace BackgroundThread with Scheduler

2015-10-02 Thread JIRA 
Michael Dürig created OAK-3468:
--

 Summary: Replace BackgroundThread with Scheduler
 Key: OAK-3468
 URL: https://issues.apache.org/jira/browse/OAK-3468
 Project: Jackrabbit Oak
  Issue Type: Technical task
  Components: segmentmk
Reporter: Michael Dürig


I think we should replace the background thread with some kind of a scheduler. 
The goal would be to decouple threading from scheduling. IMO threads should not 
be managed by the application but by the container. 



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (OAK-2635) TimeSeriesMax's frequent 'drops to 0'

2015-10-02 Thread JIRA 

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

Michael Dürig commented on OAK-2635:


Need fix from JCR-3860 to proceed here

> TimeSeriesMax's frequent 'drops to 0'
> -
>
> Key: OAK-2635
> URL: https://issues.apache.org/jira/browse/OAK-2635
> Project: Jackrabbit Oak
>  Issue Type: Bug
>  Components: core
>Affects Versions: 1.0.12
>Reporter: Stefan Egli
>Assignee: Michael Dürig
>  Labels: observation, tooling
> Fix For: 1.3.9
>
>
> The current implementation of TimeSeriesMax - which is what is backing eg the 
> very important 'ObservationQueueMaxLength' statistics - has a very infamous 
> behavior: it does very frequent, intermittent 'jumps back to 0'. This even 
> though the queue-lengths are still at the previous highs, as can often be 
> seen with subsequent measurements (which eg are still showing there are 1000 
> events in the observation queue).
> The reason seems to be that
> * the value is increased via {{TimeSeriesMax.recordValue()}} during a 1 
> second interval
> * reset to 0 via {{TimeSeriesMax.run()}} every second
> So basically, every second the counter is reset, then during 1 second if any 
> call to {{recordValue()}} happens, it is increased.
> This in my view is rather unfortunate - as it can result in mentioned 
> 'jumpy-0' behavior, but it can also jump to values in between if the largest 
> queue does not reports its length during 1 second.
> It sounds a bit like this was done this way intentionally? (perhaps to make 
> it as inexpensive as possible) or could this be fixed?



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (OAK-2635) TimeSeriesMax's frequent 'drops to 0'

2015-10-02 Thread JIRA 

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

Michael Dürig updated OAK-2635:
---
Attachment: OAK_2635.patch

Proposed patch using -1 to encode missing values of observation queue length. 
[~egli], please have a look.

> TimeSeriesMax's frequent 'drops to 0'
> -
>
> Key: OAK-2635
> URL: https://issues.apache.org/jira/browse/OAK-2635
> Project: Jackrabbit Oak
>  Issue Type: Bug
>  Components: core
>Affects Versions: 1.0.12
>Reporter: Stefan Egli
>Assignee: Michael Dürig
>  Labels: observation, tooling
> Fix For: 1.3.9
>
> Attachments: OAK_2635.patch
>
>
> The current implementation of TimeSeriesMax - which is what is backing eg the 
> very important 'ObservationQueueMaxLength' statistics - has a very infamous 
> behavior: it does very frequent, intermittent 'jumps back to 0'. This even 
> though the queue-lengths are still at the previous highs, as can often be 
> seen with subsequent measurements (which eg are still showing there are 1000 
> events in the observation queue).
> The reason seems to be that
> * the value is increased via {{TimeSeriesMax.recordValue()}} during a 1 
> second interval
> * reset to 0 via {{TimeSeriesMax.run()}} every second
> So basically, every second the counter is reset, then during 1 second if any 
> call to {{recordValue()}} happens, it is increased.
> This in my view is rather unfortunate - as it can result in mentioned 
> 'jumpy-0' behavior, but it can also jump to values in between if the largest 
> queue does not reports its length during 1 second.
> It sounds a bit like this was done this way intentionally? (perhaps to make 
> it as inexpensive as possible) or could this be fixed?



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (OAK-3460) Progress logging for RepositorySidegrade

2015-10-02 Thread JIRA 

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

Michael Dürig commented on OAK-3460:


Patch looks good to me. Note that wrapping of node states is notoriously 
difficult though regarding correctness and performance of 
{{compareAgainstBaseState}} and {{equals}}. The former seems fine, the latter 
is missing though and I would propose something like:

{code}
@Override
public boolean equals(Object other) {
if (other instanceof ReportingNodeState) {
return delegate.equals(((ReportingNodeState) other).delegate);
} else {
return delegate.equals(other);
}
}
{code}

This will still have some performance implications when a 
{{ReportingNodeState}} is passed to the equals method of e.g. 
{{SegmentNodeState}} as it will fall back to {{AbstractNodeState#equals}} in 
that case. I thinks this is fine, but we should but a note to that respect into 
the Javadoc of {{ReportingNodeState}}. 

Regarding {{ReportingNodeStateTest}}, it would be good to have a test case 
there covering {{compareAgainstBaseState}} in the recursive case (i.e. where a 
tree of several levels is traversed). 

> Progress logging for RepositorySidegrade
> 
>
> Key: OAK-3460
> URL: https://issues.apache.org/jira/browse/OAK-3460
> Project: Jackrabbit Oak
>  Issue Type: Improvement
>  Components: upgrade
>Affects Versions: 1.0.21, 1.3.6, 1.2.6
>Reporter: Julian Sedding
>Assignee: Julian Sedding
> Attachments: OAK-3460.patch
>
>
> Currently the RepositorySidegrade (aka NodeStore to NodeStore copy) has no 
> progress logging. RepositoryUpgrade logs a message every 10'000th node. It 
> would be nice if RepositorySidegrade did the same.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (OAK-3290) Revision gc blocks repository shutdown

2015-10-02 Thread JIRA 

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

Michael Dürig updated OAK-3290:
---
Fix Version/s: (was: 1.0.22)
   (was: 1.2.7)
   1.2.8
   1.0.23

> Revision gc blocks repository shutdown
> --
>
> Key: OAK-3290
> URL: https://issues.apache.org/jira/browse/OAK-3290
> Project: Jackrabbit Oak
>  Issue Type: Improvement
>  Components: segmentmk
>Reporter: Michael Dürig
>Assignee: Michael Dürig
>  Labels: cleanup, compaction, gc
> Fix For: 1.3.8, 1.0.23, 1.2.8
>
>
> Shutting down the repository while revision gc is running might block for a 
> long time until either compaction estimation/compaction or clean up has 
> finished. We should provide a way to interrupt those operations for a timely 
> shut down. 



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (OAK-2881) ConsistencyChecker#checkConsistency can't cope with inconsistent journal

2015-10-02 Thread JIRA 

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

Michael Dürig updated OAK-2881:
---
Priority: Minor  (was: Major)

> ConsistencyChecker#checkConsistency can't cope with inconsistent journal
> 
>
> Key: OAK-2881
> URL: https://issues.apache.org/jira/browse/OAK-2881
> Project: Jackrabbit Oak
>  Issue Type: Bug
>  Components: run
>Reporter: Michael Dürig
>Assignee: Michael Dürig
>Priority: Minor
>  Labels: resilience, tooling
> Fix For: 1.3.8
>
>
> When running the consistency checker against a repository with a corrupt 
> journal, it fails with an {{ISA}} instead of trying to skip over invalid 
> revision identifiers:
> {noformat}
> Exception in thread "main" java.lang.IllegalArgumentException: Bad record 
> identifier: foobar
> at 
> org.apache.jackrabbit.oak.plugins.segment.RecordId.fromString(RecordId.java:57)
> at 
> org.apache.jackrabbit.oak.plugins.segment.file.FileStore.(FileStore.java:227)
> at 
> org.apache.jackrabbit.oak.plugins.segment.file.FileStore.(FileStore.java:178)
> at 
> org.apache.jackrabbit.oak.plugins.segment.file.FileStore.(FileStore.java:156)
> at 
> org.apache.jackrabbit.oak.plugins.segment.file.FileStore.(FileStore.java:166)
> at 
> org.apache.jackrabbit.oak.plugins.segment.file.FileStore$ReadOnlyStore.(FileStore.java:805)
> at 
> org.apache.jackrabbit.oak.plugins.segment.file.tooling.ConsistencyChecker.(ConsistencyChecker.java:108)
> at 
> org.apache.jackrabbit.oak.plugins.segment.file.tooling.ConsistencyChecker.checkConsistency(ConsistencyChecker.java:70)
> at org.apache.jackrabbit.oak.run.Main.check(Main.java:701)
> at org.apache.jackrabbit.oak.run.Main.main(Main.java:158)
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (OAK-2879) Compaction should check for required disk space before running

2015-10-02 Thread Francesco Mari (JIRA) 

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

Francesco Mari updated OAK-2879:

Attachment: OAK-2879-02.patch

[~mduerig], [^OAK-2879-02.patch] should address your concerns. The code doesn't 
rely on interruptions anymore, but it implements its own cancelation strategy.

> Compaction should check for required disk space before running
> --
>
> Key: OAK-2879
> URL: https://issues.apache.org/jira/browse/OAK-2879
> Project: Jackrabbit Oak
>  Issue Type: Sub-task
>  Components: segmentmk
>Reporter: Michael Dürig
>Assignee: Francesco Mari
>  Labels: compaction, doc-impacting, gc, resilience
> Fix For: 1.3.8
>
> Attachments: OAK-2879-01.patch, OAK-2879-02.patch
>
>
> In the worst case compaction doubles the repository size while running. As 
> this is somewhat unexpected we should check whether there is enough free disk 
> space before running compaction and log a warning otherwise. This is to avoid 
> a common source of running out of disk space and ending up with a corrupted 
> repository. 



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (OAK-1576) SegmentMK: Implement refined conflict resolution for addExistingNode conflicts

2015-10-02 Thread JIRA 

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

Michael Dürig updated OAK-1576:
---
Fix Version/s: (was: 1.3.9)
   1.4

> SegmentMK: Implement refined conflict resolution for addExistingNode conflicts
> --
>
> Key: OAK-1576
> URL: https://issues.apache.org/jira/browse/OAK-1576
> Project: Jackrabbit Oak
>  Issue Type: Sub-task
>  Components: segmentmk
>Reporter: Michael Dürig
>Assignee: Michael Dürig
>  Labels: concurrency, resilience, scalability
> Fix For: 1.4
>
>
> Implement refined conflict resolution for addExistingNode conflicts as 
> defined in the parent issue for the SegementMK.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (OAK-3396) NPE during syncAllExternalUsers in LdapIdentityProvider.createUser

2015-10-02 Thread Davide Giannella (JIRA) 

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

Davide Giannella updated OAK-3396:
--
Priority: Blocker  (was: Minor)

> NPE during syncAllExternalUsers in LdapIdentityProvider.createUser
> --
>
> Key: OAK-3396
> URL: https://issues.apache.org/jira/browse/OAK-3396
> Project: Jackrabbit Oak
>  Issue Type: Bug
>  Components: auth-ldap
>Affects Versions: 1.0.18
>Reporter: Stefan Egli
>Assignee: Tobias Bocanegra
>Priority: Blocker
> Fix For: 1.0.22
>
> Attachments: OAK-3396.patch, OAK-3396.patch.v2
>
>
> When executing the JMX method syncAllExternalUsers the following NPE has been 
> encountered. This likely indicates that - for a particular user - there is no 
> attribute '{{uid}}':
> {code}
> java.lang.NullPointerException
> at 
> org.apache.jackrabbit.oak.security.authentication.ldap.impl.LdapIdentityProvider.createUser(LdapIdentityProvider.java:667)
> at 
> org.apache.jackrabbit.oak.security.authentication.ldap.impl.LdapIdentityProvider.access$000(LdapIdentityProvider.java:88)
> at 
> org.apache.jackrabbit.oak.security.authentication.ldap.impl.LdapIdentityProvider$1.getNext(LdapIdentityProvider.java:281)
> at 
> org.apache.jackrabbit.oak.security.authentication.ldap.impl.LdapIdentityProvider$1.getNext(LdapIdentityProvider.java:273)
> at 
> org.apache.jackrabbit.commons.iterator.AbstractLazyIterator.hasNext(AbstractLazyIterator.java:39)
> at 
> org.apache.jackrabbit.oak.spi.security.authentication.external.impl.jmx.SyncMBeanImpl$Delegatee.syncAllExternalUsers(SyncMBeanImpl.java:245)
> at 
> org.apache.jackrabbit.oak.spi.security.authentication.external.impl.jmx.SyncMBeanImpl.syncAllExternalUsers(SyncMBeanImpl.java:426)
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (OAK-3172) Unreleased closed sessions can keep a root reference from getting collected

2015-10-02 Thread JIRA 

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

Michael Dürig commented on OAK-3172:


I actually made similar observation while evaluation the patches for OAK-3348. 
There I tentatively nulled out the {{SessionDelegate.root}}, 
{{SessionContext.sessionContext}} and {{SessionDelegate.sd}} references. It 
improved the situation somewhat but needs further following up. 


> Unreleased closed sessions can keep a root reference from getting collected
> ---
>
> Key: OAK-3172
> URL: https://issues.apache.org/jira/browse/OAK-3172
> Project: Jackrabbit Oak
>  Issue Type: Sub-task
>  Components: segmentmk
>Reporter: Alex Parvulescu
>Assignee: Alex Parvulescu
>  Labels: compaction, gc
> Fix For: 1.4
>
>
> It looks like even if a component logs out a session, but keeps a reference 
> to it around this will still prevent GC from running, as the session will 
> wrap a _root_ reference pointing to the moment/revision when the session was 
> last accessed.
> Extract from jvisualvm:
> {code}
> this - value: org.apache.jackrabbit.oak.plugins.segment.SegmentId #505
>  <- [106] - class: org.apache.jackrabbit.oak.plugins.segment.SegmentId[], 
> value: org.apache.jackrabbit.oak.plugins.segment.SegmentId #505
>   <- refids - class: org.apache.jackrabbit.oak.plugins.segment.Segment, 
> value: org.apache.jackrabbit.oak.plugins.segment.SegmentId[] #67 (120 items)
><- segment - class: 
> org.apache.jackrabbit.oak.plugins.segment.SegmentId, value: 
> org.apache.jackrabbit.oak.plugins.segment.Segment #81
> <- [124] - class: 
> org.apache.jackrabbit.oak.plugins.segment.SegmentId[], value: 
> org.apache.jackrabbit.oak.plugins.segment.SegmentId #496
>  <- refids - class: 
> org.apache.jackrabbit.oak.plugins.segment.Segment, value: 
> org.apache.jackrabbit.oak.plugins.segment.SegmentId[] #17 (204 items)
>   <- segment - class: 
> org.apache.jackrabbit.oak.plugins.segment.SegmentId, value: 
> org.apache.jackrabbit.oak.plugins.segment.Segment #17
><- segmentId - class: 
> org.apache.jackrabbit.oak.plugins.segment.SegmentNodeState, value: 
> org.apache.jackrabbit.oak.plugins.segment.SegmentId #551
> <- base - class: 
> org.apache.jackrabbit.oak.plugins.segment.SegmentNodeBuilder, value: 
> org.apache.jackrabbit.oak.plugins.segment.SegmentNodeState #5557
>  <- builder - class: org.apache.jackrabbit.oak.core.MutableRoot, 
> value: org.apache.jackrabbit.oak.plugins.segment.SegmentNodeBuilder #5652
>   <- root - class: 
> org.apache.jackrabbit.oak.jcr.repository.RepositoryImpl$1, value: 
> org.apache.jackrabbit.oak.core.MutableRoot #151
><- sd - class: 
> com.adobe.granite.repository.impl.CRX3SessionImpl, value: 
> org.apache.jackrabbit.oak.jcr.repository.RepositoryImpl$1 #117
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (OAK-2879) Compaction should check for required disk space before running

2015-10-02 Thread JIRA 

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

Michael Dürig commented on OAK-2879:


General approach looks good. However we need to avoid using 
{{Thread.interrupt}} as it can interfere with NIO (see OAK-2609) and come up 
with a custom approach of signalling interruption. 

Nice thing is that OAK-3290 will also profit from this work!

Regarding the additional logging, we should probably change the wording in 
"transient changes will be discarded at next cleanup" as "transient changes" 
will confuse people. 




> Compaction should check for required disk space before running
> --
>
> Key: OAK-2879
> URL: https://issues.apache.org/jira/browse/OAK-2879
> Project: Jackrabbit Oak
>  Issue Type: Sub-task
>  Components: segmentmk
>Reporter: Michael Dürig
>Assignee: Francesco Mari
>  Labels: compaction, doc-impacting, gc, resilience
> Fix For: 1.3.8
>
> Attachments: OAK-2879-01.patch
>
>
> In the worst case compaction doubles the repository size while running. As 
> this is somewhat unexpected we should check whether there is enough free disk 
> space before running compaction and log a warning otherwise. This is to avoid 
> a common source of running out of disk space and ending up with a corrupted 
> repository. 



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (OAK-2879) Compaction should check for required disk space before running

2015-10-02 Thread JIRA 

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

Michael Dürig commented on OAK-2879:


This doesn't properly cancel diffing while busy inside a big sub-tree AFAICS. 
Maybe passing a {{Predicate}} into the diffs to determine the cancellation 
status would work better?

What is the idea re. {{CompactionStrategy#isDiskSpaceSufficient}}? Currently 
that method just returns true so compaction would never be cancelled. 

Finally I have some concerns regarding calling {{FileStore#size}}. I have seen 
this method contending the file store when called all too often. Do really need 
the current size? Can we call it less often? Otherwise we might be able 
minimise the lock in its implementation. 

> Compaction should check for required disk space before running
> --
>
> Key: OAK-2879
> URL: https://issues.apache.org/jira/browse/OAK-2879
> Project: Jackrabbit Oak
>  Issue Type: Sub-task
>  Components: segmentmk
>Reporter: Michael Dürig
>Assignee: Francesco Mari
>  Labels: compaction, doc-impacting, gc, resilience
> Fix For: 1.3.8
>
> Attachments: OAK-2879-01.patch, OAK-2879-02.patch
>
>
> In the worst case compaction doubles the repository size while running. As 
> this is somewhat unexpected we should check whether there is enough free disk 
> space before running compaction and log a warning otherwise. This is to avoid 
> a common source of running out of disk space and ending up with a corrupted 
> repository. 



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (OAK-2879) Compaction should check for required disk space before running

2015-10-02 Thread Francesco Mari (JIRA) 

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

Francesco Mari commented on OAK-2879:
-

bq. This doesn't properly cancel diffing while busy inside a big sub-tree 
AFAICS. Maybe passing a Predicate into the diffs to determine the cancellation 
status would work better?

Yes, my solution is broken. I like the idea of the {{Predicate}}, I will rework 
the approach.

bq. What is the idea re. CompactionStrategy#isDiskSpaceSufficient? Currently 
that method just returns true so compaction would never be cancelled.

The patch is far to be complete, the method was there just to show how the 
{{CompactionStrategy}} could influence compaction with regard to disk space. I 
still didn't come up with a proper heuristic to stop compaction.

bq. Do really need the current size? Can we call it less often?

Yes, the method should probably be called less often. But what is the right 
frequency of the background thread checking the disk space? Should the thread 
be always active? Should the thread be active only when compaction is running, 
instead? What if, instead of checking the disk space via {{size()}}, we 
increment the known size of the store using {{FileStore#writeSegment()}} as a 
hook? In this case, we can reset the size after a cleanup.

There is still some thinking to do before the patch will be complete, but now 
that I know that the approach is correct (on a very high level) I can improve 
on what I have.

> Compaction should check for required disk space before running
> --
>
> Key: OAK-2879
> URL: https://issues.apache.org/jira/browse/OAK-2879
> Project: Jackrabbit Oak
>  Issue Type: Sub-task
>  Components: segmentmk
>Reporter: Michael Dürig
>Assignee: Francesco Mari
>  Labels: compaction, doc-impacting, gc, resilience
> Fix For: 1.3.8
>
> Attachments: OAK-2879-01.patch, OAK-2879-02.patch
>
>
> In the worst case compaction doubles the repository size while running. As 
> this is somewhat unexpected we should check whether there is enough free disk 
> space before running compaction and log a warning otherwise. This is to avoid 
> a common source of running out of disk space and ending up with a corrupted 
> repository. 



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (OAK-3396) NPE during syncAllExternalUsers in LdapIdentityProvider.createUser

2015-10-02 Thread Tobias Bocanegra (JIRA) 

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

Tobias Bocanegra updated OAK-3396:
--
Fix Version/s: 1.2.7
   1.3.8

> NPE during syncAllExternalUsers in LdapIdentityProvider.createUser
> --
>
> Key: OAK-3396
> URL: https://issues.apache.org/jira/browse/OAK-3396
> Project: Jackrabbit Oak
>  Issue Type: Bug
>  Components: auth-ldap
>Affects Versions: 1.0.18
>Reporter: Stefan Egli
>Assignee: Tobias Bocanegra
>Priority: Blocker
> Fix For: 1.3.8, 1.2.7, 1.0.22
>
> Attachments: OAK-3396.patch, OAK-3396.patch.v2
>
>
> When executing the JMX method syncAllExternalUsers the following NPE has been 
> encountered. This likely indicates that - for a particular user - there is no 
> attribute '{{uid}}':
> {code}
> java.lang.NullPointerException
> at 
> org.apache.jackrabbit.oak.security.authentication.ldap.impl.LdapIdentityProvider.createUser(LdapIdentityProvider.java:667)
> at 
> org.apache.jackrabbit.oak.security.authentication.ldap.impl.LdapIdentityProvider.access$000(LdapIdentityProvider.java:88)
> at 
> org.apache.jackrabbit.oak.security.authentication.ldap.impl.LdapIdentityProvider$1.getNext(LdapIdentityProvider.java:281)
> at 
> org.apache.jackrabbit.oak.security.authentication.ldap.impl.LdapIdentityProvider$1.getNext(LdapIdentityProvider.java:273)
> at 
> org.apache.jackrabbit.commons.iterator.AbstractLazyIterator.hasNext(AbstractLazyIterator.java:39)
> at 
> org.apache.jackrabbit.oak.spi.security.authentication.external.impl.jmx.SyncMBeanImpl$Delegatee.syncAllExternalUsers(SyncMBeanImpl.java:245)
> at 
> org.apache.jackrabbit.oak.spi.security.authentication.external.impl.jmx.SyncMBeanImpl.syncAllExternalUsers(SyncMBeanImpl.java:426)
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (OAK-3396) NPE during syncAllExternalUsers in LdapIdentityProvider.createUser

2015-10-02 Thread Tobias Bocanegra (JIRA) 

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

Tobias Bocanegra commented on OAK-3396:
---

fixed in trunk: r1706457

> NPE during syncAllExternalUsers in LdapIdentityProvider.createUser
> --
>
> Key: OAK-3396
> URL: https://issues.apache.org/jira/browse/OAK-3396
> Project: Jackrabbit Oak
>  Issue Type: Bug
>  Components: auth-ldap
>Affects Versions: 1.0.18
>Reporter: Stefan Egli
>Assignee: Tobias Bocanegra
>Priority: Blocker
> Fix For: 1.3.8, 1.2.7, 1.0.22
>
> Attachments: OAK-3396.patch, OAK-3396.patch.v2
>
>
> When executing the JMX method syncAllExternalUsers the following NPE has been 
> encountered. This likely indicates that - for a particular user - there is no 
> attribute '{{uid}}':
> {code}
> java.lang.NullPointerException
> at 
> org.apache.jackrabbit.oak.security.authentication.ldap.impl.LdapIdentityProvider.createUser(LdapIdentityProvider.java:667)
> at 
> org.apache.jackrabbit.oak.security.authentication.ldap.impl.LdapIdentityProvider.access$000(LdapIdentityProvider.java:88)
> at 
> org.apache.jackrabbit.oak.security.authentication.ldap.impl.LdapIdentityProvider$1.getNext(LdapIdentityProvider.java:281)
> at 
> org.apache.jackrabbit.oak.security.authentication.ldap.impl.LdapIdentityProvider$1.getNext(LdapIdentityProvider.java:273)
> at 
> org.apache.jackrabbit.commons.iterator.AbstractLazyIterator.hasNext(AbstractLazyIterator.java:39)
> at 
> org.apache.jackrabbit.oak.spi.security.authentication.external.impl.jmx.SyncMBeanImpl$Delegatee.syncAllExternalUsers(SyncMBeanImpl.java:245)
> at 
> org.apache.jackrabbit.oak.spi.security.authentication.external.impl.jmx.SyncMBeanImpl.syncAllExternalUsers(SyncMBeanImpl.java:426)
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (OAK-3311) Potential NPE in syncAllExternalUsers() aborts the process

2015-10-02 Thread Tobias Bocanegra (JIRA) 

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

Tobias Bocanegra commented on OAK-3311:
---

fixed in trunk: r1706459

> Potential NPE in syncAllExternalUsers() aborts the process
> --
>
> Key: OAK-3311
> URL: https://issues.apache.org/jira/browse/OAK-3311
> Project: Jackrabbit Oak
>  Issue Type: Bug
>  Components: auth-external
>Affects Versions: 1.2.4, 1.3.4, 1.0.19
>Reporter: Tobias Bocanegra
>Assignee: Tobias Bocanegra
>Priority: Blocker
> Fix For: 1.3.9, 1.2.7, 1.0.22
>
> Attachments: OAK-3311-1.0.19.patch
>
>
> The iteration over all users in {{syncAllExternalUsers()}} aborts if there is 
> an uncaught NPE.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (OAK-3311) Potential NPE in syncAllExternalUsers() aborts the process

2015-10-02 Thread Tobias Bocanegra (JIRA) 

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

Tobias Bocanegra commented on OAK-3311:
---

bq. missing test-case verifying that the issue is actually valid and that the 
patch actually addresses it.
unfortunately, I don't know how to create a test case here, since the MBean 
needs a JCR repository, but the test is in oak. either there is an easy way to 
retrieve the repository, or we need to rewrite the sync handler to use oak 
directly instead of JCR - or at least the MBean.

> Potential NPE in syncAllExternalUsers() aborts the process
> --
>
> Key: OAK-3311
> URL: https://issues.apache.org/jira/browse/OAK-3311
> Project: Jackrabbit Oak
>  Issue Type: Bug
>  Components: auth-external
>Affects Versions: 1.2.4, 1.3.4, 1.0.19
>Reporter: Tobias Bocanegra
>Assignee: Tobias Bocanegra
>Priority: Blocker
> Fix For: 1.3.9, 1.2.7, 1.0.22
>
> Attachments: OAK-3311-1.0.19.patch
>
>
> The iteration over all users in {{syncAllExternalUsers()}} aborts if there is 
> an uncaught NPE.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (OAK-3311) Potential NPE in syncAllExternalUsers() aborts the process

2015-10-02 Thread Tobias Bocanegra (JIRA) 

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

Tobias Bocanegra updated OAK-3311:
--
Fix Version/s: 1.2.7
   1.3.9

> Potential NPE in syncAllExternalUsers() aborts the process
> --
>
> Key: OAK-3311
> URL: https://issues.apache.org/jira/browse/OAK-3311
> Project: Jackrabbit Oak
>  Issue Type: Bug
>  Components: auth-external
>Affects Versions: 1.2.4, 1.3.4, 1.0.19
>Reporter: Tobias Bocanegra
>Assignee: Tobias Bocanegra
>Priority: Blocker
> Fix For: 1.3.9, 1.2.7, 1.0.22
>
> Attachments: OAK-3311-1.0.19.patch
>
>
> The iteration over all users in {{syncAllExternalUsers()}} aborts if there is 
> an uncaught NPE.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Resolved] (OAK-3311) Potential NPE in syncAllExternalUsers() aborts the process

2015-10-02 Thread Tobias Bocanegra (JIRA) 

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

Tobias Bocanegra resolved OAK-3311.
---
Resolution: Fixed

> Potential NPE in syncAllExternalUsers() aborts the process
> --
>
> Key: OAK-3311
> URL: https://issues.apache.org/jira/browse/OAK-3311
> Project: Jackrabbit Oak
>  Issue Type: Bug
>  Components: auth-external
>Affects Versions: 1.2.4, 1.3.4, 1.0.19
>Reporter: Tobias Bocanegra
>Assignee: Tobias Bocanegra
>Priority: Blocker
> Fix For: 1.3.9, 1.2.7, 1.0.22
>
> Attachments: OAK-3311-1.0.19.patch
>
>
> The iteration over all users in {{syncAllExternalUsers()}} aborts if there is 
> an uncaught NPE.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (OAK-3396) NPE during syncAllExternalUsers in LdapIdentityProvider.createUser

2015-10-02 Thread Tobias Bocanegra (JIRA) 

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

Tobias Bocanegra commented on OAK-3396:
---

fixed in 1.0: r1706476

> NPE during syncAllExternalUsers in LdapIdentityProvider.createUser
> --
>
> Key: OAK-3396
> URL: https://issues.apache.org/jira/browse/OAK-3396
> Project: Jackrabbit Oak
>  Issue Type: Bug
>  Components: auth-ldap
>Affects Versions: 1.0.18
>Reporter: Stefan Egli
>Assignee: Tobias Bocanegra
>Priority: Blocker
> Fix For: 1.3.8, 1.2.7, 1.0.22
>
> Attachments: OAK-3396.patch, OAK-3396.patch.v2
>
>
> When executing the JMX method syncAllExternalUsers the following NPE has been 
> encountered. This likely indicates that - for a particular user - there is no 
> attribute '{{uid}}':
> {code}
> java.lang.NullPointerException
> at 
> org.apache.jackrabbit.oak.security.authentication.ldap.impl.LdapIdentityProvider.createUser(LdapIdentityProvider.java:667)
> at 
> org.apache.jackrabbit.oak.security.authentication.ldap.impl.LdapIdentityProvider.access$000(LdapIdentityProvider.java:88)
> at 
> org.apache.jackrabbit.oak.security.authentication.ldap.impl.LdapIdentityProvider$1.getNext(LdapIdentityProvider.java:281)
> at 
> org.apache.jackrabbit.oak.security.authentication.ldap.impl.LdapIdentityProvider$1.getNext(LdapIdentityProvider.java:273)
> at 
> org.apache.jackrabbit.commons.iterator.AbstractLazyIterator.hasNext(AbstractLazyIterator.java:39)
> at 
> org.apache.jackrabbit.oak.spi.security.authentication.external.impl.jmx.SyncMBeanImpl$Delegatee.syncAllExternalUsers(SyncMBeanImpl.java:245)
> at 
> org.apache.jackrabbit.oak.spi.security.authentication.external.impl.jmx.SyncMBeanImpl.syncAllExternalUsers(SyncMBeanImpl.java:426)
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Resolved] (OAK-3396) NPE during syncAllExternalUsers in LdapIdentityProvider.createUser

2015-10-02 Thread Tobias Bocanegra (JIRA) 

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

Tobias Bocanegra resolved OAK-3396.
---
Resolution: Fixed

> NPE during syncAllExternalUsers in LdapIdentityProvider.createUser
> --
>
> Key: OAK-3396
> URL: https://issues.apache.org/jira/browse/OAK-3396
> Project: Jackrabbit Oak
>  Issue Type: Bug
>  Components: auth-ldap
>Affects Versions: 1.0.18
>Reporter: Stefan Egli
>Assignee: Tobias Bocanegra
>Priority: Blocker
> Fix For: 1.3.8, 1.2.7, 1.0.22
>
> Attachments: OAK-3396.patch, OAK-3396.patch.v2
>
>
> When executing the JMX method syncAllExternalUsers the following NPE has been 
> encountered. This likely indicates that - for a particular user - there is no 
> attribute '{{uid}}':
> {code}
> java.lang.NullPointerException
> at 
> org.apache.jackrabbit.oak.security.authentication.ldap.impl.LdapIdentityProvider.createUser(LdapIdentityProvider.java:667)
> at 
> org.apache.jackrabbit.oak.security.authentication.ldap.impl.LdapIdentityProvider.access$000(LdapIdentityProvider.java:88)
> at 
> org.apache.jackrabbit.oak.security.authentication.ldap.impl.LdapIdentityProvider$1.getNext(LdapIdentityProvider.java:281)
> at 
> org.apache.jackrabbit.oak.security.authentication.ldap.impl.LdapIdentityProvider$1.getNext(LdapIdentityProvider.java:273)
> at 
> org.apache.jackrabbit.commons.iterator.AbstractLazyIterator.hasNext(AbstractLazyIterator.java:39)
> at 
> org.apache.jackrabbit.oak.spi.security.authentication.external.impl.jmx.SyncMBeanImpl$Delegatee.syncAllExternalUsers(SyncMBeanImpl.java:245)
> at 
> org.apache.jackrabbit.oak.spi.security.authentication.external.impl.jmx.SyncMBeanImpl.syncAllExternalUsers(SyncMBeanImpl.java:426)
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (OAK-3311) Potential NPE in syncAllExternalUsers() aborts the process

2015-10-02 Thread Tobias Bocanegra (JIRA) 

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

Tobias Bocanegra commented on OAK-3311:
---

fixed in 1.0: r1706478

> Potential NPE in syncAllExternalUsers() aborts the process
> --
>
> Key: OAK-3311
> URL: https://issues.apache.org/jira/browse/OAK-3311
> Project: Jackrabbit Oak
>  Issue Type: Bug
>  Components: auth-external
>Affects Versions: 1.2.4, 1.3.4, 1.0.19
>Reporter: Tobias Bocanegra
>Assignee: Tobias Bocanegra
>Priority: Blocker
> Fix For: 1.3.9, 1.2.7, 1.0.22
>
> Attachments: OAK-3311-1.0.19.patch
>
>
> The iteration over all users in {{syncAllExternalUsers()}} aborts if there is 
> an uncaught NPE.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (OAK-3311) Potential NPE in syncAllExternalUsers() aborts the process

2015-10-02 Thread Tobias Bocanegra (JIRA) 

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

Tobias Bocanegra commented on OAK-3311:
---

fixed in 1.2: r1706465

> Potential NPE in syncAllExternalUsers() aborts the process
> --
>
> Key: OAK-3311
> URL: https://issues.apache.org/jira/browse/OAK-3311
> Project: Jackrabbit Oak
>  Issue Type: Bug
>  Components: auth-external
>Affects Versions: 1.2.4, 1.3.4, 1.0.19
>Reporter: Tobias Bocanegra
>Assignee: Tobias Bocanegra
>Priority: Blocker
> Fix For: 1.3.9, 1.2.7, 1.0.22
>
> Attachments: OAK-3311-1.0.19.patch
>
>
> The iteration over all users in {{syncAllExternalUsers()}} aborts if there is 
> an uncaught NPE.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (OAK-3396) NPE during syncAllExternalUsers in LdapIdentityProvider.createUser

2015-10-02 Thread Tobias Bocanegra (JIRA) 

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

Tobias Bocanegra commented on OAK-3396:
---

fixed in 1.2: r1706463

> NPE during syncAllExternalUsers in LdapIdentityProvider.createUser
> --
>
> Key: OAK-3396
> URL: https://issues.apache.org/jira/browse/OAK-3396
> Project: Jackrabbit Oak
>  Issue Type: Bug
>  Components: auth-ldap
>Affects Versions: 1.0.18
>Reporter: Stefan Egli
>Assignee: Tobias Bocanegra
>Priority: Blocker
> Fix For: 1.3.8, 1.2.7, 1.0.22
>
> Attachments: OAK-3396.patch, OAK-3396.patch.v2
>
>
> When executing the JMX method syncAllExternalUsers the following NPE has been 
> encountered. This likely indicates that - for a particular user - there is no 
> attribute '{{uid}}':
> {code}
> java.lang.NullPointerException
> at 
> org.apache.jackrabbit.oak.security.authentication.ldap.impl.LdapIdentityProvider.createUser(LdapIdentityProvider.java:667)
> at 
> org.apache.jackrabbit.oak.security.authentication.ldap.impl.LdapIdentityProvider.access$000(LdapIdentityProvider.java:88)
> at 
> org.apache.jackrabbit.oak.security.authentication.ldap.impl.LdapIdentityProvider$1.getNext(LdapIdentityProvider.java:281)
> at 
> org.apache.jackrabbit.oak.security.authentication.ldap.impl.LdapIdentityProvider$1.getNext(LdapIdentityProvider.java:273)
> at 
> org.apache.jackrabbit.commons.iterator.AbstractLazyIterator.hasNext(AbstractLazyIterator.java:39)
> at 
> org.apache.jackrabbit.oak.spi.security.authentication.external.impl.jmx.SyncMBeanImpl$Delegatee.syncAllExternalUsers(SyncMBeanImpl.java:245)
> at 
> org.apache.jackrabbit.oak.spi.security.authentication.external.impl.jmx.SyncMBeanImpl.syncAllExternalUsers(SyncMBeanImpl.java:426)
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)