date:20150914

[jira] [Commented] (OAK-3372) Collapsing external events in BackgroundObserver even before queue is full leads to JournalEntry not getting used

2015-09-14 Thread Vikas Saurabh (JIRA)


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

Vikas Saurabh commented on OAK-3372:


[~mduerig], my last comment, it seems, was mis-informed. I was assuming that 
other node store implementations also would have some sort of background read 
(similar to one in DocumentNodeStore) for events for changes in other cluster 
nodes. But, I couldn't quite follow Segment* implementation to figure out where 
do external events get pulled in. Can you give some pointers?

> Collapsing external events in BackgroundObserver even before queue is full 
> leads to JournalEntry not getting used
> -
>
> Key: OAK-3372
> URL: https://issues.apache.org/jira/browse/OAK-3372
> Project: Jackrabbit Oak
>  Issue Type: Improvement
>  Components: core
>Affects Versions: 1.3.5
>Reporter: Vikas Saurabh
>  Labels: resilience
>
> BackgroundObserver currently merges external events if the last one in queue 
> is also an external event. This leads to diff being done for a revision pair 
> which is different from the ones pushed actively into cache during backgroud 
> read (using JournalEntry) i.e. diff queries for {{diff("/a/b", rA, rC)}} 
> while background read had pushed results of {{diff("/a/b", rA, rB)}} and 
> {{diff("/a/b", rB, rC)}}.
> (cc [~mreutegg], [~egli], [~chetanm], [~mduerig])



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

[jira] [Resolved] (OAK-2986) RDB: switch to tomcat datasource implementation

2015-09-14 Thread Julian Reschke (JIRA)


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

Julian Reschke resolved OAK-2986.
-
Resolution: Fixed

Switched to tomcat datasource, made dependency test-scoped, instantiate vie 
reflection

> RDB: switch to tomcat datasource implementation 
> 
>
> Key: OAK-2986
> URL: https://issues.apache.org/jira/browse/OAK-2986
> Project: Jackrabbit Oak
>  Issue Type: Sub-task
>  Components: rdbmk
>Affects Versions: 1.2.4, 1.3.5, 1.0.19
>Reporter: Julian Reschke
>Assignee: Julian Reschke
>  Labels: resilience
> Fix For: 1.3.7, 1.2.6, 1.0.21
>
> Attachments: OAK-2986.diff, OAK-2986.diff
>
>
> See .
> In addition, this is the datasource used in Sling's datasource service, so 
> it's closer to what people will use in practice.



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

[jira] [Updated] (OAK-2986) RDB: switch to tomcat datasource implementation

2015-09-14 Thread Julian Reschke (JIRA)


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

Julian Reschke updated OAK-2986:

Fix Version/s: 1.0.21

> RDB: switch to tomcat datasource implementation 
> 
>
> Key: OAK-2986
> URL: https://issues.apache.org/jira/browse/OAK-2986
> Project: Jackrabbit Oak
>  Issue Type: Sub-task
>  Components: rdbmk
>Affects Versions: 1.2.4, 1.3.5, 1.0.19
>Reporter: Julian Reschke
>Assignee: Julian Reschke
>  Labels: resilience
> Fix For: 1.3.7, 1.2.6, 1.0.21
>
> Attachments: OAK-2986.diff, OAK-2986.diff
>
>
> See .
> In addition, this is the datasource used in Sling's datasource service, so 
> it's closer to what people will use in practice.



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

[jira] [Updated] (OAK-2986) RDB: switch to tomcat datasource implementation

2015-09-14 Thread Julian Reschke (JIRA)


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

Julian Reschke updated OAK-2986:

Fix Version/s: 1.2.6

> RDB: switch to tomcat datasource implementation 
> 
>
> Key: OAK-2986
> URL: https://issues.apache.org/jira/browse/OAK-2986
> Project: Jackrabbit Oak
>  Issue Type: Sub-task
>  Components: rdbmk
>Affects Versions: 1.2.4, 1.3.5, 1.0.19
>Reporter: Julian Reschke
>Assignee: Julian Reschke
>  Labels: resilience
> Fix For: 1.3.7, 1.2.6
>
> Attachments: OAK-2986.diff, OAK-2986.diff
>
>
> See .
> In addition, this is the datasource used in Sling's datasource service, so 
> it's closer to what people will use in practice.



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

[jira] [Created] (OAK-3404) Path to logical store mapping

2015-09-14 Thread Chetan Mehrotra (JIRA)

Chetan Mehrotra created OAK-3404:


 Summary: Path to logical store mapping
 Key: OAK-3404
 URL: https://issues.apache.org/jira/browse/OAK-3404
 Project: Jackrabbit Oak
  Issue Type: Technical task
  Components: core
Reporter: Chetan Mehrotra


Need to provide an API {{PathToStoreMapper}} which would be responsible for 
mapping a given path to logical store name 



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

[jira] [Created] (OAK-3403) Multiplexing store support in Property indexes

2015-09-14 Thread Chetan Mehrotra (JIRA)

Chetan Mehrotra created OAK-3403:


 Summary: Multiplexing store support in Property indexes
 Key: OAK-3403
 URL: https://issues.apache.org/jira/browse/OAK-3403
 Project: Jackrabbit Oak
  Issue Type: Technical task
  Components: query
Reporter: Chetan Mehrotra
Assignee: Chetan Mehrotra


In Oak one can define an index anywhere in the repository under a special node 
name {{oak:index}}. For e.g. if you want a property index for 
{{sling:resourceType}} at root level then you can create the index at 
/oak:index/resourceType and this index would store the index content at 
/oak:index/resourceType/:index.

# Writing - At time of commit the IndexEditor would need to decide where the 
indexed content for a given path should be stored. To start with it can make 
use of PathToStoreMapper to decide which node to use the indexed content. For 
e.g. for /libs the indexed content is stored under :index-pr and for /content 
:index-sr is used. This is simpler for PropertyIndex where IndexStoreStrategy 
can be passed the right node
# Reading - At time of reading the QueryIndex implementation would need to 
provide a union cursor which can perform lookup from all such store directories 
for a given index. 

*Open Items*
# Supporting unique indexes
# Introducing new oak:index - Node under oak:index node are special. Depending 
on parent path it might be possible that they would have to be created in both 
repositories. For e.g. /oak:index would have to be present in both PR and SR. 
While /content/foo/oak:index can live only in SR. 



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

[jira] [Assigned] (OAK-3402) Multiplexing DocumentStore support in Oak layer

2015-09-14 Thread Chetan Mehrotra (JIRA)


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

Chetan Mehrotra reassigned OAK-3402:


Assignee: Chetan Mehrotra

> Multiplexing DocumentStore support in Oak layer
> ---
>
> Key: OAK-3402
> URL: https://issues.apache.org/jira/browse/OAK-3402
> Project: Jackrabbit Oak
>  Issue Type: Story
>Reporter: Chetan Mehrotra
>Assignee: Chetan Mehrotra
>
> Supporting multiplexing repository would have impact on various places in Oak 
> design. There are various sub components in Oak which maintain there own 
> storage built on top of NodeStore. For e.g. indexes are stored within 
> NodeStore, permissions are also stored within NodeStore. Adding multiplexing 
> support would impact such stores in following ways
> The most basic application of multiplexing support is to support private and 
> shared storage. Under this an Oak application would have a private store and 
> a shared store. Content under certain paths would be stored under private 
> repo while all other content is stored under shared repo
> # *Writing* - Any content written via JCR API passes through some 
> {{CommitHooks}}. These hooks are responsible for updating the indexes, 
> permission store etc. Now if any path say /foo/bar gets modified the commits 
> hooks would need to determine under which path in NodeStore should the 
> derived data (index entries, permission etc) should be stored. For simple 
> case of private and shared store where we have 2 sets of paths private and 
> shared these hooks would need to be aware of that and use different path in 
> NodeStore to store the derived content. Key point to note here that any such 
> storage has to differentiate wether the path from which the content is being 
> derived is a private path or shared path
> # *Reading* - Reading requirement compliments the writing problem. While 
> performing any JCR operation Oak might need to invoke QueryIndex, 
> PermissionStore etc. These stores in turn would need to perform a read from 
> there storage area within NodeStore. For multiplexing support these 
> components would then need to be aware that there storage can exist in both 
> shared and private stores
> h4. Terms Used
> # _private repo_ (PR) - Set of paths which are considered private to the 
> application. Tentative example /lib,/apps
> # _shared repo_ (SR) - Set of paths which are considered shared and different 
> versions of the application can perform read and write operations on them. 
> Tentative example /content, /etc/workflow/instances
> # {{PathToStoreMapper}} - Responsible for mapping a path to store type. For 
> now it can just answer either PR or SR. But the concept can be generalized 
> Aim of this story is to prototype changes in Oak layer in a fork to asses the 
> impact on current implementation



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

[jira] [Created] (OAK-3402) Multiplexing DocumentStore support in Oak layer

2015-09-14 Thread Chetan Mehrotra (JIRA)

Chetan Mehrotra created OAK-3402:


 Summary: Multiplexing DocumentStore support in Oak layer
 Key: OAK-3402
 URL: https://issues.apache.org/jira/browse/OAK-3402
 Project: Jackrabbit Oak
  Issue Type: Story
Reporter: Chetan Mehrotra


Supporting multiplexing repository would have impact on various places in Oak 
design. There are various sub components in Oak which maintain there own 
storage built on top of NodeStore. For e.g. indexes are stored within 
NodeStore, permissions are also stored within NodeStore. Adding multiplexing 
support would impact such stores in following ways

The most basic application of multiplexing support is to support private and 
shared storage. Under this an Oak application would have a private store and a 
shared store. Content under certain paths would be stored under private repo 
while all other content is stored under shared repo

# *Writing* - Any content written via JCR API passes through some 
{{CommitHooks}}. These hooks are responsible for updating the indexes, 
permission store etc. Now if any path say /foo/bar gets modified the commits 
hooks would need to determine under which path in NodeStore should the derived 
data (index entries, permission etc) should be stored. For simple case of 
private and shared store where we have 2 sets of paths private and shared these 
hooks would need to be aware of that and use different path in NodeStore to 
store the derived content. Key point to note here that any such storage has to 
differentiate wether the path from which the content is being derived is a 
private path or shared path

# *Reading* - Reading requirement compliments the writing problem. While 
performing any JCR operation Oak might need to invoke QueryIndex, 
PermissionStore etc. These stores in turn would need to perform a read from 
there storage area within NodeStore. For multiplexing support these components 
would then need to be aware that there storage can exist in both shared and 
private stores

h4. Terms Used

# _private repo_ (PR) - Set of paths which are considered private to the 
application. Tentative example /lib,/apps
# _shared repo_ (SR) - Set of paths which are considered shared and different 
versions of the application can perform read and write operations on them. 
Tentative example /content, /etc/workflow/instances
# {{PathToStoreMapper}} - Responsible for mapping a path to store type. For now 
it can just answer either PR or SR. But the concept can be generalized 

Aim of this story is to prototype changes in Oak layer in a fork to asses the 
impact on current implementation



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

[jira] [Commented] (OAK-3398) make lease update more robust

2015-09-14 Thread Stefan Egli (JIRA)


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

Stefan Egli commented on OAK-3398:
--

second point done too:
* background lease update thread now has MAX_PRIORITY : 
http://svn.apache.org/r1702968

> make lease update more robust
> -
>
> Key: OAK-3398
> URL: https://issues.apache.org/jira/browse/OAK-3398
> Project: Jackrabbit Oak
>  Issue Type: Improvement
>  Components: core
>Affects Versions: 1.3.6
>Reporter: Stefan Egli
>Assignee: Stefan Egli
> Fix For: 1.3.7
>
>
> With the lease check introduced in OAK-2739 (and refined to do a oak-core 
> stop in OAK-3397) it becomes more critical that the lease is always properly 
> updated (to avoid an unnecessary oak-core stop). The following issues exist 
> atm:
> * currently the lease is valid 60sec by default, updated every 20sec, the 
> lease check fails with a margin of 20sec *before* it times out. this means if 
> the lease update thread is not operating for 20sec it will cause a stop. 
> that's quite a low figure probably
> ** the suggestion is to increase the lease timeout to 120sec from 60sec - 
> update it as soon as 10sec has been eaten off it, and leave the 20sec safety 
> margin at the end. This would result in 90sec 'idle equals faulty'
> * on a machine with heavy load it seems likely that the lease-update-thread 
> doesn't get scheduled timely enough - as it races for cpu against all the 
> other busy threads
> ** the suggestion is to increase the thread priority of the lease update 
> thread - so if the VM supports thread priorities, that would help reduce 
> lease failure 'just because the cpu is too busy'
> * the ClusterNodeInfo, when renewing the lease, doesn't check if the lease 
> has been marked as timed-out/recovering by another instance. it just 
> overwrites whatever is there. 
> ** It should, however, only update the lease when it has not yet been marked 
> as timed out.



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

[jira] [Created] (OAK-3401) Multiplexing DocumentStore support

2015-09-14 Thread Chetan Mehrotra (JIRA)

