[jira] [Commented] (JCR-3981) Null pointer exception on journal synchronization

[liang cheng (JIRA)]

[ 
https://issues.apache.org/jira/browse/JCR-3981?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15472430#comment-15472430
 ] 

liang cheng commented on JCR-3981:
--

one of our customer also hit this issue.  It's really urgent for us

> Null pointer exception on journal synchronization
> -
>
> Key: JCR-3981
> URL: https://issues.apache.org/jira/browse/JCR-3981
> Project: Jackrabbit Content Repository
>  Issue Type: Bug
>  Components: jackrabbit-core
>Affects Versions: 2.11.3
>Reporter: Illia Khokholkov
>
> Using Jackrabbit 2.x, I am experiencing an issue that is similar if not 
> identical to the JCR-773, which was "remedied" a long time. The stack trace 
> of an exception looks like this:
> {noformat}
> java.lang.NullPointerException: null
>   at java.io.FilterInputStream.close(FilterInputStream.java:181)
>   at 
> org.apache.jackrabbit.core.journal.ReadRecord.close(ReadRecord.java:212)
>   at 
> org.apache.jackrabbit.core.journal.DatabaseRecordIterator.close(DatabaseRecordIterator.java:155)
>   at 
> org.apache.jackrabbit.core.journal.DatabaseRecordIterator.close(DatabaseRecordIterator.java:121)
>   at 
> org.apache.jackrabbit.core.journal.AbstractJournal.doSync(AbstractJournal.java:263)
>   at 
> org.apache.jackrabbit.core.journal.DatabaseJournal.doSync(DatabaseJournal.java:458)
>   at 
> org.apache.jackrabbit.core.journal.AbstractJournal.internalSync(AbstractJournal.java:222)
>   at 
> org.apache.jackrabbit.core.journal.AbstractJournal.sync(AbstractJournal.java:190)
>   at 
> org.apache.jackrabbit.core.cluster.ClusterNode.internalSync(ClusterNode.java:340)
>   at 
> org.apache.jackrabbit.core.cluster.ClusterNode.syncOnStartup(ClusterNode.java:365)
>   at 
> org.apache.jackrabbit.core.cluster.ClusterNode.start(ClusterNode.java:277)
>   at 
> org.apache.jackrabbit.core.RepositoryImpl.(RepositoryImpl.java:344)
> {noformat}
> Unfortunately, I cannot determine the root cause of the problem yet, because 
> it appears to be sporadic. However, when it happens, none of the cluster 
> members can ever get back to normal.
> *Questions*
> As pointed out before, the JCR-773 is marked as fixed so I assume there 
> should be no errors like the ones I see. Anyway, it would be great if I could 
> get an answer to the following question:
> * Is this a known problem and if so, how can it be mitigated/eliminated?



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

Re: Usecases around Binary handling in Oak

[Alexander Klimetschek]

Hi everyone,

late to the game… back from a long leave :) I just wanted to chime in the 
security discussion.

Please be aware that the ReferenceBinary interface [1] exists today (I haven't 
seen that mentioned in this or the previous thread, please excuse if I missed 
it). It has a String getReference() method which in case of a filedata store 
will include the hash, from which you can calculate the file location. We have 
actively used this in a performance optimization as described in the use case 
as described by Chetan. See [2] for some code showcasing it.

Yes, this requires knowing an implementation detail (and we fall back to using 
the JCR binary interface in case the file cannot be found), but if you think 
there is a security issue, it exists in Jackrabbit/Oak already.

I do understand the performance problem, which can be a big one, so finding a 
secure solution would be great. The important case is IMO about bridging 
non-JCR-API capable application (say imagemagick, S3 URLs/browsers etc.), which 
cannot be rewritten to use the JCR API, with the file data store, and IIUC 
readonly access is fine (UC1 mostly).

Cheers,
Alex

[1] 
https://jackrabbit.apache.org/api/2.6/org/apache/jackrabbit/api/ReferenceBinary.html