Chetan Mehrotra created OAK-3401:


 Summary: Multiplexing DocumentStore support
 Key: OAK-3401
 URL: https://issues.apache.org/jira/browse/OAK-3401
 Project: Jackrabbit Oak
  Issue Type: Epic
  Components: core, mongomk
Reporter: Chetan Mehrotra


The scenario for this multiplexing is the following:

* multiple Oak instances configured using a DocumentNodeStore
* all DocumentNodeStore instances connect to the same physical backend,
e.g. a mongod/mongos instance
* each Oak instance needs a private area that is not shared with the
other instances ( e.g. /tmp )

The concept is similar to Unix filesystem mounts managed in /etc/fstab. A 
'root' store manages the whole repository, while at certain points other 
sub-stores take over.

An example configuration can be:

{noformat}
/ <- root store
 /apps<- sub-store 1
 /libs<- sub-store 1
 /tmp <- sub-store 2
{noformat}

For more details refer to the thread by [~rombert] at [1]

Supporting this would require changes both in Document NodeStore layer and in 
Oak layer

[1] 
http://mail-archives.apache.org/mod_mbox/jackrabbit-oak-dev/201507.mbox/%3c1436362049.2080.31.ca...@apache.org%3E



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

[jira] [Resolved] (OAK-3400) ClusterNodeInfo should not be osgi-dependent (for lease check failure handling)

2015-09-14 Thread Stefan Egli (JIRA)


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

Stefan Egli resolved OAK-3400.
--
Resolution: Fixed

I still get some ITs failing - but I can't see any connection to 
clusterNodeInfo/lease-handling - thus closing this ticket

{code}
Running org.apache.jackrabbit.oak.jcr.tck.VersionIT
Tests run: 1416, Failures: 1, Errors: 2, Skipped: 0, Time elapsed: 220.493 sec 
<<< FAILURE!
testRestoreOrderJcr2_4(org.apache.jackrabbit.test.api.version.RestoreTest)  
Time elapsed: 1.528 sec  <<< FAILURE!
junit.framework.AssertionFailedError: Failed to create versionable test 
node.OakMerge0004: The node 3:/jcr:system/jcr:versionStorage/32 was already 
added in revision
r14fcc5e050f-0-1, before
r14fcc5ea10d-0-1
at junit.framework.Assert.fail(Assert.java:50)
at 
org.apache.jackrabbit.test.api.version.AbstractVersionTest.setUp(AbstractVersionTest.java:86)
at 
org.apache.jackrabbit.test.api.version.RestoreTest.setUp(RestoreTest.java:62)
at junit.framework.TestCase.runBare(TestCase.java:132)
at junit.framework.TestResult$1.protect(TestResult.java:110)
at junit.framework.TestResult.runProtected(TestResult.java:128)
at junit.framework.TestResult.run(TestResult.java:113)
at junit.framework.TestCase.run(TestCase.java:124)
at 
org.apache.jackrabbit.test.AbstractJCRTest.run(AbstractJCRTest.java:464)
at junit.framework.TestSuite.runTest(TestSuite.java:243)
at junit.framework.TestSuite.run(TestSuite.java:238)
at junit.framework.TestSuite.runTest(TestSuite.java:243)
at junit.framework.TestSuite.run(TestSuite.java:238)
at junit.framework.TestSuite.runTest(TestSuite.java:243)
at junit.framework.TestSuite.run(TestSuite.java:238)
at 
org.junit.internal.runners.JUnit38ClassRunner.run(JUnit38ClassRunner.java:83)
at 
org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:252)
at 
org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:141)
at 
org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:112)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at 
org.apache.maven.surefire.util.ReflectionUtils.invokeMethodWithArray(ReflectionUtils.java:189)
at 
org.apache.maven.surefire.booter.ProviderFactory$ProviderProxy.invoke(ProviderFactory.java:165)
at 
org.apache.maven.surefire.booter.ProviderFactory.invokeProvider(ProviderFactory.java:85)
at 
org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:115)
at 
org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:75)

testRestoreOrder2Jcr2_2(org.apache.jackrabbit.test.api.version.RestoreTest)  
Time elapsed: 5.172 sec  <<< ERROR!
javax.jcr.InvalidItemStateException: OakMerge0004: The node 
4:/jcr:system/jcr:versionStorage/5c/13 was already added in revision
r14fcc5fe22a-0-1, before
r14fcc5ff652-0-1
at 
org.apache.jackrabbit.oak.api.CommitFailedException.asRepositoryException(CommitFailedException.java:239)
at 
org.apache.jackrabbit.oak.api.CommitFailedException.asRepositoryException(CommitFailedException.java:212)
at 
org.apache.jackrabbit.oak.jcr.delegate.SessionDelegate.newRepositoryException(SessionDelegate.java:672)
at 
org.apache.jackrabbit.oak.jcr.delegate.SessionDelegate.save(SessionDelegate.java:497)
at 
org.apache.jackrabbit.oak.jcr.session.SessionImpl$8.performVoid(SessionImpl.java:425)
at 
org.apache.jackrabbit.oak.jcr.delegate.SessionDelegate.performVoid(SessionDelegate.java:275)
at 
org.apache.jackrabbit.oak.jcr.session.SessionImpl.save(SessionImpl.java:422)
at 
org.apache.jackrabbit.test.api.version.RestoreTest.setUp(RestoreTest.java:72)
at junit.framework.TestCase.runBare(TestCase.java:132)
at junit.framework.TestResult$1.protect(TestResult.java:110)
at junit.framework.TestResult.runProtected(TestResult.java:128)
at junit.framework.TestResult.run(TestResult.java:113)
at junit.framework.TestCase.run(TestCase.java:124)
at 
org.apache.jackrabbit.test.AbstractJCRTest.run(AbstractJCRTest.java:464)
at junit.framework.TestSuite.runTest(TestSuite.java:243)
at junit.framework.TestSuite.run(TestSuite.java:238)
at junit.framework.TestSuite.runTest(TestSuite.java:243)
at junit.framework.TestSuite.run(TestSuite.java:238)
at junit.framework.TestSuite.runTest(TestSuite.java:243)
at junit.framework.TestSuite.run(TestSuite.java:238)
at 
org.junit.internal.runners.JUni

[jira] [Commented] (OAK-3390) Avoid instanceof check in DocumentNodeStore

2015-09-14 Thread Julian Reschke (JIRA)


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

Julian Reschke commented on OAK-3390:
-

Hmmm.

1) This doesn't remove the "instanceof", it just moves it into a different 
class.

2) We still have the "instanceof" in LastRevRecoveryAgent.


> Avoid instanceof check in DocumentNodeStore
> ---
>
> Key: OAK-3390
> URL: https://issues.apache.org/jira/browse/OAK-3390
> Project: Jackrabbit Oak
>  Issue Type: Bug
>  Components: core, mongomk
>Affects Versions: 1.3.4
>Reporter: Marcel Reutegger
>Assignee: Marcel Reutegger
> Fix For: 1.3.7
>
>
> The instanceof MongoDocumentStore check does not work anymore when the store 
> is wrapped with e.g. the LeaseCheckDocumentStoreWrapper.



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

[jira] [Commented] (OAK-3400) ClusterNodeInfo should not be osgi-dependent (for lease check failure handling)

2015-09-14 Thread Stefan Egli (JIRA)


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

Stefan Egli commented on OAK-3400:
--

fixed in http://svn.apache.org/r1702963 - waiting for ITs to succeed before 
declaring victory

> ClusterNodeInfo should not be osgi-dependent (for lease check failure 
> handling)
> ---
>
> Key: OAK-3400
> URL: https://issues.apache.org/jira/browse/OAK-3400
> Project: Jackrabbit Oak
>  Issue Type: Bug
>  Components: core
> Environment: Affects revision 1.3.6+: 1702958
>Reporter: Stefan Egli
>Assignee: Stefan Egli
>Priority: Critical
> Fix For: 1.3.7
>
>
> Currently the ClusterNodeInfo wants an (osgi) ComponentContext so that it can 
> do a bundle-stop on lease failure.
> However, osgi-dependency we should only have in DocumentNodeStoreService - 
> and not in DocumentNodeStore/ClusterNodeInfo etc.
> So instead of passing a ComponentContext, let the builder have a 
> LeaseFailureHandler which will be passed to the ClusterNodeInfo.
> This blocks the IT tests - hence critical



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

[jira] [Resolved] (OAK-3390) Avoid instanceof check in DocumentNodeStore

2015-09-14 Thread Marcel Reutegger (JIRA)


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

Marcel Reutegger resolved OAK-3390.
---
Resolution: Fixed

Fixed in trunk: http://svn.apache.org/r1702959

> Avoid instanceof check in DocumentNodeStore
> ---
>
> Key: OAK-3390
> URL: https://issues.apache.org/jira/browse/OAK-3390
> Project: Jackrabbit Oak
>  Issue Type: Bug
>  Components: core, mongomk
>Affects Versions: 1.3.4
>Reporter: Marcel Reutegger
>Assignee: Marcel Reutegger
> Fix For: 1.3.7
>
>
> The instanceof MongoDocumentStore check does not work anymore when the store 
> is wrapped with e.g. the LeaseCheckDocumentStoreWrapper.



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

[jira] [Updated] (OAK-3400) ClusterNodeInfo should not be osgi-dependent (for lease check failure handling)

2015-09-14 Thread Stefan Egli (JIRA)


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

Stefan Egli updated OAK-3400:
-
Affects Version/s: (was: 1.3.6)
  Environment: Affects revision 1.3.6+: 1702958

> ClusterNodeInfo should not be osgi-dependent (for lease check failure 
> handling)
> ---
>
> Key: OAK-3400
> URL: https://issues.apache.org/jira/browse/OAK-3400
> Project: Jackrabbit Oak
>  Issue Type: Bug
>  Components: core
> Environment: Affects revision 1.3.6+: 1702958
>Reporter: Stefan Egli
>Assignee: Stefan Egli
>Priority: Critical
> Fix For: 1.3.7
>
>
> Currently the ClusterNodeInfo wants an (osgi) ComponentContext so that it can 
> do a bundle-stop on lease failure.
> However, osgi-dependency we should only have in DocumentNodeStoreService - 
> and not in DocumentNodeStore/ClusterNodeInfo etc.
> So instead of passing a ComponentContext, let the builder have a 
> LeaseFailureHandler which will be passed to the ClusterNodeInfo.
> This blocks the IT tests - hence critical



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

[jira] [Commented] (OAK-3400) ClusterNodeInfo should not be osgi-dependent (for lease check failure handling)

2015-09-14 Thread Marcel Reutegger (JIRA)


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

Marcel Reutegger commented on OAK-3400:
---

The failing test is in oak-remote:

{noformat}
Tests run: 240, Failures: 0, Errors: 80, Skipped: 0, Time elapsed: 22.381 sec 
<<< FAILURE! - in org.apache.jackrabbit.oak.remote.http.handler.RemoteServerIT
testReadLastRevisionTreeMultiStringProperty[0](org.apache.jackrabbit.oak.remote.http.handler.RemoteServerIT)
  Time elapsed: 0.007 sec  <<< ERROR!
java.lang.NoClassDefFoundError: org/osgi/framework/BundleException
at java.net.URLClassLoader$1.run(URLClassLoader.java:366)
at java.net.URLClassLoader$1.run(URLClassLoader.java:355)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.findClass(URLClassLoader.java:354)
at java.lang.ClassLoader.loadClass(ClassLoader.java:425)
at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:308)
at java.lang.ClassLoader.loadClass(ClassLoader.java:358)
at 
org.apache.jackrabbit.oak.plugins.document.DocumentNodeStore.(DocumentNodeStore.java:432)
at 
org.apache.jackrabbit.oak.plugins.document.DocumentMK$Builder.getNodeStore(DocumentMK.java:637)
at 
org.apache.jackrabbit.oak.NodeStoreFixture$2.createNodeStore(NodeStoreFixture.java:57)
at org.apache.jackrabbit.oak.OakBaseTest.(OakBaseTest.java:73)
at 
org.apache.jackrabbit.oak.remote.http.handler.RemoteServerIT.(RemoteServerIT.java:78)
{noformat}

> ClusterNodeInfo should not be osgi-dependent (for lease check failure 
> handling)
> ---
>
> Key: OAK-3400
> URL: https://issues.apache.org/jira/browse/OAK-3400
> Project: Jackrabbit Oak
>  Issue Type: Bug
>  Components: core
>Affects Versions: 1.3.6
>Reporter: Stefan Egli
>Assignee: Stefan Egli
>Priority: Critical
> Fix For: 1.3.7
>
>
> Currently the ClusterNodeInfo wants an (osgi) ComponentContext so that it can 
> do a bundle-stop on lease failure.
> However, osgi-dependency we should only have in DocumentNodeStoreService - 
> and not in DocumentNodeStore/ClusterNodeInfo etc.
> So instead of passing a ComponentContext, let the builder have a 
> LeaseFailureHandler which will be passed to the ClusterNodeInfo.
> This blocks the IT tests - hence critical



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

[jira] [Created] (OAK-3400) ClusterNodeInfo should not be osgi-dependent (for lease check failure handling)

2015-09-14 Thread Stefan Egli (JIRA)

Stefan Egli created OAK-3400:


 Summary: ClusterNodeInfo should not be osgi-dependent (for lease 
check failure handling)
 Key: OAK-3400
 URL: https://issues.apache.org/jira/browse/OAK-3400
 Project: Jackrabbit Oak
  Issue Type: Bug
  Components: core
Affects Versions: 1.3.6
Reporter: Stefan Egli
Assignee: Stefan Egli
Priority: Critical
 Fix For: 1.3.7


Currently the ClusterNodeInfo wants an (osgi) ComponentContext so that it can 
do a bundle-stop on lease failure.

However, osgi-dependency we should only have in DocumentNodeStoreService - and 
not in DocumentNodeStore/ClusterNodeInfo etc.

So instead of passing a ComponentContext, let the builder have a 
LeaseFailureHandler which will be passed to the ClusterNodeInfo.

This blocks the IT tests - hence critical



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

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

2015-09-14 Thread Manfred Baedke (JIRA)


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

Manfred Baedke commented on OAK-3396:
-

Hi [~egli],

The patch looks sensible, but note that LdapIdentityProvider has method pairs 
createUser()/createGroup() and listUsers()/listGroups() that have almost 
identical code. Since it's at least the second time I see only one of the 
methods patched, I think this should be refactored.

> 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
>Priority: Minor
> Fix For: 1.0.20
>
> Attachments: OAK-3396.patch
>
>
> 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-3398) make lease update more robust

2015-09-14 Thread Stefan Egli (JIRA)


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

Stefan Egli commented on OAK-3398:
--

first point done: 
* lease timeout set to 120sec now - updated every 10sec - failure margin is 
20sec before lease timeout: http://svn.apache.org/r1702953

> make lease update more robust
> -
>
> Key: OAK-3398
> URL: https://issues.apache.org/jira/browse/OAK-3398
> Project: Jackrabbit Oak
>  Issue Type: Improvement
>  Components: core
>Affects Versions: 1.3.6
>Reporter: Stefan Egli
>Assignee: Stefan Egli
> Fix For: 1.3.7
>
>
> With the lease check introduced in OAK-2739 (and refined to do a oak-core 
> stop in OAK-3397) it becomes more critical that the lease is always properly 
> updated (to avoid an unnecessary oak-core stop). The following issues exist 
> atm:
> * currently the lease is valid 60sec by default, updated every 20sec, the 
> lease check fails with a margin of 20sec *before* it times out. this means if 
> the lease update thread is not operating for 20sec it will cause a stop. 
> that's quite a low figure probably
> ** the suggestion is to increase the lease timeout to 120sec from 60sec - 
> update it as soon as 10sec has been eaten off it, and leave the 20sec safety 
> margin at the end. This would result in 90sec 'idle equals faulty'
> * on a machine with heavy load it seems likely that the lease-update-thread 
> doesn't get scheduled timely enough - as it races for cpu against all the 
> other busy threads
> ** the suggestion is to increase the thread priority of the lease update 
> thread - so if the VM supports thread priorities, that would help reduce 
> lease failure 'just because the cpu is too busy'
> * the ClusterNodeInfo, when renewing the lease, doesn't check if the lease 
> has been marked as timed-out/recovering by another instance. it just 
> overwrites whatever is there. 
> ** It should, however, only update the lease when it has not yet been marked 
> as timed out.



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

[jira] [Resolved] (OAK-3397) stop oak-core bundle on lease failure

2015-09-14 Thread Stefan Egli (JIRA)


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

Stefan Egli resolved OAK-3397.
--
Resolution: Fixed

done in http://svn.apache.org/r1702934