[2] sample code

public static File getDataStoreRef(Node ntFile) throws RepositoryException {
if (ntFile.hasProperty(PN_FILE_DATA)) {
Property property = ntFile.getProperty(PN_FILE_DATA);
if (property.getType() == PropertyType.BINARY) {
Binary binary = property.getBinary();
if (binary instanceof ReferenceBinary) {
String ref = ((ReferenceBinary) binary).getReference();
// oak reference is "hash:something"
ref = StringUtils.substringBefore(ref, ":");
if (ref == null) {
// This happens when asset has been created before file 
datastore option was configured
// Looks like rendition data is not being extracted for 
existing assets
return null;
}
// hash to datastore file structure - from Jackrabbit 
FileDataStore
File file = new File(ref.substring(0, 2));
file = new File(file, ref.substring(2, 4));
file = new File(file, ref.substring(4, 6));
file = new File(file, ref);
return file;
}
}
}
return null;
}

[jira] [Commented] (JCR-4015) CLONE - jackrabbit-jcr-commons JcrUtils.getOrCreateByPath fails if session is not allowed to read root

[Carsten Ziegeler (JIRA)]

[ 
https://issues.apache.org/jira/browse/JCR-4015?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15471266#comment-15471266
 ] 

Carsten Ziegeler commented on JCR-4015:
---

If the full path already exists, the method currently first tries the parent 
node, however if that one is not readable, it goes up the hierarchy. So we need 
to check the full path first. Potential patch:

{code}
Index: src/main/java/org/apache/jackrabbit/commons/JcrUtils.java
===
--- src/main/java/org/apache/jackrabbit/commons/JcrUtils.java   (Revision 
1759610)
+++ src/main/java/org/apache/jackrabbit/commons/JcrUtils.java   (Arbeitskopie)
@@ -1451,6 +1451,9 @@
 } else if (!absolutePath.startsWith("/")) {
 throw new IllegalArgumentException("not an absolute path: " + 
absolutePath);
 } else {
+if ( session.nodeExists(absolutePath) ) {
+return session.getNode(absolutePath);
+}
 // find deepest existing parent node
 String path = absolutePath;
 int currentIndex = path.lastIndexOf('/');
{code}

> CLONE - jackrabbit-jcr-commons JcrUtils.getOrCreateByPath fails if session is 
> not allowed to read root
> --
>
> Key: JCR-4015
> URL: https://issues.apache.org/jira/browse/JCR-4015
> Project: Jackrabbit Content Repository
>  Issue Type: Bug
>  Components: jackrabbit-jcr-commons
>Affects Versions: 2.4.5, 2.6.5, 2.8.1, 2.10.3, 2.12.2
>Reporter: Carsten Ziegeler
>Assignee: Julian Reschke
> Fix For: 2.13.4
>
>
> JcrUtils.getOrCreateByPath  starts to try to find the node from the root down 
> to the specified path, therefore if the current session has not access to 
> "/", it fails. JcrUtils.getOrCreateByPath must try the longest path first and 
> then reduce it until it finds an accessible node. So for example if the input 
> is "/a/b/c" instead of testing for "/", "/a", "/a/b" .. it should test 
> /a/b/c, /a/b, /a and then /



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

[jira] [Reopened] (JCR-4015) CLONE - jackrabbit-jcr-commons JcrUtils.getOrCreateByPath fails if session is not allowed to read root

[Carsten Ziegeler (JIRA)]

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

Carsten Ziegeler reopened JCR-4015:
---

Unfortunately the provided patch does not cover all use cases

> CLONE - jackrabbit-jcr-commons JcrUtils.getOrCreateByPath fails if session is 
> not allowed to read root
> --
>
> Key: JCR-4015
> URL: https://issues.apache.org/jira/browse/JCR-4015
> Project: Jackrabbit Content Repository
>  Issue Type: Bug
>  Components: jackrabbit-jcr-commons
>Affects Versions: 2.4.5, 2.6.5, 2.8.1, 2.10.3, 2.12.2
>Reporter: Carsten Ziegeler
>Assignee: Julian Reschke
> Fix For: 2.13.4
>
>
> JcrUtils.getOrCreateByPath  starts to try to find the node from the root down 
> to the specified path, therefore if the current session has not access to 
> "/", it fails. JcrUtils.getOrCreateByPath must try the longest path first and 
> then reduce it until it finds an accessible node. So for example if the input 
> is "/a/b/c" instead of testing for "/", "/a", "/a/b" .. it should test 
> /a/b/c, /a/b, /a and then /



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

[jira] [Updated] (JCR-4018) Consistent Async Upload Executor handling in Backend implementations

[Woonsan Ko (JIRA)]

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

Woonsan Ko updated JCR-4018:

Description: 
There are some inconsistent configuration/behaviors regarding asynchronous 
upload executor handling.
For example,
- {{VFSBackend}} disables async upload based on {{asyncPoolSize}} not based on 
{{CachingDataStore#asyncUploadLimit}}.
- {{FSBackend}} disables it based on {{CachingDataStore#asyncUploadLimit}} 
correctly as of JCR-4008.
- {{S3Backend}} doesn't have a feature to disable async uploading yet.

Probably it would be nicer to have {{AbstractBackend}} for all the practical 
{{Backend}} implementations to share the handling on asynchronous uploading 
features such as how to create an {{Executor}} and async executor pool size, 
etc. There are already some duplicate code regarding this in {{VFSBackend}} and 
{{FSBackend}}.

  was:
There are some inconsistent configuration/behaviors regarding asynchronous 
upload executor handling.
For example,
- {{VFSBackend}} disables async upload based on {{asyncPoolSize}} not based on 
{{CachingDataStore#asyncUploadLimit}}.
- {{FSBackend}} disables it based on {{CachingDataStore#asyncUploadLimit}} 
correctly as of JCR-4008.
- {{S3Backend}} doesn't have a feature to disable async uploading yet.

Probably it would be nicer to have {{AbstractBackend}} for all the practical 
{{Backend}} implementations to share the handling on asynchronous uploading 
features such as how to create an {{Executor}} and async executor pool size, 
etc.


> Consistent Async Upload Executor handling in Backend implementations
> 
>
> Key: JCR-4018
> URL: https://issues.apache.org/jira/browse/JCR-4018
> Project: Jackrabbit Content Repository
>  Issue Type: Improvement
>Reporter: Woonsan Ko
>Priority: Minor
>
> There are some inconsistent configuration/behaviors regarding asynchronous 
> upload executor handling.
> For example,
> - {{VFSBackend}} disables async upload based on {{asyncPoolSize}} not based 
> on {{CachingDataStore#asyncUploadLimit}}.
> - {{FSBackend}} disables it based on {{CachingDataStore#asyncUploadLimit}} 
> correctly as of JCR-4008.
> - {{S3Backend}} doesn't have a feature to disable async uploading yet.
> Probably it would be nicer to have {{AbstractBackend}} for all the practical 
> {{Backend}} implementations to share the handling on asynchronous uploading 
> features such as how to create an {{Executor}} and async executor pool size, 
> etc. There are already some duplicate code regarding this in {{VFSBackend}} 
> and {{FSBackend}}.



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

[jira] [Commented] (JCR-4008) Restore TestCachingFDS.testDeleteRecord() to fix it with disabling AsyncUpload in unit tests

[Woonsan Ko (JIRA)]

[ 
https://issues.apache.org/jira/browse/JCR-4008?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15471205#comment-15471205
 ] 

Woonsan Ko commented on JCR-4008:
-

Hi [~amitjain],

Thanks for clarification!
I've closed the old pull request and posted a new one: 
https://github.com/apache/jackrabbit/pull/42
Please take a review.
By the way, I've created another ticket for the small 'refactoring': JCR-4018. 
I'd like to post a separate PR to the ticket as soon as this issue gets 
resolved.

Kind regards,

Woonsan

> Restore TestCachingFDS.testDeleteRecord() to fix it with disabling 
> AsyncUpload in unit tests
> 
>
> Key: JCR-4008
> URL: https://issues.apache.org/jira/browse/JCR-4008
> Project: Jackrabbit Content Repository
>  Issue Type: Bug
>Affects Versions: 2.13.2
>Reporter: Woonsan Ko
> Fix For: 2.13.4
>
>
> The test used to fail occasionally before the test method was commented out 
> by JCR-4006:
> {noformat}
> junit.framework.AssertionFailedError: rec2 should be null
>   at junit.framework.Assert.fail(Assert.java:50)
>   at junit.framework.Assert.assertTrue(Assert.java:20)
>   at junit.framework.Assert.assertNull(Assert.java:237)
>   at 
> org.apache.jackrabbit.core.data.TestCaseBase.doDeleteRecordTest(TestCaseBase.java:327)
>   at 
> org.apache.jackrabbit.core.data.TestCaseBase.testDeleteRecord(TestCaseBase.java:192)
> {noformat}
> The main reason of this error is because the underlying backend uses 
> asynchronous writing threads by default, which is not working well when 
> extending {{org.apache.jackrabbit.core.data.TestCaseBase}} as mentioned in 
> JCR-4005.
> So, it seems better to fix it again like the following like how JCR-4005 was 
> fixed:
> - Restore the commented out block ({{TestCachingFDS.testDeleteRecord()}}).
> - Provide an option to disable asynchronous writing in all the related 
> backend implementations. e.g., disable it if {{asyncWritePoolSize}} is zero 
> or smaller.
> - In unit tests, simply disable async writing.



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

[jira] [Created] (JCR-4018) Consistent Async Upload Executor handling in Backend implementations

[Woonsan Ko (JIRA)]

Woonsan Ko created JCR-4018:
---

 Summary: Consistent Async Upload Executor handling in Backend 
implementations
 Key: JCR-4018
 URL: https://issues.apache.org/jira/browse/JCR-4018
 Project: Jackrabbit Content Repository
  Issue Type: Improvement
Reporter: Woonsan Ko
Priority: Minor


There are some inconsistent configuration/behaviors regarding asynchronous 
upload executor handling.
For example,
- {{VFSBackend}} disables async upload based on {{asyncPoolSize}} not based on 
{{CachingDataStore#asyncUploadLimit}}.
- {{FSBackend}} disables it based on {{CachingDataStore#asyncUploadLimit}} 
correctly as of JCR-4008.
- {{S3Backend}} doesn't have a feature to disable async uploading yet.

Probably it would be nicer to have {{AbstractBackend}} for all the practical 
{{Backend}} implementations to share the handling on asynchronous uploading 
features such as how to create an {{Executor}} and async executor pool size, 
etc.



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

[jira] [Commented] (JCR-4008) Restore TestCachingFDS.testDeleteRecord() to fix it with disabling AsyncUpload in unit tests

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/JCR-4008?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15471160#comment-15471160
 ] 

ASF GitHub Bot commented on JCR-4008:
-

GitHub user woonsan opened a pull request:

https://github.com/apache/jackrabbit/pull/42

JCR-4008: restoring #testDeleteRecord() tests by disabling async uploading.



You can merge this pull request into a Git repository by running:

$ git pull https://github.com/woonsan/jackrabbit bugfix/JCR-4008-2

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/jackrabbit/pull/42.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #42


commit 43af6b1fc1049d718df60ec0330e41b19a9c68d9
Author: Woonsan Ko 
Date:   2016-09-07T17:02:51Z

JCR-4008: restoring #testDeleteRecord() tests by disabling async uploading.




> Restore TestCachingFDS.testDeleteRecord() to fix it with disabling 
> AsyncUpload in unit tests
> 
>
> Key: JCR-4008
> URL: https://issues.apache.org/jira/browse/JCR-4008
> Project: Jackrabbit Content Repository
>  Issue Type: Bug
>Affects Versions: 2.13.2
>Reporter: Woonsan Ko
> Fix For: 2.13.4
>
>
> The test used to fail occasionally before the test method was commented out 
> by JCR-4006:
> {noformat}
> junit.framework.AssertionFailedError: rec2 should be null
>   at junit.framework.Assert.fail(Assert.java:50)
>   at junit.framework.Assert.assertTrue(Assert.java:20)
>   at junit.framework.Assert.assertNull(Assert.java:237)
>   at 
> org.apache.jackrabbit.core.data.TestCaseBase.doDeleteRecordTest(TestCaseBase.java:327)
>   at 
> org.apache.jackrabbit.core.data.TestCaseBase.testDeleteRecord(TestCaseBase.java:192)
> {noformat}
> The main reason of this error is because the underlying backend uses 
> asynchronous writing threads by default, which is not working well when 
> extending {{org.apache.jackrabbit.core.data.TestCaseBase}} as mentioned in 
> JCR-4005.
> So, it seems better to fix it again like the following like how JCR-4005 was 
> fixed:
> - Restore the commented out block ({{TestCachingFDS.testDeleteRecord()}}).
> - Provide an option to disable asynchronous writing in all the related 
> backend implementations. e.g., disable it if {{asyncWritePoolSize}} is zero 
> or smaller.
> - In unit tests, simply disable async writing.



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

[jira] [Commented] (JCR-4008) Restore TestCachingFDS.testDeleteRecord() to fix it with disabling AsyncUpload in unit tests

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/JCR-4008?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15471157#comment-15471157
 ] 

ASF GitHub Bot commented on JCR-4008:
-

Github user woonsan closed the pull request at:

https://github.com/apache/jackrabbit/pull/40


> Restore TestCachingFDS.testDeleteRecord() to fix it with disabling 
> AsyncUpload in unit tests
> 
>
> Key: JCR-4008
> URL: https://issues.apache.org/jira/browse/JCR-4008
> Project: Jackrabbit Content Repository
>  Issue Type: Bug
>Affects Versions: 2.13.2
>Reporter: Woonsan Ko
> Fix For: 2.13.4
>
>
> The test used to fail occasionally before the test method was commented out 
> by JCR-4006:
> {noformat}
> junit.framework.AssertionFailedError: rec2 should be null
>   at junit.framework.Assert.fail(Assert.java:50)
>   at junit.framework.Assert.assertTrue(Assert.java:20)
>   at junit.framework.Assert.assertNull(Assert.java:237)
>   at 
> org.apache.jackrabbit.core.data.TestCaseBase.doDeleteRecordTest(TestCaseBase.java:327)
>   at 
> org.apache.jackrabbit.core.data.TestCaseBase.testDeleteRecord(TestCaseBase.java:192)
> {noformat}
> The main reason of this error is because the underlying backend uses 
> asynchronous writing threads by default, which is not working well when 
> extending {{org.apache.jackrabbit.core.data.TestCaseBase}} as mentioned in 
> JCR-4005.
> So, it seems better to fix it again like the following like how JCR-4005 was 
> fixed:
> - Restore the commented out block ({{TestCachingFDS.testDeleteRecord()}}).
> - Provide an option to disable asynchronous writing in all the related 
> backend implementations. e.g., disable it if {{asyncWritePoolSize}} is zero 
> or smaller.
> - In unit tests, simply disable async writing.



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

[jira] [Commented] (JCR-4008) Restore TestCachingFDS.testDeleteRecord() to fix it with disabling AsyncUpload in unit tests

[Amit Jain (JIRA)]

[ 
https://issues.apache.org/jira/browse/JCR-4008?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15470998#comment-15470998
 ] 

Amit Jain commented on JCR-4008:


Hi [~woon_san] Yes lets track that change with a new issue.

> Restore TestCachingFDS.testDeleteRecord() to fix it with disabling 
> AsyncUpload in unit tests
> 
>
> Key: JCR-4008
> URL: https://issues.apache.org/jira/browse/JCR-4008
> Project: Jackrabbit Content Repository
>  Issue Type: Bug
>Affects Versions: 2.13.2
>Reporter: Woonsan Ko
> Fix For: 2.13.4
>
>
> The test used to fail occasionally before the test method was commented out 
> by JCR-4006:
> {noformat}
> junit.framework.AssertionFailedError: rec2 should be null
>   at junit.framework.Assert.fail(Assert.java:50)
>   at junit.framework.Assert.assertTrue(Assert.java:20)
>   at junit.framework.Assert.assertNull(Assert.java:237)
>   at 
> org.apache.jackrabbit.core.data.TestCaseBase.doDeleteRecordTest(TestCaseBase.java:327)
>   at 
> org.apache.jackrabbit.core.data.TestCaseBase.testDeleteRecord(TestCaseBase.java:192)
> {noformat}
> The main reason of this error is because the underlying backend uses 
> asynchronous writing threads by default, which is not working well when 
> extending {{org.apache.jackrabbit.core.data.TestCaseBase}} as mentioned in 
> JCR-4005.
> So, it seems better to fix it again like the following like how JCR-4005 was 
> fixed:
> - Restore the commented out block ({{TestCachingFDS.testDeleteRecord()}}).
> - Provide an option to disable asynchronous writing in all the related 
> backend implementations. e.g., disable it if {{asyncWritePoolSize}} is zero 
> or smaller.
> - In unit tests, simply disable async writing.



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

extensions to JackrabbitEventFilter

[Stefan Egli]

Hi,

I'd like to discuss two extensions to JackrabbitEventFilter that would allow
optimizations on observation handling eg in Oak:

* JCR-4016 : extend path and property filtering of observation event
* JCR-4017 : add ignoresInfo flag to JackrabbitEventFilter

Please provide feedback in the tickets, thx!

Cheers,
Stefan
--
https://issues.apache.org/jira/browse/JCR-4016
https://issues.apache.org/jira/browse/JCR-4017

[jira] [Created] (JCR-4017) add ignoresInfo flag to JackrabbitEventFilter

[Stefan Egli (JIRA)]

Stefan Egli created JCR-4017:


 Summary: add ignoresInfo flag to JackrabbitEventFilter
 Key: JCR-4017
 URL: https://issues.apache.org/jira/browse/JCR-4017
 Project: Jackrabbit Content Repository
  Issue Type: Improvement
  Components: observation
Affects Versions: 2.13.3
Reporter: Stefan Egli


Some EventListeners aren't really interested in the info {{Map}} the 
{{onEvent}} ie {{Event}} comes with. However, maintaining that {{Map}} can be 
costly. It would be more efficient if listeners could express that they're not 
at all interested in this map and that Jackrabbit/Oak can filter it.

Suggestion is therefore to extend JackrabbitEventFilter with:
{code}
boolean ignoresEventInfo;
{code}



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

[jira] [Created] (JCR-4016) extend path and property filtering of observation event

[Stefan Egli (JIRA)]

Stefan Egli created JCR-4016:


 Summary: extend path and property filtering of observation event
 Key: JCR-4016
 URL: https://issues.apache.org/jira/browse/JCR-4016
 Project: Jackrabbit Content Repository
  Issue Type: Improvement
  Components: observation
Affects Versions: 2.13.3
Reporter: Stefan Egli


The current {{JackrabbitEventFilter}} allows to specify a number of paths, a 
number of exclude paths and a flag isDeep indicating if it wants to dive into 
those registered paths. While this provides some degree of filtering already, 
it might be more efficient to allow for even more fine grained filtering 
additionally.

This ticket is to suggest introducing a filter along the lines of the following:
{code}
public interface Filter {

enum FilterResult {
INCLUDE, INCLUDE_SKIP_CHILDREN,
EXCLUDE, EXCLUDE_SKIP_CHILDREN };

FilterResult filter(String nodeOrPropertyPath);
}
{code}



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

[jira] [Commented] (JCR-4015) CLONE - jackrabbit-jcr-commons JcrUtils.getOrCreateByPath fails if session is not allowed to read root

[Julian Reschke (JIRA)]

[ 
https://issues.apache.org/jira/browse/JCR-4015?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15470565#comment-15470565
 ] 

Julian Reschke commented on JCR-4015:
-

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

> CLONE - jackrabbit-jcr-commons JcrUtils.getOrCreateByPath fails if session is 
> not allowed to read root
> --
>
> Key: JCR-4015
> URL: https://issues.apache.org/jira/browse/JCR-4015
> Project: Jackrabbit Content Repository
>  Issue Type: Bug
>  Components: jackrabbit-jcr-commons
>Affects Versions: 2.4.5, 2.6.5, 2.8.1, 2.10.3, 2.12.2
>Reporter: Carsten Ziegeler
>Assignee: Julian Reschke
> Fix For: 2.13.4
>
>
> JcrUtils.getOrCreateByPath  starts to try to find the node from the root down 
> to the specified path, therefore if the current session has not access to 
> "/", it fails. JcrUtils.getOrCreateByPath must try the longest path first and 
> then reduce it until it finds an accessible node. So for example if the input 
> is "/a/b/c" instead of testing for "/", "/a", "/a/b" .. it should test 
> /a/b/c, /a/b, /a and then /



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

Re: Seekable access to a Binary

[Julian Reschke]

On 2016-09-07 11:06, Michael Marth wrote:

Hi,

I believe Oak has no notion of requests - the 1-1 binding of a request to a 
session is done in Sling.
However, having said that: I was not aware of all the complexities you mention. 
To add one more: probably the design would have to encounter for different 
clustered Sling instances (that share 1 repository) that receive chunks 
belonging to the same binary. Is that right?

Afaik branches are not exposed into userland, but are an implementation detail. 
 When I made my comment below, I did not realize that in order for this to work 
branches would have exposed. I am not sure if that's a good idea. Also not sure 
if it would even solve the problem.
Maybe a better approach could be to persist the chunks in a temp space, similar 
to what Marcel suggested. But maybe that temp space could be a functionality of 
the datastore (I believe Marcel suggested to create a temp location by the user 
itself via the JCR API)

Michael

Sent from a mobile device



Maybe we could have a Oak specific InputStream implementation that wraps 
a series of existing Binary implementations, and which Oak, when writing 
a new binary, could leverage? (by not actually reading the binaries, but 
just copying references around...)


Best regards, Julian

[jira] [Assigned] (JCR-4015) CLONE - jackrabbit-jcr-commons JcrUtils.getOrCreateByPath fails if session is not allowed to read root

[Julian Reschke (JIRA)]

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

Julian Reschke reassigned JCR-4015:
---

Assignee: Julian Reschke

> CLONE - jackrabbit-jcr-commons JcrUtils.getOrCreateByPath fails if session is 
> not allowed to read root
> --
>
> Key: JCR-4015
> URL: https://issues.apache.org/jira/browse/JCR-4015
> Project: Jackrabbit Content Repository
>  Issue Type: Bug
>  Components: jackrabbit-jcr-commons
>Affects Versions: 2.4.5, 2.6.5, 2.8.1, 2.10.3, 2.12.2
>Reporter: Carsten Ziegeler
>Assignee: Julian Reschke
>
> JcrUtils.getOrCreateByPath  starts to try to find the node from the root down 
> to the specified path, therefore if the current session has not access to 
> "/", it fails. JcrUtils.getOrCreateByPath must try the longest path first and 
> then reduce it until it finds an accessible node. So for example if the input 
> is "/a/b/c" instead of testing for "/", "/a", "/a/b" .. it should test 
> /a/b/c, /a/b, /a and then /



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

Re: [VOTE] Release Apache Jackrabbit 2.13.3

[Julian Reschke]

On 2016-09-07 09:31, Marcel Reutegger wrote:

...


[X] +1 Release this package as Apache Jackrabbit 2.13.3

Best regards, Julian

Re: Seekable access to a Binary

[Michael Marth]

Hi,

I believe Oak has no notion of requests - the 1-1 binding of a request to a 
session is done in Sling.
However, having said that: I was not aware of all the complexities you mention. 
To add one more: probably the design would have to encounter for different 
clustered Sling instances (that share 1 repository) that receive chunks 
belonging to the same binary. Is that right?

Afaik branches are not exposed into userland, but are an implementation detail. 
 When I made my comment below, I did not realize that in order for this to work 
branches would have exposed. I am not sure if that's a good idea. Also not sure 
if it would even solve the problem.
Maybe a better approach could be to persist the chunks in a temp space, similar 
to what Marcel suggested. But maybe that temp space could be a functionality of 
the datastore (I believe Marcel suggested to create a temp location by the user 
itself via the JCR API)

Michael

Sent from a mobile device

_
From: Ian Boston >
Sent: Wednesday, September 7, 2016 9:36 AM
Subject: Re: Seekable access to a Binary
To: >


Hi,

On 6 September 2016 at 18:00, Michael Marth 
> wrote:

> Hi,
>
> I think it would be neat if we could utilize our existing mechanism rather
> than a new flag. In particular, MVCC and branches for session isolation.
> And also simply use session.save() to indicate that an upload is complete
> (and the branch containing the binaries/chunks can be merged).
>

Do branches and sessions hang around between requests ?

Each body part will come from different requests, sometimes separated by
hours and possibly even from different source IP addresses, especially
under upload restart conditions. At present, in streaming mode, as each
body part is encountered a session.save is performed to cause JCR/Oak to
read that input stream from the request, since JCR does not expose anything
that can be used to write binary data to the repository.

Best Regards
Ian



>
> Michael
>
> Sent from a mobile device
>
>
>
>
> On Tue, Sep 6, 2016 at 1:15 PM +0200, "Marcel Reutegger" <
> mreut...@adobe.com> 
> wrote:
>
> Hi,
>
> On 06/09/16 12:34, Bertrand Delacretaz wrote:
> > On Tue, Sep 6, 2016 at 9:49 AM, Marcel Reutegger 
> > >
> wrote:
> >> ...we'd still have to add
> >> Jackrabbit API to support it. E.g. something like:
> >>
> >> valueFactory.createBinary(existingBinary, appendThisInputStream); ...
> >
> > And maybe a way to mark the binary as "in progress" to avoid
> > applications using half-uploaded binaries?
>
> This can easily be prevented if the 'in progress' binary is
> uploaded to a temporary location first and then copied over
> to the correct location once complete. Keep in mind that
> copying a large existing binary in Oak is simply a cheap
> copy of the reference.
>
> Regards
> Marcel
>

[VOTE] Release Apache Jackrabbit 2.13.3

[Marcel Reutegger]

A candidate for the Jackrabbit 2.13.3 release is available at:

https://dist.apache.org/repos/dist/dev/jackrabbit/2.13.3/

The release candidate is a zip archive of the sources in:

https://svn.apache.org/repos/asf/jackrabbit/tags/jackrabbit-2.13.3/

The SHA1 checksum of the archive is 
1fabc1d1db4aef2db7081507e96e18074ed83991.


A staged Maven repository is available for review at:

https://repository.apache.org/

The command for running automated checks against this release candidate is:

$ sh check-release.sh 2.13.3 1fabc1d1db4aef2db7081507e96e18074ed83991

Please vote on releasing this package as Apache Jackrabbit 2.13.3.
The vote is open for the next 72 hours and passes if a majority of at
least three +1 Jackrabbit PMC votes are cast.

[ ] +1 Release this package as Apache Jackrabbit 2.13.3
[ ] -1 Do not release this package because...

Regards
 Marcel