> stop oak-core bundle on lease failure
> -
>
> Key: OAK-3397
> URL: https://issues.apache.org/jira/browse/OAK-3397
> Project: Jackrabbit Oak
>  Issue Type: Improvement
>  Components: core
>Affects Versions: 1.3.4
>Reporter: Stefan Egli
>Assignee: Stefan Egli
> Fix For: 1.3.7
>
>
> As being discussed [on the 
> list|http://oak.markmail.org/thread/qja6ieqe5z27wolf] restarting 
> DocumentNodeStore (OAK-3250) as originally suggested seems not-so-trivial and 
> has further side-effects that would first have to be resolved. So in order to 
> still be able to get rid of the System.exit, the suggestion is to stop the 
> oak-core bundle instead.



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

[jira] [Updated] (OAK-3201) Use static references in SecurityProviderImpl for composite services

2015-09-14 Thread Francesco Mari (JIRA)


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

Francesco Mari updated OAK-3201:

Attachment: OAK-3201-06.patch

[^OAK-3201-06.patch] should be the final patch. Compared with the previous 
patch, I added tests in Oak PojoSR and fixed some minor issues that arose 
during testing. [~chetanm], feel free to review.

> Use static references in SecurityProviderImpl for composite services
> 
>
> Key: OAK-3201
> URL: https://issues.apache.org/jira/browse/OAK-3201
> Project: Jackrabbit Oak
>  Issue Type: Bug
>  Components: core
>Reporter: Francesco Mari
>Assignee: Francesco Mari
> Fix For: 1.3.7
>
> Attachments: OAK-3201-01.patch, OAK-3201-02.patch, OAK-3201-03.patch, 
> OAK-3201-04.patch, OAK-3201-05.patch, OAK-3201-06.patch, mbean-test.log
>
>
> {{SecurityProviderImpl}} has dynamic references to many other services, like 
> {{RestrictionProvider}}, that represent the configuration of this component.
> Being these services dynamic, the OSGi runtime has no clear dependency 
> relationship between the {{SecurityProviderImpl}} and the required services. 
> Thus, it may happen that an instance of {{SecurityProviderImpl}} is published 
> before the services it requires are started, creating a window where the 
> {{SecurityProviderimpl}} is operating differently from the way it's 
> configured.
> I suggest to turn the dynamic references in {{SecurityProviderImpl}} to 
> static ones to improve the consistency of the implementation.



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

[jira] [Assigned] (OAK-3399) 5sec retry loop before declaring lease failure (was: as a last resort try to update it there)

2015-09-14 Thread Stefan Egli (JIRA)


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

Stefan Egli reassigned OAK-3399:


Assignee: Stefan Egli

> 5sec retry loop before declaring lease failure (was: as a last resort try to 
> update it there)
> -
>
> Key: OAK-3399
> URL: https://issues.apache.org/jira/browse/OAK-3399
> Project: Jackrabbit Oak
>  Issue Type: Improvement
>  Components: core
>Affects Versions: 1.3.6
>Reporter: Stefan Egli
>Assignee: Stefan Egli
> Fix For: 1.3.7
>
>
> Not sure if this is a good idea - but when the lease check finds out that the 
> lease is valid for less than the margin (which is 20sec by default), it could 
> then try to update the lease directly. The 'ugly' part of this is that 
> normally this job is done by a dedicated background 'lease update' thread - 
> and now it would be done in the context of a user-thread 'very much under the 
> hood'. but the advantage would be that it would eg catch the 'laptop-sleep' 
> situation when running a single vm ..



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

[jira] [Updated] (OAK-3399) 5sec retry loop before declaring lease failure (was: as a last resort try to update it there)

2015-09-14 Thread Stefan Egli (JIRA)


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

Stefan Egli updated OAK-3399:
-
Fix Version/s: 1.3.7

> 5sec retry loop before declaring lease failure (was: as a last resort try to 
> update it there)
> -
>
> Key: OAK-3399
> URL: https://issues.apache.org/jira/browse/OAK-3399
> Project: Jackrabbit Oak
>  Issue Type: Improvement
>  Components: core
>Affects Versions: 1.3.6
>Reporter: Stefan Egli
> Fix For: 1.3.7
>
>
> Not sure if this is a good idea - but when the lease check finds out that the 
> lease is valid for less than the margin (which is 20sec by default), it could 
> then try to update the lease directly. The 'ugly' part of this is that 
> normally this job is done by a dedicated background 'lease update' thread - 
> and now it would be done in the context of a user-thread 'very much under the 
> hood'. but the advantage would be that it would eg catch the 'laptop-sleep' 
> situation when running a single vm ..



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

[jira] [Commented] (OAK-3399) 5sec retry loop before declaring lease failure (was: as a last resort try to update it there)

2015-09-14 Thread Stefan Egli (JIRA)


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

Stefan Egli commented on OAK-3399:
--

alternatively - as a less intrusive solution: do a 5 x 1sec retry loop when 
detecting a lease failure before actually declaring it. That would delay the 
failure-action by 5sec (which I see as non-problematic - it would anyway have 
been done), but in the best case the lease-update-thread just had a hickup and 
it was lucky enough to update it again - in which case we don't have to stop. 
This would probably help in development as it supports the 
laptop-wake-from-sleep case..

> 5sec retry loop before declaring lease failure (was: as a last resort try to 
> update it there)
> -
>
> Key: OAK-3399
> URL: https://issues.apache.org/jira/browse/OAK-3399
> Project: Jackrabbit Oak
>  Issue Type: Improvement
>  Components: core
>Affects Versions: 1.3.6
>Reporter: Stefan Egli
>
> Not sure if this is a good idea - but when the lease check finds out that the 
> lease is valid for less than the margin (which is 20sec by default), it could 
> then try to update the lease directly. The 'ugly' part of this is that 
> normally this job is done by a dedicated background 'lease update' thread - 
> and now it would be done in the context of a user-thread 'very much under the 
> hood'. but the advantage would be that it would eg catch the 'laptop-sleep' 
> situation when running a single vm ..



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

[jira] [Updated] (OAK-3399) 5sec retry loop before declaring lease failure (was: as a last resort try to update it there)

2015-09-14 Thread Stefan Egli (JIRA)


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

Stefan Egli updated OAK-3399:
-
Summary: 5sec retry loop before declaring lease failure (was: as a last 
resort try to update it there)  (was: before declaring lease failure, as a last 
resort try to update it there)

> 5sec retry loop before declaring lease failure (was: as a last resort try to 
> update it there)
> -
>
> Key: OAK-3399
> URL: https://issues.apache.org/jira/browse/OAK-3399
> Project: Jackrabbit Oak
>  Issue Type: Improvement
>  Components: core
>Affects Versions: 1.3.6
>Reporter: Stefan Egli
>
> Not sure if this is a good idea - but when the lease check finds out that the 
> lease is valid for less than the margin (which is 20sec by default), it could 
> then try to update the lease directly. The 'ugly' part of this is that 
> normally this job is done by a dedicated background 'lease update' thread - 
> and now it would be done in the context of a user-thread 'very much under the 
> hood'. but the advantage would be that it would eg catch the 'laptop-sleep' 
> situation when running a single vm ..



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

[jira] [Commented] (OAK-3395) RevisionGC fails for JCR paths having line feed characters

2015-09-14 Thread Chetan Mehrotra (JIRA)


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

Chetan Mehrotra commented on OAK-3395:
--

Lets followup on thread on DL. Looking at change done for above comment the 
logic is now in Namespace#isValidLocalName. Problem is that new logic uses 
Character#isSpaceChar instead of Character#isWhitespace used earlier and due to 
this now names with line feed etc are getting allowed for creation

> RevisionGC fails for JCR paths having line feed characters
> --
>
> Key: OAK-3395
> URL: https://issues.apache.org/jira/browse/OAK-3395
> Project: Jackrabbit Oak
>  Issue Type: Bug
>  Components: mongomk, rdbmk
>Reporter: Chetan Mehrotra
>Assignee: Chetan Mehrotra
>Priority: Minor
> Fix For: 1.3.7, 1.2.6, 1.0.21
>
>
> RevisionGC fails with error while processing any id (derived from JCR path) 
> having line feed or carriage return char
> This happens because it relies on Oak Commons StringSort and ExternalSort 
> which works with line delimited string and having an id with line break would 
> break this sorting logic. Error reported is like
> {noformat}
> java.lang.AssertionError: Invalid id /1442211320
>   at 
> org.apache.jackrabbit.oak.plugins.document.util.Utils.getDepthFromId(Utils.java:337)
>   at 
> org.apache.jackrabbit.oak.plugins.document.NodeDocumentIdComparator.compare(NodeDocumentIdComparator.java:38)
>   at 
> org.apache.jackrabbit.oak.plugins.document.NodeDocumentIdComparator.compare(NodeDocumentIdComparator.java:30)
>   at java.util.TimSort.countRunAndMakeAscending(TimSort.java:324)
>   at java.util.TimSort.sort(TimSort.java:203)
>   at java.util.TimSort.sort(TimSort.java:173)
>   at java.util.Arrays.sort(Arrays.java:659)
>   at java.util.Collections.sort(Collections.java:217)
>   at 
> org.apache.jackrabbit.oak.commons.sort.ExternalSort.sortAndSave(ExternalSort.java:279)
>   at 
> org.apache.jackrabbit.oak.commons.sort.ExternalSort.sortInBatch(ExternalSort.java:218)
>   at 
> org.apache.jackrabbit.oak.commons.sort.ExternalSort.sortInBatch(ExternalSort.java:257)
>   at 
> org.apache.jackrabbit.oak.commons.sort.StringSort$PersistentState.sort(StringSort.java:191)
>   at 
> org.apache.jackrabbit.oak.commons.sort.StringSort.sort(StringSort.java:88)
>   at 
> org.apache.jackrabbit.oak.plugins.document.VersionGarbageCollector$DeletedDocsGC.ensureSorted(VersionGarbageCollector.java:383)
>   at 
> org.apache.jackrabbit.oak.plugins.document.VersionGarbageCollector$DeletedDocsGC.getDocIdsToDelete(VersionGarbageCollector.java:274)
>   at 
> org.apache.jackrabbit.oak.plugins.document.VersionGarbageCollector$DeletedDocsGC.removeDeletedDocuments(VersionGarbageCollector.java:296)
>   at 
> org.apache.jackrabbit.oak.plugins.document.VersionGarbageCollector$DeletedDocsGC.removeDocuments(VersionGarbageCollector.java:241)
>   at 
> org.apache.jackrabbit.oak.plugins.document.VersionGarbageCollector.collectDeletedDocuments(VersionGarbageCollector.java:154)
>   at 
> org.apache.jackrabbit.oak.plugins.document.VersionGarbageCollector.gc(VersionGarbageCollector.java:105)
>   at 
> org.apache.jackrabbit.oak.plugins.document.VersionGCDeletionTest.gcWithPathsHavingNewLine(VersionGCDeletionTest.java:203)
> {noformat}



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

[jira] [Commented] (OAK-3395) RevisionGC fails for JCR paths having line feed characters

2015-09-14 Thread Julian Reschke (JIRA)


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

Julian Reschke commented on OAK-3395:
-

We used to do this in Oak as well.

It seems that the changes made for OAK-1174 broke that.

Citing 
https://issues.apache.org/jira/browse/OAK-1174?focusedCommentId=13950984&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13950984:

"Fixed in revision 1582804 by moving the whitespace checks from the name/path 
parser classes to NameValidator."

...but I don't see the promised change in NameValidator.

> RevisionGC fails for JCR paths having line feed characters
> --
>
> Key: OAK-3395
> URL: https://issues.apache.org/jira/browse/OAK-3395
> Project: Jackrabbit Oak
>  Issue Type: Bug
>  Components: mongomk, rdbmk
>Reporter: Chetan Mehrotra
>Assignee: Chetan Mehrotra
>Priority: Minor
> Fix For: 1.3.7, 1.2.6, 1.0.21
>
>
> RevisionGC fails with error while processing any id (derived from JCR path) 
> having line feed or carriage return char
> This happens because it relies on Oak Commons StringSort and ExternalSort 
> which works with line delimited string and having an id with line break would 
> break this sorting logic. Error reported is like
> {noformat}
> java.lang.AssertionError: Invalid id /1442211320
>   at 
> org.apache.jackrabbit.oak.plugins.document.util.Utils.getDepthFromId(Utils.java:337)
>   at 
> org.apache.jackrabbit.oak.plugins.document.NodeDocumentIdComparator.compare(NodeDocumentIdComparator.java:38)
>   at 
> org.apache.jackrabbit.oak.plugins.document.NodeDocumentIdComparator.compare(NodeDocumentIdComparator.java:30)
>   at java.util.TimSort.countRunAndMakeAscending(TimSort.java:324)
>   at java.util.TimSort.sort(TimSort.java:203)
>   at java.util.TimSort.sort(TimSort.java:173)
>   at java.util.Arrays.sort(Arrays.java:659)
>   at java.util.Collections.sort(Collections.java:217)
>   at 
> org.apache.jackrabbit.oak.commons.sort.ExternalSort.sortAndSave(ExternalSort.java:279)
>   at 
> org.apache.jackrabbit.oak.commons.sort.ExternalSort.sortInBatch(ExternalSort.java:218)
>   at 
> org.apache.jackrabbit.oak.commons.sort.ExternalSort.sortInBatch(ExternalSort.java:257)
>   at 
> org.apache.jackrabbit.oak.commons.sort.StringSort$PersistentState.sort(StringSort.java:191)
>   at 
> org.apache.jackrabbit.oak.commons.sort.StringSort.sort(StringSort.java:88)
>   at 
> org.apache.jackrabbit.oak.plugins.document.VersionGarbageCollector$DeletedDocsGC.ensureSorted(VersionGarbageCollector.java:383)
>   at 
> org.apache.jackrabbit.oak.plugins.document.VersionGarbageCollector$DeletedDocsGC.getDocIdsToDelete(VersionGarbageCollector.java:274)
>   at 
> org.apache.jackrabbit.oak.plugins.document.VersionGarbageCollector$DeletedDocsGC.removeDeletedDocuments(VersionGarbageCollector.java:296)
>   at 
> org.apache.jackrabbit.oak.plugins.document.VersionGarbageCollector$DeletedDocsGC.removeDocuments(VersionGarbageCollector.java:241)
>   at 
> org.apache.jackrabbit.oak.plugins.document.VersionGarbageCollector.collectDeletedDocuments(VersionGarbageCollector.java:154)
>   at 
> org.apache.jackrabbit.oak.plugins.document.VersionGarbageCollector.gc(VersionGarbageCollector.java:105)
>   at 
> org.apache.jackrabbit.oak.plugins.document.VersionGCDeletionTest.gcWithPathsHavingNewLine(VersionGCDeletionTest.java:203)
> {noformat}



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

[jira] [Commented] (OAK-1891) Regression: non-space whitespace not allowed in item names

2015-09-14 Thread Julian Reschke (JIRA)


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

Julian Reschke commented on OAK-1891:
-

I believe this should be closed as "works as designed".

> Regression: non-space whitespace not allowed in item names
> --
>
> Key: OAK-1891
> URL: https://issues.apache.org/jira/browse/OAK-1891
> Project: Jackrabbit Oak
>  Issue Type: Bug
>  Components: core
>Affects Versions: 1.0
>Reporter: Tobias Bocanegra
>
> item names with a non-space whitespace are not allowed anymore in oak.
> https://github.com/apache/jackrabbit-oak/blob/1.0/oak-core/src/main/java/org/apache/jackrabbit/oak/plugins/name/Namespaces.java#L252
> this used to work in jackrabbit and can be a problem for customers trying to 
> migrate old content. also upgrading existing content might result in 
> unexpected results.



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

[jira] [Commented] (OAK-3398) make lease update more robust

2015-09-14 Thread Stefan Egli (JIRA)


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

Stefan Egli commented on OAK-3398:
--

there's also OAK-3399 which is about an idea to try updating the lease right 
before we'd otherwise declare it failed. it's kind of a hack though, so I'm not 
sure..

> make lease update more robust
> -
>
> Key: OAK-3398
> URL: https://issues.apache.org/jira/browse/OAK-3398
> Project: Jackrabbit Oak
>  Issue Type: Improvement
>  Components: core
>Affects Versions: 1.3.6
>Reporter: Stefan Egli
>Assignee: Stefan Egli
> Fix For: 1.3.7
>
>
> With the lease check introduced in OAK-2739 (and refined to do a oak-core 
> stop in OAK-3397) it becomes more critical that the lease is always properly 
> updated (to avoid an unnecessary oak-core stop). The following issues exist 
> atm:
> * currently the lease is valid 60sec by default, updated every 20sec, the 
> lease check fails with a margin of 20sec *before* it times out. this means if 
> the lease update thread is not operating for 20sec it will cause a stop. 
> that's quite a low figure probably
> ** the suggestion is to increase the lease timeout to 120sec from 60sec - 
> update it as soon as 10sec has been eaten off it, and leave the 20sec safety 
> margin at the end. This would result in 90sec 'idle equals faulty'
> * on a machine with heavy load it seems likely that the lease-update-thread 
> doesn't get scheduled timely enough - as it races for cpu against all the 
> other busy threads
> ** the suggestion is to increase the thread priority of the lease update 
> thread - so if the VM supports thread priorities, that would help reduce 
> lease failure 'just because the cpu is too busy'
> * the ClusterNodeInfo, when renewing the lease, doesn't check if the lease 
> has been marked as timed-out/recovering by another instance. it just 
> overwrites whatever is there. 
> ** It should, however, only update the lease when it has not yet been marked 
> as timed out.



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

[jira] [Created] (OAK-3399) before declaring lease failure, as a last resort try to update it there

2015-09-14 Thread Stefan Egli (JIRA)

Stefan Egli created OAK-3399:


 Summary: before declaring lease failure, as a last resort try to 
update it there
 Key: OAK-3399
 URL: https://issues.apache.org/jira/browse/OAK-3399
 Project: Jackrabbit Oak
  Issue Type: Improvement
  Components: core
Affects Versions: 1.3.6
Reporter: Stefan Egli


Not sure if this is a good idea - but when the lease check finds out that the 
lease is valid for less than the margin (which is 20sec by default), it could 
then try to update the lease directly. The 'ugly' part of this is that normally 
this job is done by a dedicated background 'lease update' thread - and now it 
would be done in the context of a user-thread 'very much under the hood'. but 
the advantage would be that it would eg catch the 'laptop-sleep' situation when 
running a single vm ..



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

[jira] [Created] (OAK-3398) make lease update more robust

2015-09-14 Thread Stefan Egli (JIRA)

Stefan Egli created OAK-3398:


 Summary: make lease update more robust
 Key: OAK-3398
 URL: https://issues.apache.org/jira/browse/OAK-3398
 Project: Jackrabbit Oak
  Issue Type: Improvement
  Components: core
Affects Versions: 1.3.6
Reporter: Stefan Egli
Assignee: Stefan Egli
 Fix For: 1.3.7


With the lease check introduced in OAK-2739 (and refined to do a oak-core stop 
in OAK-3397) it becomes more critical that the lease is always properly updated 
(to avoid an unnecessary oak-core stop). The following issues exist atm:
* currently the lease is valid 60sec by default, updated every 20sec, the lease 
check fails with a margin of 20sec *before* it times out. this means if the 
lease update thread is not operating for 20sec it will cause a stop. that's 
quite a low figure probably
** the suggestion is to increase the lease timeout to 120sec from 60sec - 
update it as soon as 10sec has been eaten off it, and leave the 20sec safety 
margin at the end. This would result in 90sec 'idle equals faulty'
* on a machine with heavy load it seems likely that the lease-update-thread 
doesn't get scheduled timely enough - as it races for cpu against all the other 
busy threads
** the suggestion is to increase the thread priority of the lease update thread 
- so if the VM supports thread priorities, that would help reduce lease failure 
'just because the cpu is too busy'
* the ClusterNodeInfo, when renewing the lease, doesn't check if the lease has 
been marked as timed-out/recovering by another instance. it just overwrites 
whatever is there. 
** It should, however, only update the lease when it has not yet been marked as 
timed out.



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

[jira] [Comment Edited] (OAK-3395) RevisionGC fails for JCR paths having line feed characters

2015-09-14 Thread Chetan Mehrotra (JIRA)


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

Chetan Mehrotra edited comment on OAK-3395 at 9/14/15 9:44 AM:
---

Okie. So looks like JR2 did not allowed that 
[PathParser|https://github.com/apache/jackrabbit/blob/trunk/jackrabbit-spi-commons/src/main/java/org/apache/jackrabbit/spi/commons/conversion/PathParser.java#L257]
 would throw exception for all non space whitespaces!

{code}
public void testPathWithLineBreak() throws Exception{
String relPath = "a\rb";
Node n = testRootNode.addNode(relPath, "nt:folder");
superuser.save();
}
{code}

Fails with

{noformat}
Caused by: org.apache.jackrabbit.spi.commons.conversion.MalformedPathException: 
'a
b' is not a valid path. Whitespace other than SP (U+0020) not a allowed in a 
name, but U+000d was found at position 1.
at 
org.apache.jackrabbit.spi.commons.conversion.PathParser.parse(PathParser.java:400)
at 
org.apache.jackrabbit.spi.commons.conversion.PathParser.parse(PathParser.java:122)
at org.apac
{noformat}

So should we do the same in Oak also? Would discuss this on DL


was (Author: chetanm):
Okie. So looks like JR2 did not allowed that 
[PathParser|https://github.com/apache/jackrabbit/blob/trunk/jackrabbit-spi-commons/src/main/java/org/apache/jackrabbit/spi/commons/conversion/PathParser.java#L257]
 would throw exception for all non space whitespaces!

{code}
public void testPathWithLineBreak() throws Exception{
String relPath = "a\rb";
Node n = testRootNode.addNode(relPath, "nt:folder");
superuser.save();
}
{code}

Fails with

{noformat}
Caused by: org.apache.jackrabbit.spi.commons.conversion.MalformedPathException: 
'a
b' is not a valid path. Whitespace other than SP (U+0020) not a allowed in a 
name, but U+000d was found at position 1.
at 
org.apache.jackrabbit.spi.commons.conversion.PathParser.parse(PathParser.java:400)
at 
org.apache.jackrabbit.spi.commons.conversion.PathParser.parse(PathParser.java:122)
at org.apac
{noformat}

So should we do the same in Oak also?

> RevisionGC fails for JCR paths having line feed characters
> --
>
> Key: OAK-3395
> URL: https://issues.apache.org/jira/browse/OAK-3395
> Project: Jackrabbit Oak
>  Issue Type: Bug
>  Components: mongomk, rdbmk
>Reporter: Chetan Mehrotra
>Assignee: Chetan Mehrotra
>Priority: Minor
> Fix For: 1.3.7, 1.2.6, 1.0.21
>
>
> RevisionGC fails with error while processing any id (derived from JCR path) 
> having line feed or carriage return char
> This happens because it relies on Oak Commons StringSort and ExternalSort 
> which works with line delimited string and having an id with line break would 
> break this sorting logic. Error reported is like
> {noformat}
> java.lang.AssertionError: Invalid id /1442211320
>   at 
> org.apache.jackrabbit.oak.plugins.document.util.Utils.getDepthFromId(Utils.java:337)
>   at 
> org.apache.jackrabbit.oak.plugins.document.NodeDocumentIdComparator.compare(NodeDocumentIdComparator.java:38)
>   at 
> org.apache.jackrabbit.oak.plugins.document.NodeDocumentIdComparator.compare(NodeDocumentIdComparator.java:30)
>   at java.util.TimSort.countRunAndMakeAscending(TimSort.java:324)
>   at java.util.TimSort.sort(TimSort.java:203)
>   at java.util.TimSort.sort(TimSort.java:173)
>   at java.util.Arrays.sort(Arrays.java:659)
>   at java.util.Collections.sort(Collections.java:217)
>   at 
> org.apache.jackrabbit.oak.commons.sort.ExternalSort.sortAndSave(ExternalSort.java:279)
>   at 
> org.apache.jackrabbit.oak.commons.sort.ExternalSort.sortInBatch(ExternalSort.java:218)
>   at 
> org.apache.jackrabbit.oak.commons.sort.ExternalSort.sortInBatch(ExternalSort.java:257)
>   at 
> org.apache.jackrabbit.oak.commons.sort.StringSort$PersistentState.sort(StringSort.java:191)
>   at 
> org.apache.jackrabbit.oak.commons.sort.StringSort.sort(StringSort.java:88)
>   at 
> org.apache.jackrabbit.oak.plugins.document.VersionGarbageCollector$DeletedDocsGC.ensureSorted(VersionGarbageCollector.java:383)
>   at 
> org.apache.jackrabbit.oak.plugins.document.VersionGarbageCollector$DeletedDocsGC.getDocIdsToDelete(VersionGarbageCollector.java:274)
>   at 
> org.apache.jackrabbit.oak.plugins.document.VersionGarbageCollector$DeletedDocsGC.removeDeletedDocuments(VersionGarbageCollector.java:296)
>   at 
> org.apache.jackrabbit.oak.plugins.document.VersionGarbageCollector$DeletedDocsGC.removeDocuments(VersionGarbageCollector.java:241)
>   at 
> org.apache.jackrabbit.oak.plugins.document.VersionGarbageCollector.collectDeletedDocuments(VersionGarbageCollector.java:154)
>   at

[jira] [Commented] (OAK-3395) RevisionGC fails for JCR paths having line feed characters

2015-09-14 Thread Chetan Mehrotra (JIRA)


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

Chetan Mehrotra commented on OAK-3395:
--

Okie. So looks like JR2 did not allowed that 
[PathParser|https://github.com/apache/jackrabbit/blob/trunk/jackrabbit-spi-commons/src/main/java/org/apache/jackrabbit/spi/commons/conversion/PathParser.java#L257]
 would throw exception for all non space whitespaces!

{code}
public void testPathWithLineBreak() throws Exception{
String relPath = "a\rb";
Node n = testRootNode.addNode(relPath, "nt:folder");
superuser.save();
}
{code}

Fails with

{noformat}
Caused by: org.apache.jackrabbit.spi.commons.conversion.MalformedPathException: 
'a
b' is not a valid path. Whitespace other than SP (U+0020) not a allowed in a 
name, but U+000d was found at position 1.
at 
org.apache.jackrabbit.spi.commons.conversion.PathParser.parse(PathParser.java:400)
at 
org.apache.jackrabbit.spi.commons.conversion.PathParser.parse(PathParser.java:122)
at org.apac
{noformat}

So should we do the same in Oak also?

> RevisionGC fails for JCR paths having line feed characters
> --
>
> Key: OAK-3395
> URL: https://issues.apache.org/jira/browse/OAK-3395
> Project: Jackrabbit Oak
>  Issue Type: Bug
>  Components: mongomk, rdbmk
>Reporter: Chetan Mehrotra
>Assignee: Chetan Mehrotra
>Priority: Minor
> Fix For: 1.3.7, 1.2.6, 1.0.21
>
>
> RevisionGC fails with error while processing any id (derived from JCR path) 
> having line feed or carriage return char
> This happens because it relies on Oak Commons StringSort and ExternalSort 
> which works with line delimited string and having an id with line break would 
> break this sorting logic. Error reported is like
> {noformat}
> java.lang.AssertionError: Invalid id /1442211320
>   at 
> org.apache.jackrabbit.oak.plugins.document.util.Utils.getDepthFromId(Utils.java:337)
>   at 
> org.apache.jackrabbit.oak.plugins.document.NodeDocumentIdComparator.compare(NodeDocumentIdComparator.java:38)
>   at 
> org.apache.jackrabbit.oak.plugins.document.NodeDocumentIdComparator.compare(NodeDocumentIdComparator.java:30)
>   at java.util.TimSort.countRunAndMakeAscending(TimSort.java:324)
>   at java.util.TimSort.sort(TimSort.java:203)
>   at java.util.TimSort.sort(TimSort.java:173)
>   at java.util.Arrays.sort(Arrays.java:659)
>   at java.util.Collections.sort(Collections.java:217)
>   at 
> org.apache.jackrabbit.oak.commons.sort.ExternalSort.sortAndSave(ExternalSort.java:279)
>   at 
> org.apache.jackrabbit.oak.commons.sort.ExternalSort.sortInBatch(ExternalSort.java:218)
>   at 
> org.apache.jackrabbit.oak.commons.sort.ExternalSort.sortInBatch(ExternalSort.java:257)
>   at 
> org.apache.jackrabbit.oak.commons.sort.StringSort$PersistentState.sort(StringSort.java:191)
>   at 
> org.apache.jackrabbit.oak.commons.sort.StringSort.sort(StringSort.java:88)
>   at 
> org.apache.jackrabbit.oak.plugins.document.VersionGarbageCollector$DeletedDocsGC.ensureSorted(VersionGarbageCollector.java:383)
>   at 
> org.apache.jackrabbit.oak.plugins.document.VersionGarbageCollector$DeletedDocsGC.getDocIdsToDelete(VersionGarbageCollector.java:274)
>   at 
> org.apache.jackrabbit.oak.plugins.document.VersionGarbageCollector$DeletedDocsGC.removeDeletedDocuments(VersionGarbageCollector.java:296)
>   at 
> org.apache.jackrabbit.oak.plugins.document.VersionGarbageCollector$DeletedDocsGC.removeDocuments(VersionGarbageCollector.java:241)
>   at 
> org.apache.jackrabbit.oak.plugins.document.VersionGarbageCollector.collectDeletedDocuments(VersionGarbageCollector.java:154)
>   at 
> org.apache.jackrabbit.oak.plugins.document.VersionGarbageCollector.gc(VersionGarbageCollector.java:105)
>   at 
> org.apache.jackrabbit.oak.plugins.document.VersionGCDeletionTest.gcWithPathsHavingNewLine(VersionGCDeletionTest.java:203)
> {noformat}



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

[jira] [Updated] (OAK-3395) RevisionGC fails for JCR paths having line feed characters

2015-09-14 Thread Amit Jain (JIRA)


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

Amit Jain updated OAK-3395:
---
Fix Version/s: (was: 1.2.5)
   1.2.6

> RevisionGC fails for JCR paths having line feed characters
> --
>
> Key: OAK-3395
> URL: https://issues.apache.org/jira/browse/OAK-3395
> Project: Jackrabbit Oak
>  Issue Type: Bug
>  Components: mongomk, rdbmk
>Reporter: Chetan Mehrotra
>Assignee: Chetan Mehrotra
>Priority: Minor
> Fix For: 1.3.7, 1.2.6, 1.0.21
>
>
> RevisionGC fails with error while processing any id (derived from JCR path) 
> having line feed or carriage return char
> This happens because it relies on Oak Commons StringSort and ExternalSort 
> which works with line delimited string and having an id with line break would 
> break this sorting logic. Error reported is like
> {noformat}
> java.lang.AssertionError: Invalid id /1442211320
>   at 
> org.apache.jackrabbit.oak.plugins.document.util.Utils.getDepthFromId(Utils.java:337)
>   at 
> org.apache.jackrabbit.oak.plugins.document.NodeDocumentIdComparator.compare(NodeDocumentIdComparator.java:38)
>   at 
> org.apache.jackrabbit.oak.plugins.document.NodeDocumentIdComparator.compare(NodeDocumentIdComparator.java:30)
>   at java.util.TimSort.countRunAndMakeAscending(TimSort.java:324)
>   at java.util.TimSort.sort(TimSort.java:203)
>   at java.util.TimSort.sort(TimSort.java:173)
>   at java.util.Arrays.sort(Arrays.java:659)
>   at java.util.Collections.sort(Collections.java:217)
>   at 
> org.apache.jackrabbit.oak.commons.sort.ExternalSort.sortAndSave(ExternalSort.java:279)
>   at 
> org.apache.jackrabbit.oak.commons.sort.ExternalSort.sortInBatch(ExternalSort.java:218)
>   at 
> org.apache.jackrabbit.oak.commons.sort.ExternalSort.sortInBatch(ExternalSort.java:257)
>   at 
> org.apache.jackrabbit.oak.commons.sort.StringSort$PersistentState.sort(StringSort.java:191)
>   at 
> org.apache.jackrabbit.oak.commons.sort.StringSort.sort(StringSort.java:88)
>   at 
> org.apache.jackrabbit.oak.plugins.document.VersionGarbageCollector$DeletedDocsGC.ensureSorted(VersionGarbageCollector.java:383)
>   at 
> org.apache.jackrabbit.oak.plugins.document.VersionGarbageCollector$DeletedDocsGC.getDocIdsToDelete(VersionGarbageCollector.java:274)
>   at 
> org.apache.jackrabbit.oak.plugins.document.VersionGarbageCollector$DeletedDocsGC.removeDeletedDocuments(VersionGarbageCollector.java:296)
>   at 
> org.apache.jackrabbit.oak.plugins.document.VersionGarbageCollector$DeletedDocsGC.removeDocuments(VersionGarbageCollector.java:241)
>   at 
> org.apache.jackrabbit.oak.plugins.document.VersionGarbageCollector.collectDeletedDocuments(VersionGarbageCollector.java:154)
>   at 
> org.apache.jackrabbit.oak.plugins.document.VersionGarbageCollector.gc(VersionGarbageCollector.java:105)
>   at 
> org.apache.jackrabbit.oak.plugins.document.VersionGCDeletionTest.gcWithPathsHavingNewLine(VersionGCDeletionTest.java:203)
> {noformat}



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

[jira] [Commented] (OAK-3395) RevisionGC fails for JCR paths having line feed characters

2015-09-14 Thread Michael Marth (JIRA)


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

Michael Marth commented on OAK-3395:


re-phrasing Julian's question: *should* we treat these characters as illegal?

> RevisionGC fails for JCR paths having line feed characters
> --
>
> Key: OAK-3395
> URL: https://issues.apache.org/jira/browse/OAK-3395
> Project: Jackrabbit Oak
>  Issue Type: Bug
>  Components: mongomk, rdbmk
>Reporter: Chetan Mehrotra
>Assignee: Chetan Mehrotra
>Priority: Minor
> Fix For: 1.3.7, 1.2.5, 1.0.21
>
>
> RevisionGC fails with error while processing any id (derived from JCR path) 
> having line feed or carriage return char
> This happens because it relies on Oak Commons StringSort and ExternalSort 
> which works with line delimited string and having an id with line break would 
> break this sorting logic. Error reported is like
> {noformat}
> java.lang.AssertionError: Invalid id /1442211320
>   at 
> org.apache.jackrabbit.oak.plugins.document.util.Utils.getDepthFromId(Utils.java:337)
>   at 
> org.apache.jackrabbit.oak.plugins.document.NodeDocumentIdComparator.compare(NodeDocumentIdComparator.java:38)
>   at 
> org.apache.jackrabbit.oak.plugins.document.NodeDocumentIdComparator.compare(NodeDocumentIdComparator.java:30)
>   at java.util.TimSort.countRunAndMakeAscending(TimSort.java:324)
>   at java.util.TimSort.sort(TimSort.java:203)
>   at java.util.TimSort.sort(TimSort.java:173)
>   at java.util.Arrays.sort(Arrays.java:659)
>   at java.util.Collections.sort(Collections.java:217)
>   at 
> org.apache.jackrabbit.oak.commons.sort.ExternalSort.sortAndSave(ExternalSort.java:279)
>   at 
> org.apache.jackrabbit.oak.commons.sort.ExternalSort.sortInBatch(ExternalSort.java:218)
>   at 
> org.apache.jackrabbit.oak.commons.sort.ExternalSort.sortInBatch(ExternalSort.java:257)
>   at 
> org.apache.jackrabbit.oak.commons.sort.StringSort$PersistentState.sort(StringSort.java:191)
>   at 
> org.apache.jackrabbit.oak.commons.sort.StringSort.sort(StringSort.java:88)
>   at 
> org.apache.jackrabbit.oak.plugins.document.VersionGarbageCollector$DeletedDocsGC.ensureSorted(VersionGarbageCollector.java:383)
>   at 
> org.apache.jackrabbit.oak.plugins.document.VersionGarbageCollector$DeletedDocsGC.getDocIdsToDelete(VersionGarbageCollector.java:274)
>   at 
> org.apache.jackrabbit.oak.plugins.document.VersionGarbageCollector$DeletedDocsGC.removeDeletedDocuments(VersionGarbageCollector.java:296)
>   at 
> org.apache.jackrabbit.oak.plugins.document.VersionGarbageCollector$DeletedDocsGC.removeDocuments(VersionGarbageCollector.java:241)
>   at 
> org.apache.jackrabbit.oak.plugins.document.VersionGarbageCollector.collectDeletedDocuments(VersionGarbageCollector.java:154)
>   at 
> org.apache.jackrabbit.oak.plugins.document.VersionGarbageCollector.gc(VersionGarbageCollector.java:105)
>   at 
> org.apache.jackrabbit.oak.plugins.document.VersionGCDeletionTest.gcWithPathsHavingNewLine(VersionGCDeletionTest.java:203)
> {noformat}



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

[jira] [Commented] (OAK-3395) RevisionGC fails for JCR paths having line feed characters

2015-09-14 Thread Chetan Mehrotra (JIRA)


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

Chetan Mehrotra commented on OAK-3395:
--

Tried with JCR API and I am able to create nodes like 

{code}
@Test
public void nodeWithNewLine() throws Exception{
Session s = getAdminSession();
Node root = s.getRootNode();

String relPath = "a\r\nb";
root.addNode(relPath);
s.save();
Session s2 = getAdminSession();
Assert.assertEquals("/"+relPath, s2.getNode("/" +  relPath).getPath());
}
{code}

Looking at JcrPathParser#parse it allows such chars

> RevisionGC fails for JCR paths having line feed characters
> --
>
> Key: OAK-3395
> URL: https://issues.apache.org/jira/browse/OAK-3395
> Project: Jackrabbit Oak
>  Issue Type: Bug
>  Components: mongomk, rdbmk
>Reporter: Chetan Mehrotra
>Assignee: Chetan Mehrotra
>Priority: Minor
> Fix For: 1.3.7, 1.2.5, 1.0.21
>
>
> RevisionGC fails with error while processing any id (derived from JCR path) 
> having line feed or carriage return char
> This happens because it relies on Oak Commons StringSort and ExternalSort 
> which works with line delimited string and having an id with line break would 
> break this sorting logic. Error reported is like
> {noformat}
> java.lang.AssertionError: Invalid id /1442211320
>   at 
> org.apache.jackrabbit.oak.plugins.document.util.Utils.getDepthFromId(Utils.java:337)
>   at 
> org.apache.jackrabbit.oak.plugins.document.NodeDocumentIdComparator.compare(NodeDocumentIdComparator.java:38)
>   at 
> org.apache.jackrabbit.oak.plugins.document.NodeDocumentIdComparator.compare(NodeDocumentIdComparator.java:30)
>   at java.util.TimSort.countRunAndMakeAscending(TimSort.java:324)
>   at java.util.TimSort.sort(TimSort.java:203)
>   at java.util.TimSort.sort(TimSort.java:173)
>   at java.util.Arrays.sort(Arrays.java:659)
>   at java.util.Collections.sort(Collections.java:217)
>   at 
> org.apache.jackrabbit.oak.commons.sort.ExternalSort.sortAndSave(ExternalSort.java:279)
>   at 
> org.apache.jackrabbit.oak.commons.sort.ExternalSort.sortInBatch(ExternalSort.java:218)
>   at 
> org.apache.jackrabbit.oak.commons.sort.ExternalSort.sortInBatch(ExternalSort.java:257)
>   at 
> org.apache.jackrabbit.oak.commons.sort.StringSort$PersistentState.sort(StringSort.java:191)
>   at 
> org.apache.jackrabbit.oak.commons.sort.StringSort.sort(StringSort.java:88)
>   at 
> org.apache.jackrabbit.oak.plugins.document.VersionGarbageCollector$DeletedDocsGC.ensureSorted(VersionGarbageCollector.java:383)
>   at 
> org.apache.jackrabbit.oak.plugins.document.VersionGarbageCollector$DeletedDocsGC.getDocIdsToDelete(VersionGarbageCollector.java:274)
>   at 
> org.apache.jackrabbit.oak.plugins.document.VersionGarbageCollector$DeletedDocsGC.removeDeletedDocuments(VersionGarbageCollector.java:296)
>   at 
> org.apache.jackrabbit.oak.plugins.document.VersionGarbageCollector$DeletedDocsGC.removeDocuments(VersionGarbageCollector.java:241)
>   at 
> org.apache.jackrabbit.oak.plugins.document.VersionGarbageCollector.collectDeletedDocuments(VersionGarbageCollector.java:154)
>   at 
> org.apache.jackrabbit.oak.plugins.document.VersionGarbageCollector.gc(VersionGarbageCollector.java:105)
>   at 
> org.apache.jackrabbit.oak.plugins.document.VersionGCDeletionTest.gcWithPathsHavingNewLine(VersionGCDeletionTest.java:203)
> {noformat}



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

[jira] [Commented] (OAK-3366) Property indexes reindex flag getting reset to true at startup

2015-09-14 Thread Elemer Kisch (JIRA)


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

Elemer Kisch commented on OAK-3366:
---

[~chetanm] Yepp, thank you for clarifying.

> Property indexes reindex flag getting reset to true at startup
> --
>
> Key: OAK-3366
> URL: https://issues.apache.org/jira/browse/OAK-3366
> Project: Jackrabbit Oak
>  Issue Type: Bug
>  Components: jcr
>Reporter: Chetan Mehrotra
>Assignee: Chetan Mehrotra
> Fix For: 1.3.6
>
> Attachments: OAK-3366-01.patch, OAK-3366.patch
>
>
> At times it is seen that {{reindex}} flag for property indexes is getting 
> reset to true. As per analysis by [~alex.parvulescu] it happens due to the 
> order in which repository gets started and PropertyIndexEditorProvider gets 
> registered. 
> If the editor is registered after repository got started then _missing index 
> provider_ for the 'property' type will silently set *all* the existing 
> property index definitions reindex flags to true.
> After some offline discussion it was decided that proper fix here would be to 
> ensure that repository is only started *after* property index editor gets 
> registered. This would ensure that the whiteboard tracker would be opened in 
> that activate itself after the provider is registered and it is ensured that 
> if a tracker is opened it gets access to already registered services without 
> any delay. This would avoid any scenario where commit happens without any 
> property index editor being present



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

[jira] [Commented] (OAK-3366) Property indexes reindex flag getting reset to true at startup

2015-09-14 Thread Chetan Mehrotra (JIRA)


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

Chetan Mehrotra commented on OAK-3366:
--

[~elemer] The fix here need not be backported. I believe your query is related 
to same issue affecting Adobe AEM then the fix for that is done in a different 
way in an Adobe internal component

> Property indexes reindex flag getting reset to true at startup
> --
>
> Key: OAK-3366
> URL: https://issues.apache.org/jira/browse/OAK-3366
> Project: Jackrabbit Oak
>  Issue Type: Bug
>  Components: jcr
>Reporter: Chetan Mehrotra
>Assignee: Chetan Mehrotra
> Fix For: 1.3.6
>
> Attachments: OAK-3366-01.patch, OAK-3366.patch
>
>
> At times it is seen that {{reindex}} flag for property indexes is getting 
> reset to true. As per analysis by [~alex.parvulescu] it happens due to the 
> order in which repository gets started and PropertyIndexEditorProvider gets 
> registered. 
> If the editor is registered after repository got started then _missing index 
> provider_ for the 'property' type will silently set *all* the existing 
> property index definitions reindex flags to true.
> After some offline discussion it was decided that proper fix here would be to 
> ensure that repository is only started *after* property index editor gets 
> registered. This would ensure that the whiteboard tracker would be opened in 
> that activate itself after the provider is registered and it is ensured that 
> if a tracker is opened it gets access to already registered services without 
> any delay. This would avoid any scenario where commit happens without any 
> property index editor being present



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

[jira] [Commented] (OAK-3366) Property indexes reindex flag getting reset to true at startup

2015-09-14 Thread Elemer Kisch (JIRA)


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

Elemer Kisch commented on OAK-3366:
---

[~chetanm] is this issue not fixed for the 1.0.x ?

> Property indexes reindex flag getting reset to true at startup
> --
>
> Key: OAK-3366
> URL: https://issues.apache.org/jira/browse/OAK-3366
> Project: Jackrabbit Oak
>  Issue Type: Bug
>  Components: jcr
>Reporter: Chetan Mehrotra
>Assignee: Chetan Mehrotra
> Fix For: 1.3.6
>
> Attachments: OAK-3366-01.patch, OAK-3366.patch
>
>
> At times it is seen that {{reindex}} flag for property indexes is getting 
> reset to true. As per analysis by [~alex.parvulescu] it happens due to the 
> order in which repository gets started and PropertyIndexEditorProvider gets 
> registered. 
> If the editor is registered after repository got started then _missing index 
> provider_ for the 'property' type will silently set *all* the existing 
> property index definitions reindex flags to true.
> After some offline discussion it was decided that proper fix here would be to 
> ensure that repository is only started *after* property index editor gets 
> registered. This would ensure that the whiteboard tracker would be opened in 
> that activate itself after the provider is registered and it is ensured that 
> if a tracker is opened it gets access to already registered services without 
> any delay. This would avoid any scenario where commit happens without any 
> property index editor being present



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

[jira] [Updated] (OAK-3395) RevisionGC fails for JCR paths having line feed characters

2015-09-14 Thread Marcel Reutegger (JIRA)


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

Marcel Reutegger updated OAK-3395:
--
Fix Version/s: (was: 1.3.6)
   1.3.7

> RevisionGC fails for JCR paths having line feed characters
> --
>
> Key: OAK-3395
> URL: https://issues.apache.org/jira/browse/OAK-3395
> Project: Jackrabbit Oak
>  Issue Type: Bug
>  Components: mongomk, rdbmk
>Reporter: Chetan Mehrotra
>Assignee: Chetan Mehrotra
>Priority: Minor
> Fix For: 1.3.7, 1.2.5, 1.0.21
>
>
> RevisionGC fails with error while processing any id (derived from JCR path) 
> having line feed or carriage return char
> This happens because it relies on Oak Commons StringSort and ExternalSort 
> which works with line delimited string and having an id with line break would 
> break this sorting logic. Error reported is like
> {noformat}
> java.lang.AssertionError: Invalid id /1442211320
>   at 
> org.apache.jackrabbit.oak.plugins.document.util.Utils.getDepthFromId(Utils.java:337)
>   at 
> org.apache.jackrabbit.oak.plugins.document.NodeDocumentIdComparator.compare(NodeDocumentIdComparator.java:38)
>   at 
> org.apache.jackrabbit.oak.plugins.document.NodeDocumentIdComparator.compare(NodeDocumentIdComparator.java:30)
>   at java.util.TimSort.countRunAndMakeAscending(TimSort.java:324)
>   at java.util.TimSort.sort(TimSort.java:203)
>   at java.util.TimSort.sort(TimSort.java:173)
>   at java.util.Arrays.sort(Arrays.java:659)
>   at java.util.Collections.sort(Collections.java:217)
>   at 
> org.apache.jackrabbit.oak.commons.sort.ExternalSort.sortAndSave(ExternalSort.java:279)
>   at 
> org.apache.jackrabbit.oak.commons.sort.ExternalSort.sortInBatch(ExternalSort.java:218)
>   at 
> org.apache.jackrabbit.oak.commons.sort.ExternalSort.sortInBatch(ExternalSort.java:257)
>   at 
> org.apache.jackrabbit.oak.commons.sort.StringSort$PersistentState.sort(StringSort.java:191)
>   at 
> org.apache.jackrabbit.oak.commons.sort.StringSort.sort(StringSort.java:88)
>   at 
> org.apache.jackrabbit.oak.plugins.document.VersionGarbageCollector$DeletedDocsGC.ensureSorted(VersionGarbageCollector.java:383)
>   at 
> org.apache.jackrabbit.oak.plugins.document.VersionGarbageCollector$DeletedDocsGC.getDocIdsToDelete(VersionGarbageCollector.java:274)
>   at 
> org.apache.jackrabbit.oak.plugins.document.VersionGarbageCollector$DeletedDocsGC.removeDeletedDocuments(VersionGarbageCollector.java:296)
>   at 
> org.apache.jackrabbit.oak.plugins.document.VersionGarbageCollector$DeletedDocsGC.removeDocuments(VersionGarbageCollector.java:241)
>   at 
> org.apache.jackrabbit.oak.plugins.document.VersionGarbageCollector.collectDeletedDocuments(VersionGarbageCollector.java:154)
>   at 
> org.apache.jackrabbit.oak.plugins.document.VersionGarbageCollector.gc(VersionGarbageCollector.java:105)
>   at 
> org.apache.jackrabbit.oak.plugins.document.VersionGCDeletionTest.gcWithPathsHavingNewLine(VersionGCDeletionTest.java:203)
> {noformat}



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

[jira] [Updated] (OAK-3054) IndexStatsMBean should provide some details if the async indexing is failing

2015-09-14 Thread Marcel Reutegger (JIRA)


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

Marcel Reutegger updated OAK-3054:
--
Fix Version/s: (was: 1.3.6)
   1.3.7

> IndexStatsMBean should provide some details if the async indexing is failing
> 
>
> Key: OAK-3054
> URL: https://issues.apache.org/jira/browse/OAK-3054
> Project: Jackrabbit Oak
>  Issue Type: Improvement
>  Components: query
>Reporter: Chetan Mehrotra
>Priority: Minor
>  Labels: resilience, tooling
> Fix For: 1.3.7, 1.2.6
>
>
> If the background indexing fails for some reason it logs the exception for 
> the first time then it logs the exception like _The index update failed ..._. 
> After that if indexing continues to fail then no further logging is done so 
> as to avoid creating noise.
> This poses a problem on long running system where original exception might 
> not be noticed and index does not show updated result. For such cases we 
> should expose the indexing health as part of {{IndexStatsMBean}}. Also we can 
> provide the last recorded exception. 
> Administrator can then check for MBean and enable debug logs for further 
> troubleshooting



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

[jira] [Updated] (OAK-3250) Restart DocumentNodeStore on lease timeout instead of System.exit

2015-09-14 Thread Stefan Egli (JIRA)


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

Stefan Egli updated OAK-3250:
-
Fix Version/s: (was: 1.3.6)
   1.4

Unscheduling this from 1.3 for now as we should follow-up on OAK-3397 as the 
short-to-medium term solution (long-term we might be able to come back to 
OAK-3250)

> Restart DocumentNodeStore on lease timeout instead of System.exit
> -
>
> Key: OAK-3250
> URL: https://issues.apache.org/jira/browse/OAK-3250
> Project: Jackrabbit Oak
>  Issue Type: Improvement
>  Components: core
>Affects Versions: 1.3.4
>Reporter: Stefan Egli
>Assignee: Stefan Egli
> Fix For: 1.4
>
>
> As discussed [on the list|http://markmail.org/thread/uo6n5oozlbhe7ifg] usage 
> of System.exit is not ideal and one suggested alternative is to follow up on 
> the idea to instead perform a 'restart of DocumentNodeStore' - while marking 
> the local instance as 'deactivating' towards discovery-lite-descriptor so 
> that upper layer discovery.oak can properly send a TOPOLOGY_CHANGING to all 
> listeners, so that they immediately stop any topology-dependent activity.



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

[jira] [Created] (OAK-3397) stop oak-core bundle on lease failure

2015-09-14 Thread Stefan Egli (JIRA)

Stefan Egli created OAK-3397:


 Summary: stop oak-core bundle on lease failure
 Key: OAK-3397
 URL: https://issues.apache.org/jira/browse/OAK-3397
 Project: Jackrabbit Oak
  Issue Type: Improvement
  Components: core
Affects Versions: 1.3.4
Reporter: Stefan Egli
Assignee: Stefan Egli
 Fix For: 1.3.6


As being discussed [on the 
list|http://oak.markmail.org/thread/qja6ieqe5z27wolf] restarting 
DocumentNodeStore (OAK-3250) as originally suggested seems not-so-trivial and 
has further side-effects that would first have to be resolved. So in order to 
still be able to get rid of the System.exit, the suggestion is to stop the 
oak-core bundle instead.



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

[jira] [Updated] (OAK-1617) Automatically convert "or" queries to "union" for SQL-2

2015-09-14 Thread Marcel Reutegger (JIRA)


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

Marcel Reutegger updated OAK-1617:
--
Fix Version/s: (was: 1.4)

> Automatically convert "or" queries to "union" for SQL-2
> ---
>
> Key: OAK-1617
> URL: https://issues.apache.org/jira/browse/OAK-1617
> Project: Jackrabbit Oak
>  Issue Type: Improvement
>  Components: query
>Reporter: Thomas Mueller
>Assignee: Davide Giannella
>Priority: Minor
> Fix For: 1.3.6
>
>
> XPath queries that contain "or" conditions are automatically converted to 
> "union" SQL-2 queries. However, SQL-2 queries that contain "or" conditions 
> are not (yet).



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

[jira] [Assigned] (OAK-3390) Avoid instanceof check in DocumentNodeStore

2015-09-14 Thread Marcel Reutegger (JIRA)


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

Marcel Reutegger reassigned OAK-3390:
-

Assignee: Marcel Reutegger

> Avoid instanceof check in DocumentNodeStore
> ---
>
> Key: OAK-3390
> URL: https://issues.apache.org/jira/browse/OAK-3390
> Project: Jackrabbit Oak
>  Issue Type: Bug
>  Components: core, mongomk
>Affects Versions: 1.3.4
>Reporter: Marcel Reutegger
>Assignee: Marcel Reutegger
> Fix For: 1.3.7
>
>
> The instanceof MongoDocumentStore check does not work anymore when the store 
> is wrapped with e.g. the LeaseCheckDocumentStoreWrapper.



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

[jira] [Updated] (OAK-3389) oak-run check for dropped tables broken

2015-09-14 Thread Stefan Egli (JIRA)


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

Stefan Egli updated OAK-3389:
-
Attachment: OAK-3389.patch

As suggested by Marcel on [the 
list|http://markmail.org/message/dlz5h7db6umf5t2w] one short-term fix would be 
to disable the lease-check here. Attached a suggested patch which does this: 
[^OAK-3389.patch]

> oak-run check for dropped tables broken
> ---
>
> Key: OAK-3389
> URL: https://issues.apache.org/jira/browse/OAK-3389
> Project: Jackrabbit Oak
>  Issue Type: Technical task
>  Components: rdbmk, run
>Affects Versions: 1.3.5
>Reporter: Julian Reschke
> Attachments: OAK-3389.patch
>
>
> @Override
> public void tearDownCluster() {
> String dropped = "";
> for (DocumentMK kernel : kernels) {
> kernel.dispose();
> if (kernel.getDocumentStore() instanceof 
> RDBDocumentStore) {
> dropped += 
> ((RDBDocumentStore)kernel.getDocumentStore()).getDroppedTables();
> }
> }
> if (dropDBAfterTest) {
> if(blobStoreFixture != null){
> blobStoreFixture.tearDown();
> }
> if (dropped.isEmpty()) {
> throw new RuntimeException("dropdb was set, but 
> tables have not been dropped");
> }
> }
> }
> has been broken because the DS is now wrapped by 
> LeaseCheckDocumentStoreWrapper. Figure out a different way to obtain the 
> information.



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

[jira] [Commented] (OAK-3389) oak-run check for dropped tables broken

2015-09-14 Thread Marcel Reutegger (JIRA)


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

Marcel Reutegger commented on OAK-3389:
---

Disabled lease check in oak-run RDBFixture as a temporary workaround: 
http://svn.apache.org/r1702864

> oak-run check for dropped tables broken
> ---
>
> Key: OAK-3389
> URL: https://issues.apache.org/jira/browse/OAK-3389
> Project: Jackrabbit Oak
>  Issue Type: Technical task
>  Components: rdbmk, run
>Affects Versions: 1.3.5
>Reporter: Julian Reschke
> Attachments: OAK-3389.patch
>
>
> @Override
> public void tearDownCluster() {
> String dropped = "";
> for (DocumentMK kernel : kernels) {
> kernel.dispose();
> if (kernel.getDocumentStore() instanceof 
> RDBDocumentStore) {
> dropped += 
> ((RDBDocumentStore)kernel.getDocumentStore()).getDroppedTables();
> }
> }
> if (dropDBAfterTest) {
> if(blobStoreFixture != null){
> blobStoreFixture.tearDown();
> }
> if (dropped.isEmpty()) {
> throw new RuntimeException("dropdb was set, but 
> tables have not been dropped");
> }
> }
> }
> has been broken because the DS is now wrapped by 
> LeaseCheckDocumentStoreWrapper. Figure out a different way to obtain the 
> information.



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

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

2015-09-14 Thread Stefan Egli (JIRA)


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

Stefan Egli updated OAK-3396:
-
Attachment: OAK-3396.patch

Attaching a suggested fix ([^OAK-3396.patch]) which would catch the NPE and 
translate it into a {{LdapInvalidAttributeValueException}} which is caught 
further up the stack.

> 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
>Priority: Minor
> Fix For: 1.0.20
>
> Attachments: OAK-3396.patch
>
>
> 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] [Created] (OAK-3396) NPE during syncAllExternalUsers in LdapIdentityProvider.createUser

2015-09-14 Thread Stefan Egli (JIRA)

Stefan Egli created OAK-3396:


 Summary: 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
Priority: Minor
 Fix For: 1.0.20


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-3390) Avoid instanceof check in DocumentNodeStore

2015-09-14 Thread Julian Reschke (JIRA)


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

Julian Reschke commented on OAK-3390:
-

More breakage in a different place: 
https://issues.apache.org/jira/browse/OAK-3389 (and I don't believe we'd want 
to handle that with Builder extensions). Also, we know that the multiplexing 
implementation will have the same problem.

> Avoid instanceof check in DocumentNodeStore
> ---
>
> Key: OAK-3390
> URL: https://issues.apache.org/jira/browse/OAK-3390
> Project: Jackrabbit Oak
>  Issue Type: Bug
>  Components: core, mongomk
>Affects Versions: 1.3.4
>Reporter: Marcel Reutegger
> Fix For: 1.3.7
>
>
> The instanceof MongoDocumentStore check does not work anymore when the store 
> is wrapped with e.g. the LeaseCheckDocumentStoreWrapper.



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

[jira] [Commented] (OAK-3390) Avoid instanceof check in DocumentNodeStore

2015-09-14 Thread Julian Reschke (JIRA)


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

Julian Reschke commented on OAK-3390:
-

If that was true, why do we have the current breakage then? :-)

> Avoid instanceof check in DocumentNodeStore
> ---
>
> Key: OAK-3390
> URL: https://issues.apache.org/jira/browse/OAK-3390
> Project: Jackrabbit Oak
>  Issue Type: Bug
>  Components: core, mongomk
>Affects Versions: 1.3.4
>Reporter: Marcel Reutegger
> Fix For: 1.3.7
>
>
> The instanceof MongoDocumentStore check does not work anymore when the store 
> is wrapped with e.g. the LeaseCheckDocumentStoreWrapper.



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

[jira] [Commented] (OAK-3390) Avoid instanceof check in DocumentNodeStore

2015-09-14 Thread Marcel Reutegger (JIRA)


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

Marcel Reutegger commented on OAK-3390:
---

I agree with Stefan. We are talking about as single instanceof we would like to 
get rid of. As mentioned before my preference is to move this factory method to 
a place where we know what kind of backend store is used. This is currently the 
DocumentMK.Builder, but in the long run we should probably split it up into a 
generic Builder and introduce two new builders: one for MongoDB and another one 
for RDB.

> Avoid instanceof check in DocumentNodeStore
> ---
>
> Key: OAK-3390
> URL: https://issues.apache.org/jira/browse/OAK-3390
> Project: Jackrabbit Oak
>  Issue Type: Bug
>  Components: core, mongomk
>Affects Versions: 1.3.4
>Reporter: Marcel Reutegger
> Fix For: 1.3.7
>
>
> The instanceof MongoDocumentStore check does not work anymore when the store 
> is wrapped with e.g. the LeaseCheckDocumentStoreWrapper.



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

[jira] [Commented] (OAK-3390) Avoid instanceof check in DocumentNodeStore

2015-09-14 Thread Stefan Egli (JIRA)


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

Stefan Egli commented on OAK-3390:
--

my take on doing a generic {{Adaptable}} is that that makes sense in a Silng 
Resource context since Resource is going to be very frequently used and will 
have many different adapter classes - while as with {{DocumentNodeStore}} we're 
inside an implementation and the number of adapter classes will be very few and 
are mostly known beforehand.

> Avoid instanceof check in DocumentNodeStore
> ---
>
> Key: OAK-3390
> URL: https://issues.apache.org/jira/browse/OAK-3390
> Project: Jackrabbit Oak
>  Issue Type: Bug
>  Components: core, mongomk
>Affects Versions: 1.3.4
>Reporter: Marcel Reutegger
> Fix For: 1.3.7
>
>
> The instanceof MongoDocumentStore check does not work anymore when the store 
> is wrapped with e.g. the LeaseCheckDocumentStoreWrapper.



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

[jira] [Commented] (OAK-3395) RevisionGC fails for JCR paths having line feed characters

2015-09-14 Thread Julian Reschke (JIRA)


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

Julian Reschke commented on OAK-3395:
-

Don't we treat all whitespace characters != SP as illegal?

> RevisionGC fails for JCR paths having line feed characters
> --
>
> Key: OAK-3395
> URL: https://issues.apache.org/jira/browse/OAK-3395
> Project: Jackrabbit Oak
>  Issue Type: Bug
>  Components: mongomk, rdbmk
>Reporter: Chetan Mehrotra
>Assignee: Chetan Mehrotra
>Priority: Minor
> Fix For: 1.3.6, 1.2.5, 1.0.21
>
>
> RevisionGC fails with error while processing any id (derived from JCR path) 
> having line feed or carriage return char
> This happens because it relies on Oak Commons StringSort and ExternalSort 
> which works with line delimited string and having an id with line break would 
> break this sorting logic. Error reported is like
> {noformat}
> java.lang.AssertionError: Invalid id /1442211320
>   at 
> org.apache.jackrabbit.oak.plugins.document.util.Utils.getDepthFromId(Utils.java:337)
>   at 
> org.apache.jackrabbit.oak.plugins.document.NodeDocumentIdComparator.compare(NodeDocumentIdComparator.java:38)
>   at 
> org.apache.jackrabbit.oak.plugins.document.NodeDocumentIdComparator.compare(NodeDocumentIdComparator.java:30)
>   at java.util.TimSort.countRunAndMakeAscending(TimSort.java:324)
>   at java.util.TimSort.sort(TimSort.java:203)
>   at java.util.TimSort.sort(TimSort.java:173)
>   at java.util.Arrays.sort(Arrays.java:659)
>   at java.util.Collections.sort(Collections.java:217)
>   at 
> org.apache.jackrabbit.oak.commons.sort.ExternalSort.sortAndSave(ExternalSort.java:279)
>   at 
> org.apache.jackrabbit.oak.commons.sort.ExternalSort.sortInBatch(ExternalSort.java:218)
>   at 
> org.apache.jackrabbit.oak.commons.sort.ExternalSort.sortInBatch(ExternalSort.java:257)
>   at 
> org.apache.jackrabbit.oak.commons.sort.StringSort$PersistentState.sort(StringSort.java:191)
>   at 
> org.apache.jackrabbit.oak.commons.sort.StringSort.sort(StringSort.java:88)
>   at 
> org.apache.jackrabbit.oak.plugins.document.VersionGarbageCollector$DeletedDocsGC.ensureSorted(VersionGarbageCollector.java:383)
>   at 
> org.apache.jackrabbit.oak.plugins.document.VersionGarbageCollector$DeletedDocsGC.getDocIdsToDelete(VersionGarbageCollector.java:274)
>   at 
> org.apache.jackrabbit.oak.plugins.document.VersionGarbageCollector$DeletedDocsGC.removeDeletedDocuments(VersionGarbageCollector.java:296)
>   at 
> org.apache.jackrabbit.oak.plugins.document.VersionGarbageCollector$DeletedDocsGC.removeDocuments(VersionGarbageCollector.java:241)
>   at 
> org.apache.jackrabbit.oak.plugins.document.VersionGarbageCollector.collectDeletedDocuments(VersionGarbageCollector.java:154)
>   at 
> org.apache.jackrabbit.oak.plugins.document.VersionGarbageCollector.gc(VersionGarbageCollector.java:105)
>   at 
> org.apache.jackrabbit.oak.plugins.document.VersionGCDeletionTest.gcWithPathsHavingNewLine(VersionGCDeletionTest.java:203)
> {noformat}



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

[jira] [Commented] (OAK-3395) RevisionGC fails for JCR paths having line feed characters

2015-09-14 Thread Chetan Mehrotra (JIRA)


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

Chetan Mehrotra commented on OAK-3395:
--

Added ignored testcase with http://svn.apache.org/r1702860

> RevisionGC fails for JCR paths having line feed characters
> --
>
> Key: OAK-3395
> URL: https://issues.apache.org/jira/browse/OAK-3395
> Project: Jackrabbit Oak
>  Issue Type: Bug
>  Components: mongomk, rdbmk
>Reporter: Chetan Mehrotra
>Assignee: Chetan Mehrotra
>Priority: Minor
> Fix For: 1.3.6, 1.2.5, 1.0.21
>
>
> RevisionGC fails with error while processing any id (derived from JCR path) 
> having line feed or carriage return char
> This happens because it relies on Oak Commons StringSort and ExternalSort 
> which works with line delimited string and having an id with line break would 
> break this sorting logic. Error reported is like
> {noformat}
> java.lang.AssertionError: Invalid id /1442211320
>   at 
> org.apache.jackrabbit.oak.plugins.document.util.Utils.getDepthFromId(Utils.java:337)
>   at 
> org.apache.jackrabbit.oak.plugins.document.NodeDocumentIdComparator.compare(NodeDocumentIdComparator.java:38)
>   at 
> org.apache.jackrabbit.oak.plugins.document.NodeDocumentIdComparator.compare(NodeDocumentIdComparator.java:30)
>   at java.util.TimSort.countRunAndMakeAscending(TimSort.java:324)
>   at java.util.TimSort.sort(TimSort.java:203)
>   at java.util.TimSort.sort(TimSort.java:173)
>   at java.util.Arrays.sort(Arrays.java:659)
>   at java.util.Collections.sort(Collections.java:217)
>   at 
> org.apache.jackrabbit.oak.commons.sort.ExternalSort.sortAndSave(ExternalSort.java:279)
>   at 
> org.apache.jackrabbit.oak.commons.sort.ExternalSort.sortInBatch(ExternalSort.java:218)
>   at 
> org.apache.jackrabbit.oak.commons.sort.ExternalSort.sortInBatch(ExternalSort.java:257)
>   at 
> org.apache.jackrabbit.oak.commons.sort.StringSort$PersistentState.sort(StringSort.java:191)
>   at 
> org.apache.jackrabbit.oak.commons.sort.StringSort.sort(StringSort.java:88)
>   at 
> org.apache.jackrabbit.oak.plugins.document.VersionGarbageCollector$DeletedDocsGC.ensureSorted(VersionGarbageCollector.java:383)
>   at 
> org.apache.jackrabbit.oak.plugins.document.VersionGarbageCollector$DeletedDocsGC.getDocIdsToDelete(VersionGarbageCollector.java:274)
>   at 
> org.apache.jackrabbit.oak.plugins.document.VersionGarbageCollector$DeletedDocsGC.removeDeletedDocuments(VersionGarbageCollector.java:296)
>   at 
> org.apache.jackrabbit.oak.plugins.document.VersionGarbageCollector$DeletedDocsGC.removeDocuments(VersionGarbageCollector.java:241)
>   at 
> org.apache.jackrabbit.oak.plugins.document.VersionGarbageCollector.collectDeletedDocuments(VersionGarbageCollector.java:154)
>   at 
> org.apache.jackrabbit.oak.plugins.document.VersionGarbageCollector.gc(VersionGarbageCollector.java:105)
>   at 
> org.apache.jackrabbit.oak.plugins.document.VersionGCDeletionTest.gcWithPathsHavingNewLine(VersionGCDeletionTest.java:203)
> {noformat}



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

[jira] [Updated] (OAK-3395) RevisionGC fails for JCR paths having line feed characters

2015-09-14 Thread Chetan Mehrotra (JIRA)


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

Chetan Mehrotra updated OAK-3395:
-
Description: 
RevisionGC fails with error while processing any id (derived from JCR path) 
having line feed or carriage return char

This happens because it relies on Oak Commons StringSort and ExternalSort which 
works with line delimited string and having an id with line break would break 
this sorting logic. Error reported is like

{noformat}
java.lang.AssertionError: Invalid id /1442211320
at 
org.apache.jackrabbit.oak.plugins.document.util.Utils.getDepthFromId(Utils.java:337)
at 
org.apache.jackrabbit.oak.plugins.document.NodeDocumentIdComparator.compare(NodeDocumentIdComparator.java:38)
at 
org.apache.jackrabbit.oak.plugins.document.NodeDocumentIdComparator.compare(NodeDocumentIdComparator.java:30)
at java.util.TimSort.countRunAndMakeAscending(TimSort.java:324)
at java.util.TimSort.sort(TimSort.java:203)
at java.util.TimSort.sort(TimSort.java:173)
at java.util.Arrays.sort(Arrays.java:659)
at java.util.Collections.sort(Collections.java:217)
at 
org.apache.jackrabbit.oak.commons.sort.ExternalSort.sortAndSave(ExternalSort.java:279)
at 
org.apache.jackrabbit.oak.commons.sort.ExternalSort.sortInBatch(ExternalSort.java:218)
at 
org.apache.jackrabbit.oak.commons.sort.ExternalSort.sortInBatch(ExternalSort.java:257)
at 
org.apache.jackrabbit.oak.commons.sort.StringSort$PersistentState.sort(StringSort.java:191)
at 
org.apache.jackrabbit.oak.commons.sort.StringSort.sort(StringSort.java:88)
at 
org.apache.jackrabbit.oak.plugins.document.VersionGarbageCollector$DeletedDocsGC.ensureSorted(VersionGarbageCollector.java:383)
at 
org.apache.jackrabbit.oak.plugins.document.VersionGarbageCollector$DeletedDocsGC.getDocIdsToDelete(VersionGarbageCollector.java:274)
at 
org.apache.jackrabbit.oak.plugins.document.VersionGarbageCollector$DeletedDocsGC.removeDeletedDocuments(VersionGarbageCollector.java:296)
at 
org.apache.jackrabbit.oak.plugins.document.VersionGarbageCollector$DeletedDocsGC.removeDocuments(VersionGarbageCollector.java:241)
at 
org.apache.jackrabbit.oak.plugins.document.VersionGarbageCollector.collectDeletedDocuments(VersionGarbageCollector.java:154)
at 
org.apache.jackrabbit.oak.plugins.document.VersionGarbageCollector.gc(VersionGarbageCollector.java:105)
at 
org.apache.jackrabbit.oak.plugins.document.VersionGCDeletionTest.gcWithPathsHavingNewLine(VersionGCDeletionTest.java:203)
{noformat}

  was:
RevisionGC fails with error while processing any id (derived from JCR path) 
having line feed or carriage return char

This happens because it relies on Oak Commons StringSort and ExternalSort which 
works with line delimited string and having an id with line break would break 
this sorting logic


> RevisionGC fails for JCR paths having line feed characters
> --
>
> Key: OAK-3395
> URL: https://issues.apache.org/jira/browse/OAK-3395
> Project: Jackrabbit Oak
>  Issue Type: Bug
>  Components: mongomk, rdbmk
>Reporter: Chetan Mehrotra
>Assignee: Chetan Mehrotra
>Priority: Minor
> Fix For: 1.3.6, 1.2.5, 1.0.21
>
>
> RevisionGC fails with error while processing any id (derived from JCR path) 
> having line feed or carriage return char
> This happens because it relies on Oak Commons StringSort and ExternalSort 
> which works with line delimited string and having an id with line break would 
> break this sorting logic. Error reported is like
> {noformat}
> java.lang.AssertionError: Invalid id /1442211320
>   at 
> org.apache.jackrabbit.oak.plugins.document.util.Utils.getDepthFromId(Utils.java:337)
>   at 
> org.apache.jackrabbit.oak.plugins.document.NodeDocumentIdComparator.compare(NodeDocumentIdComparator.java:38)
>   at 
> org.apache.jackrabbit.oak.plugins.document.NodeDocumentIdComparator.compare(NodeDocumentIdComparator.java:30)
>   at java.util.TimSort.countRunAndMakeAscending(TimSort.java:324)
>   at java.util.TimSort.sort(TimSort.java:203)
>   at java.util.TimSort.sort(TimSort.java:173)
>   at java.util.Arrays.sort(Arrays.java:659)
>   at java.util.Collections.sort(Collections.java:217)
>   at 
> org.apache.jackrabbit.oak.commons.sort.ExternalSort.sortAndSave(ExternalSort.java:279)
>   at 
> org.apache.jackrabbit.oak.commons.sort.ExternalSort.sortInBatch(ExternalSort.java:218)
>   at 
> org.apache.jackrabbit.oak.commons.sort.ExternalSort.sortInBatch(ExternalSort.java:257)
>   at 
> org.apache.jackrabbit.oak.commons.sort.StringSort$PersistentState.sort(StringSort.java:191)
>   at 
> org.apache.jackrabbit.oak.commons.sort.StringSort.sort(StringSort.java

[jira] [Created] (OAK-3395) RevisionGC fails for JCR paths having line feed characters

2015-09-14 Thread Chetan Mehrotra (JIRA)

Chetan Mehrotra created OAK-3395:


 Summary: RevisionGC fails for JCR paths having line feed characters
 Key: OAK-3395
 URL: https://issues.apache.org/jira/browse/OAK-3395
 Project: Jackrabbit Oak
  Issue Type: Bug
  Components: mongomk, rdbmk
Reporter: Chetan Mehrotra
Assignee: Chetan Mehrotra
Priority: Minor
 Fix For: 1.3.6, 1.2.5, 1.0.21


RevisionGC fails with error while processing any id (derived from JCR path) 
having line feed or carriage return char

This happens because it relies on Oak Commons StringSort and ExternalSort which 
works with line delimited string and having an id with line break would break 
this sorting logic



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

57 matches

Mail list logo