[jira] [Created] (OAK-4933) Create a data store implementation that integrates with Microsoft Azure Blob Storage
Matt Ryan created OAK-4933: -- Summary: Create a data store implementation that integrates with Microsoft Azure Blob Storage Key: OAK-4933 URL: https://issues.apache.org/jira/browse/OAK-4933 Project: Jackrabbit Oak Issue Type: Epic Components: blob, core Reporter: Matt Ryan This epic proposes the creation of a new type of Oak data store, AzureDataStore, that offers an integration between Oak and Microsoft Azure Blob Storage. AzureDataStore would be very similar in purpose and functionality to S3DataStore, with a different backend that uses Azure Blob Storage instead of S3. Some initial exploration into this concept can be seen in my github here: https://github.com/mattvryan/jackrabbit-oak/tree/azure-blob-store More info about Azure Blob Storage: * [Java SDK|https://azure.microsoft.com/en-us/documentation/articles/storage-java-how-to-use-blob-storage/] * [Javadoc|http://azure.github.io/azure-storage-java/] * [Source|https://github.com/azure/azure-storage-java] (GitHub) - Microsoft's Azure Storage Java SDK is open source and Apache licensed * [Package info|https://mvnrepository.com/artifact/com.microsoft.azure/azure-storage] on mvnrepository.com As I see it, the following work would be required: * Create an AzureDataStore class that extends CachingDataStore * Create a new backend for Azure Blob Storage * Comprehensive unit testing of the new data store and backend classes * Create test "mocks" for the necessary Azure Storage classes to facilitate unit testing (they are all final classes and cannot be mocked directly) * Create SharedAzureDataStore class * Create AzureDataStoreService class * Implement similar JMX metrics as exist for S3DataStore * Combine and refactor existing Oak code with newly added code to make best reuse of existing code, etc. * Integration testing with system configured with AzureDataStore, comparison w/ S3DataStore in terms of performance and correctness * Modify Azure Storage SDK code to make it into a valid OSGi bundle, and submit these changes back to that project (currently it is not an OSGi bundle and therefore currently has to be embedded) List isn't purported to be comprehensive of course. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (OAK-4932) DefaultSyncContext.sync(String) could use idp.getIdentity(ExternalIdentityRef)
[
https://issues.apache.org/jira/browse/OAK-4932?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexander Klimetschek updated OAK-4932:
---
Description:
Instead of
[idp.getGroup(id)|https://github.com/apache/jackrabbit-oak/blob/08aadf19a5e6b1bb4ca6687623e06140fb1ec5bc/oak-auth-external/src/main/java/org/apache/jackrabbit/oak/spi/security/authentication/external/basic/DefaultSyncContext.java#L291]
and
[idp.getUser(id)|https://github.com/apache/jackrabbit-oak/blob/08aadf19a5e6b1bb4ca6687623e06140fb1ec5bc/oak-auth-external/src/main/java/org/apache/jackrabbit/oak/spi/security/authentication/external/basic/DefaultSyncContext.java#L300],
the implementation of the DefaultSyncHandler could use
{{ExternalIdentityProvider.getIdentity(ExternalIdentityRef)}}, as it looks up
the reference right before (based on the {{rep:externalId}}) and fails if not
present.
h4. Reasoning
Implementing {{getUser/Group(id)}} in an ExternalIdentityProvider can be
difficult, because you need a way to search the external identity system
efficiently by the local user id, which might not always be the case, if the
external system uses another id and is only optimized for that.
h4. Consequences
# The only other place using {{ExternalIdentityProvider.getUser(String)}} is
the
[ExternalLoginModule|https://github.com/apache/jackrabbit-oak/blob/52f1e9a84324135e6a79678bbf209d03c0d2d77d/oak-auth-external/src/main/java/org/apache/jackrabbit/oak/spi/security/authentication/external/impl/ExternalLoginModule.java#L217],
in case the user is pre-authenticated and does not exist locally yet. However,
this is a specific use case that might not apply to all identity providers, in
which case they could happily skip implementing this method. A note in the
javadoc could clarify this for implementors.
# {{ExternalIdentityProvider.getGroup(String)}} would then be used in no other
place (in the sync code) and could even be deprecated, as I can't imagine
another application specific use case for it.
was:
Instead of
[idp.getGroup(id)|https://github.com/apache/jackrabbit-oak/blob/08aadf19a5e6b1bb4ca6687623e06140fb1ec5bc/oak-auth-external/src/main/java/org/apache/jackrabbit/oak/spi/security/authentication/external/basic/DefaultSyncContext.java#L291]
and
[idp.getUser(id)|https://github.com/apache/jackrabbit-oak/blob/08aadf19a5e6b1bb4ca6687623e06140fb1ec5bc/oak-auth-external/src/main/java/org/apache/jackrabbit/oak/spi/security/authentication/external/basic/DefaultSyncContext.java#L300],
the implementation of the DefaultSyncHandler could use
{{ExternalIdentityProvider.getIdentity(ExternalIdentityRef)}}, as it looks up
the reference right before (based on the {{rep:externalId}}) and fails if not
present.
h4. Reasoning
Implementing {{getUser/Group(id)}} in an ExternalIdentityProvider can be
difficult, because you need a way to search the external identity system
efficiently by the local user id, which might not always be the case, if the
external system uses another id and is only optimized for that.
h4. Consequences
# The only other place using {{ExternalIdentityProvider.getUser(String)}} is
the
[ExternalLoginModule|https://github.com/apache/jackrabbit-oak/blob/52f1e9a84324135e6a79678bbf209d03c0d2d77d/oak-auth-external/src/main/java/org/apache/jackrabbit/oak/spi/security/authentication/external/impl/ExternalLoginModule.java#L217],
in case the user is pre-authenticated and does not exist locally yet. However,
this is a specific use case that might not apply to all identity providers, in
which case they could happily skip implementing this method. A note in the
javadoc could clarify this for implementors.
# {{ExternalIdentityProvider.getGroup(String)}} would then be use in no other
place (in the sync code) and could even be deprecated, as I can't imagine
another application specific use case for it.
> DefaultSyncContext.sync(String) could use idp.getIdentity(ExternalIdentityRef)
> --
>
> Key: OAK-4932
> URL: https://issues.apache.org/jira/browse/OAK-4932
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: auth-external
>Reporter: Alexander Klimetschek
>
> Instead of
> [idp.getGroup(id)|https://github.com/apache/jackrabbit-oak/blob/08aadf19a5e6b1bb4ca6687623e06140fb1ec5bc/oak-auth-external/src/main/java/org/apache/jackrabbit/oak/spi/security/authentication/external/basic/DefaultSyncContext.java#L291]
> and
> [idp.getUser(id)|https://github.com/apache/jackrabbit-oak/blob/08aadf19a5e6b1bb4ca6687623e06140fb1ec5bc/oak-auth-external/src/main/java/org/apache/jackrabbit/oak/spi/security/authentication/external/basic/DefaultSyncContext.java#L300],
> the implementation of the DefaultSyncHandler could use
> {{ExternalIdentityProvider.getIdentity(ExternalIdentityRef)}}, as it looks up
> the
[jira] [Commented] (OAK-4932) DefaultSyncContext.sync(String) could use idp.getIdentity(ExternalIdentityRef)
[
https://issues.apache.org/jira/browse/OAK-4932?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15569669#comment-15569669
]
Alexander Klimetschek commented on OAK-4932:
/cc [~tripod] [~djaeggi] [~anchela]
> DefaultSyncContext.sync(String) could use idp.getIdentity(ExternalIdentityRef)
> --
>
> Key: OAK-4932
> URL: https://issues.apache.org/jira/browse/OAK-4932
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: auth-external
>Reporter: Alexander Klimetschek
>
> Instead of
> [idp.getGroup(id)|https://github.com/apache/jackrabbit-oak/blob/08aadf19a5e6b1bb4ca6687623e06140fb1ec5bc/oak-auth-external/src/main/java/org/apache/jackrabbit/oak/spi/security/authentication/external/basic/DefaultSyncContext.java#L291]
> and
> [idp.getUser(id)|https://github.com/apache/jackrabbit-oak/blob/08aadf19a5e6b1bb4ca6687623e06140fb1ec5bc/oak-auth-external/src/main/java/org/apache/jackrabbit/oak/spi/security/authentication/external/basic/DefaultSyncContext.java#L300],
> the implementation of the DefaultSyncHandler could use
> {{ExternalIdentityProvider.getIdentity(ExternalIdentityRef)}}, as it looks up
> the reference right before (based on the {{rep:externalId}}) and fails if not
> present.
> h4. Reasoning
> Implementing {{getUser/Group(id)}} in an ExternalIdentityProvider can be
> difficult, because you need a way to search the external identity system
> efficiently by the local user id, which might not always be the case, if the
> external system uses another id and is only optimized for that.
> h4. Consequences
> # The only other place using {{ExternalIdentityProvider.getUser(String)}} is
> the
> [ExternalLoginModule|https://github.com/apache/jackrabbit-oak/blob/52f1e9a84324135e6a79678bbf209d03c0d2d77d/oak-auth-external/src/main/java/org/apache/jackrabbit/oak/spi/security/authentication/external/impl/ExternalLoginModule.java#L217],
> in case the user is pre-authenticated and does not exist locally yet.
> However, this is a specific use case that might not apply to all identity
> providers, in which case they could happily skip implementing this method. A
> note in the javadoc could clarify this for implementors.
> # {{ExternalIdentityProvider.getGroup(String)}} would then be use in no other
> place (in the sync code) and could even be deprecated, as I can't imagine
> another application specific use case for it.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (OAK-4932) DefaultSyncContext.sync(String) could use idp.getIdentity(ExternalIdentityRef)
Alexander Klimetschek created OAK-4932:
--
Summary: DefaultSyncContext.sync(String) could use
idp.getIdentity(ExternalIdentityRef)
Key: OAK-4932
URL: https://issues.apache.org/jira/browse/OAK-4932
Project: Jackrabbit Oak
Issue Type: Improvement
Components: auth-external
Reporter: Alexander Klimetschek
Instead of
[idp.getGroup(id)|https://github.com/apache/jackrabbit-oak/blob/08aadf19a5e6b1bb4ca6687623e06140fb1ec5bc/oak-auth-external/src/main/java/org/apache/jackrabbit/oak/spi/security/authentication/external/basic/DefaultSyncContext.java#L291]
and
[idp.getUser(id)|https://github.com/apache/jackrabbit-oak/blob/08aadf19a5e6b1bb4ca6687623e06140fb1ec5bc/oak-auth-external/src/main/java/org/apache/jackrabbit/oak/spi/security/authentication/external/basic/DefaultSyncContext.java#L300],
the implementation of the DefaultSyncHandler could use
{{ExternalIdentityProvider.getIdentity(ExternalIdentityRef)}}, as it looks up
the reference right before (based on the {{rep:externalId}}) and fails if not
present.
h4. Reasoning
Implementing {{getUser/Group(id)}} in an ExternalIdentityProvider can be
difficult, because you need a way to search the external identity system
efficiently by the local user id, which might not always be the case, if the
external system uses another id and is only optimized for that.
h4. Consequences
# The only other place using {{ExternalIdentityProvider.getUser(String)}} is
the
[ExternalLoginModule|https://github.com/apache/jackrabbit-oak/blob/52f1e9a84324135e6a79678bbf209d03c0d2d77d/oak-auth-external/src/main/java/org/apache/jackrabbit/oak/spi/security/authentication/external/impl/ExternalLoginModule.java#L217],
in case the user is pre-authenticated and does not exist locally yet. However,
this is a specific use case that might not apply to all identity providers, in
which case they could happily skip implementing this method. A note in the
javadoc could clarify this for implementors.
# {{ExternalIdentityProvider.getGroup(String)}} would then be use in no other
place (in the sync code) and could even be deprecated, as I can't imagine
another application specific use case for it.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (OAK-4911) Can not read node Property when move code into a Thread (Java)
[
https://issues.apache.org/jira/browse/OAK-4911?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15569500#comment-15569500
]
amin zamani edited comment on OAK-4911 at 10/12/16 6:36 PM:
I have now modified the structure of the code:
Now in ONE THREAD A NEW FILE NODE is created but when I try to access the
property IN THE SAME THREAD I still get the same error. I access in the same
java thread where I have created the file the properties of the node that I
just have created before in the same thread. Here the example:
New thread created with following content, it calls only the
createDocument(...) method and then I get the exception - without a thread i
don't have the exception:
public Document createDocument(String folderId, CreateDocumentDto createDto) {
try {
Node node = jcrSession.getNodeByIdentifier(folderId);
Binary binary =
jcrSession.getValueFactory().createBinary(createDto.getContent());
try {
Node file = JcrUtils.getOrCreateByPath(
node,
"",
DO_CREATE_UNIQUE_LEAF,
NodeType.NT_FOLDER,
NodeType.NT_FILE,
DO_AUTO_SAVE);
file.addMixin(NodeType.MIX_VERSIONABLE);
file.addMixin(NodeType.MIX_TITLE);
file.setProperty(Property.JCR_TITLE, createDto.getTitle());
file.setProperty(Property.JCR_DESCRIPTION,
createDto.getDescription());
file.addMixin(CustomNodeType.NOAH_ENTITY_DOCUMENT);
if (createDto.getDocumentType() != null) {
file.setProperty(CustomProperty.NOAH_DOCUMENT_TYPE_VALUE,
createDto.getDocumentType().getValue());
file.setProperty(CustomProperty.NOAH_DOCUMENT_TYPE_LABEL,
createDto.getDocumentType().getLabel());
}
file.setProperty(CustomProperty.NOAH_ENTITY_URL,
createDto.getEntityUrl());
file.addMixin(CustomNodeType.NOAH_AUDITABLE);
file.setProperty(CustomProperty.NOAH_CREATED_BY,
SecurityUtil.getCurrentUserLogin());
Node content = JcrUtils.getOrAddNode(file, Node.JCR_CONTENT,
NodeType.NT_RESOURCE);
content.setProperty(Property.JCR_DATA, binary);
content.setProperty(Property.JCR_MIMETYPE,
createDto.getContentType());
String previewFileType="";
if(createDto.getPreviewType() != null){
// Ok, we are creating a preview document, so add the
preview type
file.addMixin(CustomNodeType.NOAH_PREVIEW_DOCUMENT);
System.out.println("Create preview document, set preview
type:"+createDto.getPreviewType().name());
file.setProperty(CustomProperty.NOAH_PREVIEW_TYPE,
createDto.getPreviewType().name());
previewFileType = createDto.getPreviewType().name();
}
jcrSession.refresh(true);
jcrSession.save();
jcrSession.refresh(true);
System.out.println("Created "+previewFileType+" document,id:
"+file.getIdentifier()+" ("+createDto.getTitle()+"),path: "+file.getPath());
LOG.debug("Created "+previewFileType+" document,id:
"+file.getIdentifier()+" ("+createDto.getTitle()+"),path: "+file.getPath());
Version versionNode = versionFile(file, binary);
jcrSession.refresh(true);
return toDocument(versionNode);
} finally {
binary.dispose();
}
} catch (RepositoryException e) {
throw new RuntimeRepositoryException(e);
}
}
was (Author: amin.zam...@westernacher.com):
I have now modified the structure of the code:
Now in a thread a new file node is created but when I try to access the
property I still get the same error. I access in the same java thread where I
have created the file the properties of the node that I just have created
before. Here a little exampe:
new thread created with following content, it calls only the
createDocument(...) method and then I get the exception - without a thread i
don't have the exception:
public Document createDocument(String folderId, CreateDocumentDto createDto) {
try {
Node node = jcrSession.getNodeByIdentifier(folderId);
Binary binary =
jcrSession.getValueFactory().createBinary(createDto.getContent());
try {
Node file = JcrUtils.getOrCreateByPath(
node,
"",
DO_CREATE_UNIQUE_LEAF,
NodeType.NT_FOLDER,
[jira] [Commented] (OAK-4911) Can not read node Property when move code into a Thread (Java)
[
https://issues.apache.org/jira/browse/OAK-4911?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15569516#comment-15569516
]
amin zamani commented on OAK-4911:
--
And then we get this error if above method is called :
Caused by: javax.jcr.PathNotFoundException: noah:createdBy not found on
/jcr:system/jcr:versionStorage/d2/88/43/d28843a2-c666-4936-b08b-e53912da4ecf/1.0/jcr:frozenNode
> Can not read node Property when move code into a Thread (Java)
> --
>
> Key: OAK-4911
> URL: https://issues.apache.org/jira/browse/OAK-4911
> Project: Jackrabbit Oak
> Issue Type: Bug
>Affects Versions: 1.3.10
> Environment: MAC OS X
>Reporter: amin zamani
> Attachments: java-code.txt
>
>
> Hallo,
> we develop an application and everything is working as it should. We upload
> documents and for each document a new preview file (node) should be
> generated. It works well when we execute the code synchron. But because of
> the fact that the generation of a preview file (like PDF format) can take
> very long time we decided to move the preview generation code into a usual
> java thread so that after the user is upload a document the website is
> responding very quick and does not wait till the preview file is generated
> but the preview file is generated parallel.
> No the problem: As soon as I move the same code regarding to the preview file
> generation into a usual thread (no modifications to the logic, only a thread
> is bordered to it) suddenly the node path does not exist, this is the error:
> -
> Caused by: javax.jcr.PathNotFoundException: jcr:lastModifiedBy not found on
> /jcr:system/jcr:versionStorage/7e/f8/5b/7ef85b25-4598-4476-82df-446eb3a08a90/1.0/jcr:frozenNode/jcr:content
> at
> org.apache.jackrabbit.oak.jcr.session.NodeImpl$11.perform(NodeImpl.java:631)
> at
> org.apache.jackrabbit.oak.jcr.session.NodeImpl$11.perform(NodeImpl.java:625)
> at
> org.apache.jackrabbit.oak.jcr.delegate.SessionDelegate.perform(SessionDelegate.java:207)
> at
> org.apache.jackrabbit.oak.jcr.session.ItemImpl.perform(ItemImpl.java:112)
> at
> org.apache.jackrabbit.oak.jcr.session.NodeImpl.getProperty(NodeImpl.java:625)
> at
> com.westernacher.noah.util.content_repository.JcrUtil.getStringProperty(JcrUtil.java:35)
> ---
> In my point of view this is a bug. This is the code that works:
> Example:
> /// 1) User Upload document through browser in our web app..
> // 2) ... document uploaded and saved in OAK CR
> // 3) Now generate the preview:
> updateDocumentPreview(documentId);
>
> Now the same in a thread that does not work:
> => I have only moved the method "updateDocumentPreview(documentId);" in a
> Thread (Java 8):
> //Same code as before except the last line replaced by following lines:
> Runnable run = ()-> {updateDocumentPreview(documentId);}
> new Thread(run).start(); //Start the thread to generate a document preview
> --
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (OAK-4911) Can not read node Property when move code into a Thread (Java)
[
https://issues.apache.org/jira/browse/OAK-4911?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15569513#comment-15569513
]
amin zamani commented on OAK-4911:
--
and then the last method which is called inside of createDocument(..) is
toDocument(versionNode)
=> In this method the exception is thrown:
private Document toDocument(Node documentNode) {
try {
Node file = null;
String identifier = null;
// flag to show if current node is already versioned
boolean isVersioned = true;
if( documentNode instanceof Version ){ //Versioned node
file = documentNode.getNode(Node.JCR_FROZEN_NODE);
identifier = JcrUtil.getStringProperty(file,
Property.JCR_FROZEN_UUID);
}else{ //unversioned node
file = documentNode;
isVersioned = false;
identifier = documentNode.getIdentifier();
}
Node fileContent = file.getNode(Property.JCR_CONTENT);
String versionName = documentNode.getName();
ZonedDateTime creationDate =
DateUtil.toZonedDateTime(file.getProperty(Property.JCR_CREATED).getDate());
ZonedDateTime lastModificationDate =
DateUtil.toZonedDateTime(JcrUtils.getLastModified(fileContent));
String createdBy = JcrUtil.getStringProperty(file,
CustomProperty.NOAH_CREATED_BY);
String lastModifiedBy = JcrUtil.getStringProperty(fileContent,
Property.JCR_LAST_MODIFIED_BY);
String title = JcrUtils.getStringProperty(file, Property.JCR_TITLE,
null);
String description = JcrUtils.getStringProperty(file,
Property.JCR_DESCRIPTION, null);
String entityUrl = JcrUtil.getStringProperty(file,
CustomProperty.NOAH_ENTITY_URL);
String documentTypeValue = JcrUtils.getStringProperty(file,
CustomProperty.NOAH_DOCUMENT_TYPE_VALUE, null);
String documentTypeLabel = JcrUtils.getStringProperty(file,
CustomProperty.NOAH_DOCUMENT_TYPE_LABEL, null);
ValueListEntry documentType = isNoneEmpty(documentTypeValue,
documentTypeLabel) ? new ValueListEntry(documentTypeValue, documentTypeLabel) :
null;
String contentType = JcrUtil.getStringProperty(fileContent,
Property.JCR_MIMETYPE);
long fileSize =
fileContent.getProperty(Property.JCR_DATA).getLength();
String previewType = JcrUtils.getStringProperty(file,
CustomProperty.NOAH_PREVIEW_TYPE, null);
return new Document(identifier,previewType, versionName,
creationDate, lastModificationDate, createdBy, lastModifiedBy, title,
description, entityUrl, documentType, contentType, fileSize);
} catch (RepositoryException e) {
throw new RuntimeRepositoryException(e);
}
}
> Can not read node Property when move code into a Thread (Java)
> --
>
> Key: OAK-4911
> URL: https://issues.apache.org/jira/browse/OAK-4911
> Project: Jackrabbit Oak
> Issue Type: Bug
>Affects Versions: 1.3.10
> Environment: MAC OS X
>Reporter: amin zamani
> Attachments: java-code.txt
>
>
> Hallo,
> we develop an application and everything is working as it should. We upload
> documents and for each document a new preview file (node) should be
> generated. It works well when we execute the code synchron. But because of
> the fact that the generation of a preview file (like PDF format) can take
> very long time we decided to move the preview generation code into a usual
> java thread so that after the user is upload a document the website is
> responding very quick and does not wait till the preview file is generated
> but the preview file is generated parallel.
> No the problem: As soon as I move the same code regarding to the preview file
> generation into a usual thread (no modifications to the logic, only a thread
> is bordered to it) suddenly the node path does not exist, this is the error:
> -
> Caused by: javax.jcr.PathNotFoundException: jcr:lastModifiedBy not found on
> /jcr:system/jcr:versionStorage/7e/f8/5b/7ef85b25-4598-4476-82df-446eb3a08a90/1.0/jcr:frozenNode/jcr:content
> at
> org.apache.jackrabbit.oak.jcr.session.NodeImpl$11.perform(NodeImpl.java:631)
> at
> org.apache.jackrabbit.oak.jcr.session.NodeImpl$11.perform(NodeImpl.java:625)
> at
> org.apache.jackrabbit.oak.jcr.delegate.SessionDelegate.perform(SessionDelegate.java:207)
> at
> org.apache.jackrabbit.oak.jcr.session.ItemImpl.perform(ItemImpl.java:112)
> at
> org.apache.jackrabbit.oak.jcr.session.NodeImpl.getProperty(NodeImpl.java:625)
> at
> com.westernacher.noah.util.content_repository.JcrUtil.getStringProperty(JcrUtil.java:35)
> ---
> In my point of view this is a bug. This is the
[jira] [Commented] (OAK-4911) Can not read node Property when move code into a Thread (Java)
[
https://issues.apache.org/jira/browse/OAK-4911?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15569505#comment-15569505
]
amin zamani commented on OAK-4911:
--
Inside above createDocument at the end the document which was created is
versioned, the above called "versionFile" method for versioning the document
has this implementation:
private Version versionFile(Node file, Binary fileContent) {
try {
VersionManager versionManager =
file.getSession().getWorkspace().getVersionManager();
versionManager.checkout(file.getPath());
file.getNode(Property.JCR_CONTENT).setProperty(Property.JCR_LAST_MODIFIED,
Calendar.getInstance());
file.getNode(Property.JCR_CONTENT).setProperty(Property.JCR_LAST_MODIFIED_BY,
SecurityUtil.getCurrentUserLogin());
file.getNode(Property.JCR_CONTENT).setProperty(Property.JCR_DATA,
fileContent);
jcrSession.save();
Version version = versionManager.checkin(file.getPath());
versionManager.getVersionHistory(file.getPath()).addVersionLabel(version.getName(),
NOAH_LAST_VERSION_LABEL, DO_MOVE_LABEL);
return version;
} catch (RepositoryException e) {
throw new RuntimeRepositoryException(e);
}
}
> Can not read node Property when move code into a Thread (Java)
> --
>
> Key: OAK-4911
> URL: https://issues.apache.org/jira/browse/OAK-4911
> Project: Jackrabbit Oak
> Issue Type: Bug
>Affects Versions: 1.3.10
> Environment: MAC OS X
>Reporter: amin zamani
> Attachments: java-code.txt
>
>
> Hallo,
> we develop an application and everything is working as it should. We upload
> documents and for each document a new preview file (node) should be
> generated. It works well when we execute the code synchron. But because of
> the fact that the generation of a preview file (like PDF format) can take
> very long time we decided to move the preview generation code into a usual
> java thread so that after the user is upload a document the website is
> responding very quick and does not wait till the preview file is generated
> but the preview file is generated parallel.
> No the problem: As soon as I move the same code regarding to the preview file
> generation into a usual thread (no modifications to the logic, only a thread
> is bordered to it) suddenly the node path does not exist, this is the error:
> -
> Caused by: javax.jcr.PathNotFoundException: jcr:lastModifiedBy not found on
> /jcr:system/jcr:versionStorage/7e/f8/5b/7ef85b25-4598-4476-82df-446eb3a08a90/1.0/jcr:frozenNode/jcr:content
> at
> org.apache.jackrabbit.oak.jcr.session.NodeImpl$11.perform(NodeImpl.java:631)
> at
> org.apache.jackrabbit.oak.jcr.session.NodeImpl$11.perform(NodeImpl.java:625)
> at
> org.apache.jackrabbit.oak.jcr.delegate.SessionDelegate.perform(SessionDelegate.java:207)
> at
> org.apache.jackrabbit.oak.jcr.session.ItemImpl.perform(ItemImpl.java:112)
> at
> org.apache.jackrabbit.oak.jcr.session.NodeImpl.getProperty(NodeImpl.java:625)
> at
> com.westernacher.noah.util.content_repository.JcrUtil.getStringProperty(JcrUtil.java:35)
> ---
> In my point of view this is a bug. This is the code that works:
> Example:
> /// 1) User Upload document through browser in our web app..
> // 2) ... document uploaded and saved in OAK CR
> // 3) Now generate the preview:
> updateDocumentPreview(documentId);
>
> Now the same in a thread that does not work:
> => I have only moved the method "updateDocumentPreview(documentId);" in a
> Thread (Java 8):
> //Same code as before except the last line replaced by following lines:
> Runnable run = ()-> {updateDocumentPreview(documentId);}
> new Thread(run).start(); //Start the thread to generate a document preview
> --
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (OAK-4911) Can not read node Property when move code into a Thread (Java)
[
https://issues.apache.org/jira/browse/OAK-4911?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15569500#comment-15569500
]
amin zamani commented on OAK-4911:
--
I have now modified the structure of the code:
Now in a thread a new file node is created but when I try to access the
property I still get the same error. I access in the same java thread where I
have created the file the properties of the node that I just have created
before. Here a little exampe:
new thread created with following content, it calls only the
createDocument(...) method and then I get the exception - without a thread i
don't have the exception:
public Document createDocument(String folderId, CreateDocumentDto createDto) {
try {
Node node = jcrSession.getNodeByIdentifier(folderId);
Binary binary =
jcrSession.getValueFactory().createBinary(createDto.getContent());
try {
Node file = JcrUtils.getOrCreateByPath(
node,
"",
DO_CREATE_UNIQUE_LEAF,
NodeType.NT_FOLDER,
NodeType.NT_FILE,
DO_AUTO_SAVE);
file.addMixin(NodeType.MIX_VERSIONABLE);
file.addMixin(NodeType.MIX_TITLE);
file.setProperty(Property.JCR_TITLE, createDto.getTitle());
file.setProperty(Property.JCR_DESCRIPTION,
createDto.getDescription());
file.addMixin(CustomNodeType.NOAH_ENTITY_DOCUMENT);
if (createDto.getDocumentType() != null) {
file.setProperty(CustomProperty.NOAH_DOCUMENT_TYPE_VALUE,
createDto.getDocumentType().getValue());
file.setProperty(CustomProperty.NOAH_DOCUMENT_TYPE_LABEL,
createDto.getDocumentType().getLabel());
}
file.setProperty(CustomProperty.NOAH_ENTITY_URL,
createDto.getEntityUrl());
file.addMixin(CustomNodeType.NOAH_AUDITABLE);
file.setProperty(CustomProperty.NOAH_CREATED_BY,
SecurityUtil.getCurrentUserLogin());
Node content = JcrUtils.getOrAddNode(file, Node.JCR_CONTENT,
NodeType.NT_RESOURCE);
content.setProperty(Property.JCR_DATA, binary);
content.setProperty(Property.JCR_MIMETYPE,
createDto.getContentType());
String previewFileType="";
if(createDto.getPreviewType() != null){
// Ok, we are creating a preview document, so add the
preview type
file.addMixin(CustomNodeType.NOAH_PREVIEW_DOCUMENT);
System.out.println("Create preview document, set preview
type:"+createDto.getPreviewType().name());
file.setProperty(CustomProperty.NOAH_PREVIEW_TYPE,
createDto.getPreviewType().name());
previewFileType = createDto.getPreviewType().name();
}
jcrSession.refresh(true);
jcrSession.save();
jcrSession.refresh(true);
System.out.println("Created "+previewFileType+" document,id:
"+file.getIdentifier()+" ("+createDto.getTitle()+"),path: "+file.getPath());
LOG.debug("Created "+previewFileType+" document,id:
"+file.getIdentifier()+" ("+createDto.getTitle()+"),path: "+file.getPath());
Version versionNode = versionFile(file, binary);
jcrSession.refresh(true);
return toDocument(versionNode);
} finally {
binary.dispose();
}
} catch (RepositoryException e) {
throw new RuntimeRepositoryException(e);
}
}
> Can not read node Property when move code into a Thread (Java)
> --
>
> Key: OAK-4911
> URL: https://issues.apache.org/jira/browse/OAK-4911
> Project: Jackrabbit Oak
> Issue Type: Bug
>Affects Versions: 1.3.10
> Environment: MAC OS X
>Reporter: amin zamani
> Attachments: java-code.txt
>
>
> Hallo,
> we develop an application and everything is working as it should. We upload
> documents and for each document a new preview file (node) should be
> generated. It works well when we execute the code synchron. But because of
> the fact that the generation of a preview file (like PDF format) can take
> very long time we decided to move the preview generation code into a usual
> java thread so that after the user is upload a document the website is
> responding very quick and does not wait till the preview file is generated
> but the preview file is generated parallel.
> No the problem: As soon as I move the same code regarding to the preview file
> generation into a usual thread (no modifications to the
[jira] [Commented] (OAK-4911) Can not read node Property when move code into a Thread (Java)
[
https://issues.apache.org/jira/browse/OAK-4911?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15569437#comment-15569437
]
amin zamani commented on OAK-4911:
--
I have added in each thread before it access the node this statement:
jcrSession.refresh(true);
But same error still exists -;(
> Can not read node Property when move code into a Thread (Java)
> --
>
> Key: OAK-4911
> URL: https://issues.apache.org/jira/browse/OAK-4911
> Project: Jackrabbit Oak
> Issue Type: Bug
>Affects Versions: 1.3.10
> Environment: MAC OS X
>Reporter: amin zamani
> Attachments: java-code.txt
>
>
> Hallo,
> we develop an application and everything is working as it should. We upload
> documents and for each document a new preview file (node) should be
> generated. It works well when we execute the code synchron. But because of
> the fact that the generation of a preview file (like PDF format) can take
> very long time we decided to move the preview generation code into a usual
> java thread so that after the user is upload a document the website is
> responding very quick and does not wait till the preview file is generated
> but the preview file is generated parallel.
> No the problem: As soon as I move the same code regarding to the preview file
> generation into a usual thread (no modifications to the logic, only a thread
> is bordered to it) suddenly the node path does not exist, this is the error:
> -
> Caused by: javax.jcr.PathNotFoundException: jcr:lastModifiedBy not found on
> /jcr:system/jcr:versionStorage/7e/f8/5b/7ef85b25-4598-4476-82df-446eb3a08a90/1.0/jcr:frozenNode/jcr:content
> at
> org.apache.jackrabbit.oak.jcr.session.NodeImpl$11.perform(NodeImpl.java:631)
> at
> org.apache.jackrabbit.oak.jcr.session.NodeImpl$11.perform(NodeImpl.java:625)
> at
> org.apache.jackrabbit.oak.jcr.delegate.SessionDelegate.perform(SessionDelegate.java:207)
> at
> org.apache.jackrabbit.oak.jcr.session.ItemImpl.perform(ItemImpl.java:112)
> at
> org.apache.jackrabbit.oak.jcr.session.NodeImpl.getProperty(NodeImpl.java:625)
> at
> com.westernacher.noah.util.content_repository.JcrUtil.getStringProperty(JcrUtil.java:35)
> ---
> In my point of view this is a bug. This is the code that works:
> Example:
> /// 1) User Upload document through browser in our web app..
> // 2) ... document uploaded and saved in OAK CR
> // 3) Now generate the preview:
> updateDocumentPreview(documentId);
>
> Now the same in a thread that does not work:
> => I have only moved the method "updateDocumentPreview(documentId);" in a
> Thread (Java 8):
> //Same code as before except the last line replaced by following lines:
> Runnable run = ()-> {updateDocumentPreview(documentId);}
> new Thread(run).start(); //Start the thread to generate a document preview
> --
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (OAK-4931) LdapIdentityProvider doesn't use configured custom attributes for all searches
Manfred Baedke created OAK-4931: --- Summary: LdapIdentityProvider doesn't use configured custom attributes for all searches Key: OAK-4931 URL: https://issues.apache.org/jira/browse/OAK-4931 Project: Jackrabbit Oak Issue Type: Bug Components: auth-ldap Affects Versions: 1.5.12, 1.4.8 Reporter: Manfred Baedke Assignee: Manfred Baedke The list of custom attibutes retrieved when looking up LDAP entries is not used for every search. Most notably LdapIdentityProvider.getIdentity() still retrieves all user attributes. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (OAK-4930) External Principal Management: DynamicSyncContext makes redundant calls to IdentityProvider.getIdentity()
Manfred Baedke created OAK-4930: --- Summary: External Principal Management: DynamicSyncContext makes redundant calls to IdentityProvider.getIdentity() Key: OAK-4930 URL: https://issues.apache.org/jira/browse/OAK-4930 Project: Jackrabbit Oak Issue Type: Improvement Components: auth-external Affects Versions: 1.5.12, 1.2.20, 1.4.8 Reporter: Manfred Baedke Assignee: Manfred Baedke When recursively collecting principal names associated with the declared group memberships of a given principal, the method DynamicSyncContext.collectPrincipalNames() unnecessarily calls IdentityProvider.getIdentity() for every declared group reference, though it is only necessary when the actual depth of the remaining recursion is >1. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (OAK-4883) Missing BlobGarbageCollection MBean on standby instance
[
https://issues.apache.org/jira/browse/OAK-4883?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Francesco Mari resolved OAK-4883.
-
Resolution: Fixed
Assignee: Francesco Mari (was: Timothee Maret)
Fixed at r1764475.
> Missing BlobGarbageCollection MBean on standby instance
> ---
>
> Key: OAK-4883
> URL: https://issues.apache.org/jira/browse/OAK-4883
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: segment-tar, segmentmk
>Reporter: Alex Parvulescu
>Assignee: Francesco Mari
> Labels: gc
> Attachments: OAK-4883.patch, OAK-4883.patch
>
>
> The {{BlobGarbageCollection}} MBean is no longer available on a standby
> instance, this affects non-shared datastore setups (on a shared datastore
> you'd only need to run blob gc on the primary).
> This change was introduced by OAK-4089 (and backported to 1.4 branch with
> OAK-4093).
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (OAK-4929) Clean GCMonitor#compacted method arguments
[
https://issues.apache.org/jira/browse/OAK-4929?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15568906#comment-15568906
]
Alex Parvulescu edited comment on OAK-4929 at 10/12/16 2:42 PM:
see here for the complete change diff [0]. while not a complicated change in
itself, it has a cyclic dependency problem where to be able to push this change
you'd have to do a sync release of both oak and segment-tar. or at least I
can't see how to properly split this one. fyi [~mduerig], [~frm].
[edit] please mind the {{SegmentNodeStoreService.java}} change that are
unrelated, and are coming in via a different patch not yet applied.
[0]
https://github.com/stillalex/jackrabbit-oak/commit/5e44b487ad59840896d0ae7aef23f4c476f6d372
was (Author: alex.parvulescu):
see here for the complete change diff [0]. while not a complicated change in
itself, it has a cyclic dependency problem where to be able to push this change
you'd have to do a sync release of both oak and segment-tar. or at least I
can't see how to properly split this one. fyi [~mduerig], [~frm].
[0]
https://github.com/stillalex/jackrabbit-oak/commit/5e44b487ad59840896d0ae7aef23f4c476f6d372
> Clean GCMonitor#compacted method arguments
> --
>
> Key: OAK-4929
> URL: https://issues.apache.org/jira/browse/OAK-4929
> Project: Jackrabbit Oak
> Issue Type: Technical task
> Components: core, lucene
>Reporter: Alex Parvulescu
>Assignee: Alex Parvulescu
> Fix For: 1.5.13
>
>
> Subtask of OAK-4283, first step is to remove all arguments from the
> {{GCMonitor#compacted}} api.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (OAK-4929) Clean GCMonitor#compacted method arguments
[
https://issues.apache.org/jira/browse/OAK-4929?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15568906#comment-15568906
]
Alex Parvulescu commented on OAK-4929:
--
see here for the complete change diff [0]. while not a complicated change in
itself, it has a cyclic dependency problem where to be able to push this change
you'd have to do a sync release of both oak and segment-tar. or at least I
can't see how to properly split this one. fyi [~mduerig], [~frm].
[0]
https://github.com/stillalex/jackrabbit-oak/commit/5e44b487ad59840896d0ae7aef23f4c476f6d372
> Clean GCMonitor#compacted method arguments
> --
>
> Key: OAK-4929
> URL: https://issues.apache.org/jira/browse/OAK-4929
> Project: Jackrabbit Oak
> Issue Type: Technical task
> Components: core, lucene
>Reporter: Alex Parvulescu
>Assignee: Alex Parvulescu
> Fix For: 1.5.13
>
>
> Subtask of OAK-4283, first step is to remove all arguments from the
> {{GCMonitor#compacted}} api.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (OAK-4348) Cross language search via SMT
[
https://issues.apache.org/jira/browse/OAK-4348?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15568800#comment-15568800
]
Tommaso Teofili commented on OAK-4348:
--
+1 Vikas, it's still work in progress and I definitely agree checking
{{IndexDefinition}} would save us some unnecessary calls.
Other than that the cost is usually quite cheap (did a test today with a
Spanish to English language pack) and I couldn't notice the difference while
performing queries (so I expect it to be in the order of a few milliseconds).
> Cross language search via SMT
> -
>
> Key: OAK-4348
> URL: https://issues.apache.org/jira/browse/OAK-4348
> Project: Jackrabbit Oak
> Issue Type: New Feature
> Components: query
>Reporter: Tommaso Teofili
>Assignee: Tommaso Teofili
> Fix For: 1.6
>
>
> It would be interesting to investigate usage of statistical machine
> translation toolkits (like Apache Joshua) in order to enable cross language
> search, so that query can be eventually expanded to search over translated
> terms too.
> Example:
> - enable spanish to english translation
> - perform full text search for "hola"
> - query engine looks for translations for "hola"
> - SMT returns "hello"
> - query engine add an additional (UNION) clause for the translated term
> - the query performed by Oak becomes "hello OR hola"
> - both results for english and spanish terms get returned
> This of course should be configurable.
> Note that the integration may happen also via Apache Tika which provides a
> Translator API.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (OAK-4348) Cross language search via SMT
[ https://issues.apache.org/jira/browse/OAK-4348?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15568742#comment-15568742 ] Vikas Saurabh commented on OAK-4348: [~teofili], I completely missed checking this out. I think we should check how costly is it to consult Joshua. Moreover, even if it's cheap, I think the query terms should be enhanced if some property on index def declares to do so - that way, we can quit early for un-interesting index defs. wdyt? > Cross language search via SMT > - > > Key: OAK-4348 > URL: https://issues.apache.org/jira/browse/OAK-4348 > Project: Jackrabbit Oak > Issue Type: New Feature > Components: query >Reporter: Tommaso Teofili >Assignee: Tommaso Teofili > Fix For: 1.6 > > > It would be interesting to investigate usage of statistical machine > translation toolkits (like Apache Joshua) in order to enable cross language > search, so that query can be eventually expanded to search over translated > terms too. > Example: > - enable spanish to english translation > - perform full text search for "hola" > - query engine looks for translations for "hola" > - SMT returns "hello" > - query engine add an additional (UNION) clause for the translated term > - the query performed by Oak becomes "hello OR hola" > - both results for english and spanish terms get returned > This of course should be configurable. > Note that the integration may happen also via Apache Tika which provides a > Translator API. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (OAK-4883) Missing BlobGarbageCollection MBean on standby instance
[
https://issues.apache.org/jira/browse/OAK-4883?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Timothee Maret updated OAK-4883:
Attachment: OAK-4883.patch
Attaching updated patch
cc [~frm]
> Missing BlobGarbageCollection MBean on standby instance
> ---
>
> Key: OAK-4883
> URL: https://issues.apache.org/jira/browse/OAK-4883
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: segment-tar, segmentmk
>Reporter: Alex Parvulescu
>Assignee: Timothee Maret
> Labels: gc
> Attachments: OAK-4883.patch, OAK-4883.patch
>
>
> The {{BlobGarbageCollection}} MBean is no longer available on a standby
> instance, this affects non-shared datastore setups (on a shared datastore
> you'd only need to run blob gc on the primary).
> This change was introduced by OAK-4089 (and backported to 1.4 branch with
> OAK-4093).
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (OAK-4929) Clean GCMonitor#compacted method arguments
Alex Parvulescu created OAK-4929:
Summary: Clean GCMonitor#compacted method arguments
Key: OAK-4929
URL: https://issues.apache.org/jira/browse/OAK-4929
Project: Jackrabbit Oak
Issue Type: Technical task
Components: core, lucene
Reporter: Alex Parvulescu
Assignee: Alex Parvulescu
Subtask of OAK-4283, first step is to remove all arguments from the
{{GCMonitor#compacted}} api.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (OAK-4929) Clean GCMonitor#compacted method arguments
[
https://issues.apache.org/jira/browse/OAK-4929?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alex Parvulescu updated OAK-4929:
-
Fix Version/s: (was: Segment Tar 0.0.16)
1.5.13
> Clean GCMonitor#compacted method arguments
> --
>
> Key: OAK-4929
> URL: https://issues.apache.org/jira/browse/OAK-4929
> Project: Jackrabbit Oak
> Issue Type: Technical task
> Components: core, lucene
>Reporter: Alex Parvulescu
>Assignee: Alex Parvulescu
> Fix For: 1.5.13
>
>
> Subtask of OAK-4283, first step is to remove all arguments from the
> {{GCMonitor#compacted}} api.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Assigned] (OAK-4283) Align GCMonitor API with implementation
[
https://issues.apache.org/jira/browse/OAK-4283?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alex Parvulescu reassigned OAK-4283:
Assignee: Alex Parvulescu (was: Andrei Dulceanu)
> Align GCMonitor API with implementation
>
>
> Key: OAK-4283
> URL: https://issues.apache.org/jira/browse/OAK-4283
> Project: Jackrabbit Oak
> Issue Type: Task
> Components: segment-tar
>Reporter: Michael Dürig
>Assignee: Alex Parvulescu
> Labels: api-change, compaction, gc
> Fix For: Segment Tar 0.0.16
>
>
> The argument taken by {{GCMonitor.compacted}} related to parameters of the
> compaction map. The latter has gone with OAK-3348. We need to come up with a
> way to adjust this API accordingly. Also it might make sense to broaden the
> scope of {{GCMonitor}} from its initial intent (logging) to a more general
> one as this is how it is already used e.g. by the {{RefreshOnGC}}
> implementation and for OAK-4096.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (OAK-4450) Properly split the FileStore into read-only and r/w variants
[
https://issues.apache.org/jira/browse/OAK-4450?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15568518#comment-15568518
]
Alex Parvulescu edited comment on OAK-4450 at 10/12/16 12:51 PM:
-
attaching changes needed in oak-run once this is applied and the dependency is
updated (includes change in pom.xml file needed just to testing this stuff out).
was (Author: alex.parvulescu):
attaching changes needed in oak-run once this is applied and the dependency is
updated (includes change in pom.xml file needed just to testing this stuff out).
[edit] removed the attachment, I had forgotten to update some code.
> Properly split the FileStore into read-only and r/w variants
> -
>
> Key: OAK-4450
> URL: https://issues.apache.org/jira/browse/OAK-4450
> Project: Jackrabbit Oak
> Issue Type: Technical task
> Components: segment-tar
>Reporter: Michael Dürig
>Assignee: Michael Dürig
> Labels: technical_debt
> Fix For: Segment Tar 0.0.18
>
> Attachments: OAK-4450-oak-run.patch
>
>
> The {{ReadOnlyFileStore}} class currently simply overrides the {{FileStore}}
> class replacing all mutator methods with a trivial implementation. This
> approach however leaks into its ancestor as the read only store needs to pass
> a flag to the constructor of its super class so some fields can be
> instantiated properly for the read only case.
> We should clean this up to properly separate the read only and the r/w store.
> Most likely we should factor the commonalities into a common, abstract base
> class.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (OAK-4450) Properly split the FileStore into read-only and r/w variants
[
https://issues.apache.org/jira/browse/OAK-4450?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alex Parvulescu updated OAK-4450:
-
Attachment: OAK-4450-oak-run.patch
> Properly split the FileStore into read-only and r/w variants
> -
>
> Key: OAK-4450
> URL: https://issues.apache.org/jira/browse/OAK-4450
> Project: Jackrabbit Oak
> Issue Type: Technical task
> Components: segment-tar
>Reporter: Michael Dürig
>Assignee: Michael Dürig
> Labels: technical_debt
> Fix For: Segment Tar 0.0.18
>
> Attachments: OAK-4450-oak-run.patch
>
>
> The {{ReadOnlyFileStore}} class currently simply overrides the {{FileStore}}
> class replacing all mutator methods with a trivial implementation. This
> approach however leaks into its ancestor as the read only store needs to pass
> a flag to the constructor of its super class so some fields can be
> instantiated properly for the read only case.
> We should clean this up to properly separate the read only and the r/w store.
> Most likely we should factor the commonalities into a common, abstract base
> class.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (OAK-4450) Properly split the FileStore into read-only and r/w variants
[
https://issues.apache.org/jira/browse/OAK-4450?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15565351#comment-15565351
]
Alex Parvulescu edited comment on OAK-4450 at 10/12/16 12:47 PM:
-
WIP at [0] and [1] [~mduerig], [~frm] feedback appreciated!
[0]
https://github.com/stillalex/jackrabbit-oak/commit/148296b1ac6f4a96ae24cff60c3116d774052664
[1]
https://github.com/stillalex/jackrabbit-oak/commit/01fbc8311e467996be5c5116dd445d356af6db9b
was (Author: alex.parvulescu):
WIP at
https://github.com/stillalex/jackrabbit-oak/commit/148296b1ac6f4a96ae24cff60c3116d774052664
[~mduerig], [~frm] feedback appreciated!
> Properly split the FileStore into read-only and r/w variants
> -
>
> Key: OAK-4450
> URL: https://issues.apache.org/jira/browse/OAK-4450
> Project: Jackrabbit Oak
> Issue Type: Technical task
> Components: segment-tar
>Reporter: Michael Dürig
>Assignee: Michael Dürig
> Labels: technical_debt
> Fix For: Segment Tar 0.0.18
>
>
> The {{ReadOnlyFileStore}} class currently simply overrides the {{FileStore}}
> class replacing all mutator methods with a trivial implementation. This
> approach however leaks into its ancestor as the read only store needs to pass
> a flag to the constructor of its super class so some fields can be
> instantiated properly for the read only case.
> We should clean this up to properly separate the read only and the r/w store.
> Most likely we should factor the commonalities into a common, abstract base
> class.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (OAK-4450) Properly split the FileStore into read-only and r/w variants
[
https://issues.apache.org/jira/browse/OAK-4450?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15568518#comment-15568518
]
Alex Parvulescu edited comment on OAK-4450 at 10/12/16 12:13 PM:
-
attaching changes needed in oak-run once this is applied and the dependency is
updated (includes change in pom.xml file needed just to testing this stuff out).
[edit] removed the attachment, I had forgotten to update some code.
was (Author: alex.parvulescu):
attaching changes needed in oak-run once this is applied and the dependency is
updated (includes change in pom.xml file needed just to testing this stuff out).
> Properly split the FileStore into read-only and r/w variants
> -
>
> Key: OAK-4450
> URL: https://issues.apache.org/jira/browse/OAK-4450
> Project: Jackrabbit Oak
> Issue Type: Technical task
> Components: segment-tar
>Reporter: Michael Dürig
>Assignee: Michael Dürig
> Labels: technical_debt
> Fix For: Segment Tar 0.0.18
>
>
> The {{ReadOnlyFileStore}} class currently simply overrides the {{FileStore}}
> class replacing all mutator methods with a trivial implementation. This
> approach however leaks into its ancestor as the read only store needs to pass
> a flag to the constructor of its super class so some fields can be
> instantiated properly for the read only case.
> We should clean this up to properly separate the read only and the r/w store.
> Most likely we should factor the commonalities into a common, abstract base
> class.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (OAK-4450) Properly split the FileStore into read-only and r/w variants
[
https://issues.apache.org/jira/browse/OAK-4450?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alex Parvulescu updated OAK-4450:
-
Attachment: (was: OAK-4450-oak-run.patch)
> Properly split the FileStore into read-only and r/w variants
> -
>
> Key: OAK-4450
> URL: https://issues.apache.org/jira/browse/OAK-4450
> Project: Jackrabbit Oak
> Issue Type: Technical task
> Components: segment-tar
>Reporter: Michael Dürig
>Assignee: Michael Dürig
> Labels: technical_debt
> Fix For: Segment Tar 0.0.18
>
>
> The {{ReadOnlyFileStore}} class currently simply overrides the {{FileStore}}
> class replacing all mutator methods with a trivial implementation. This
> approach however leaks into its ancestor as the read only store needs to pass
> a flag to the constructor of its super class so some fields can be
> instantiated properly for the read only case.
> We should clean this up to properly separate the read only and the r/w store.
> Most likely we should factor the commonalities into a common, abstract base
> class.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (OAK-4883) Missing BlobGarbageCollection MBean on standby instance
[
https://issues.apache.org/jira/browse/OAK-4883?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15568540#comment-15568540
]
Timothee Maret commented on OAK-4883:
-
Good catch, you are correct. I'll update the patch against the latest trunk,
thanks!
> Missing BlobGarbageCollection MBean on standby instance
> ---
>
> Key: OAK-4883
> URL: https://issues.apache.org/jira/browse/OAK-4883
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: segment-tar, segmentmk
>Reporter: Alex Parvulescu
>Assignee: Timothee Maret
> Labels: gc
> Attachments: OAK-4883.patch
>
>
> The {{BlobGarbageCollection}} MBean is no longer available on a standby
> instance, this affects non-shared datastore setups (on a shared datastore
> you'd only need to run blob gc on the primary).
> This change was introduced by OAK-4089 (and backported to 1.4 branch with
> OAK-4093).
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (OAK-4883) Missing BlobGarbageCollection MBean on standby instance
[
https://issues.apache.org/jira/browse/OAK-4883?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15568522#comment-15568522
]
Francesco Mari edited comment on OAK-4883 at 10/12/16 11:59 AM:
I was bad at line counting. The incriminating line is [this
one|https://github.com/tmaret/jackrabbit-oak/blob/OAK-4883/oak-segment-tar/src/main/java/org/apache/jackrabbit/oak/segment/SegmentNodeStoreService.java#L340].
The 'false' literal passed to toBoolean() is not used for comparison, but as a
default value in case the value for the 'standby' property is not provided or
invalid. As such, that method will effectively register a NodeStore only if the
'standby' property is true: that condition should be reversed. The rest of the
patch is correct, since it always register a BlobGCMBean independently from the
value of the 'standby' property, disabling observation in the SegmentNodeStore
if 'standby' is true.
was (Author: frm):
I was bad at line counting. The incriminating line is [this
one|https://github.com/tmaret/jackrabbit-oak/blob/OAK-4883/oak-segment-tar/src/main/java/org/apache/jackrabbit/oak/segment/SegmentNodeStoreService.java#L340].
The 'false' literal passed to toBoolean() is not used for comparison, but as a
default value in case the value for the 'standby' property is not provided or
invalid. As such, that line will effectively register a NodeStore only if the
'standby' property is true: that condition should be reverted. The rest of the
patch is correct, since it always register a BlobGCMBean independently from the
value of the 'standby' property, disabling observation in the SegmentNodeStore
if 'standby' is true.
> Missing BlobGarbageCollection MBean on standby instance
> ---
>
> Key: OAK-4883
> URL: https://issues.apache.org/jira/browse/OAK-4883
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: segment-tar, segmentmk
>Reporter: Alex Parvulescu
>Assignee: Timothee Maret
> Labels: gc
> Attachments: OAK-4883.patch
>
>
> The {{BlobGarbageCollection}} MBean is no longer available on a standby
> instance, this affects non-shared datastore setups (on a shared datastore
> you'd only need to run blob gc on the primary).
> This change was introduced by OAK-4089 (and backported to 1.4 branch with
> OAK-4093).
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (OAK-4883) Missing BlobGarbageCollection MBean on standby instance
[
https://issues.apache.org/jira/browse/OAK-4883?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15568522#comment-15568522
]
Francesco Mari commented on OAK-4883:
-
I was bad at line counting. The incriminating line is [this
one|https://github.com/tmaret/jackrabbit-oak/blob/OAK-4883/oak-segment-tar/src/main/java/org/apache/jackrabbit/oak/segment/SegmentNodeStoreService.java#L340].
The 'false' literal passed to toBoolean() is not used for comparison, but as a
default value in case the value for the 'standby' property is not provided or
invalid. As such, that line will effectively register a NodeStore only if the
'standby' property is true: that condition should be reverted. The rest of the
patch is correct, since it always register a BlobGCMBean independently from the
value of the 'standby' property, disabling observation in the SegmentNodeStore
if 'standby' is true.
> Missing BlobGarbageCollection MBean on standby instance
> ---
>
> Key: OAK-4883
> URL: https://issues.apache.org/jira/browse/OAK-4883
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: segment-tar, segmentmk
>Reporter: Alex Parvulescu
>Assignee: Timothee Maret
> Labels: gc
> Attachments: OAK-4883.patch
>
>
> The {{BlobGarbageCollection}} MBean is no longer available on a standby
> instance, this affects non-shared datastore setups (on a shared datastore
> you'd only need to run blob gc on the primary).
> This change was introduced by OAK-4089 (and backported to 1.4 branch with
> OAK-4093).
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (OAK-4450) Properly split the FileStore into read-only and r/w variants
[
https://issues.apache.org/jira/browse/OAK-4450?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alex Parvulescu updated OAK-4450:
-
Attachment: OAK-4450-oak-run.patch
attaching changes needed in oak-run once this is applied and the dependency is
updated (includes change in pom.xml file needed just to testing this stuff out).
> Properly split the FileStore into read-only and r/w variants
> -
>
> Key: OAK-4450
> URL: https://issues.apache.org/jira/browse/OAK-4450
> Project: Jackrabbit Oak
> Issue Type: Technical task
> Components: segment-tar
>Reporter: Michael Dürig
>Assignee: Michael Dürig
> Labels: technical_debt
> Fix For: Segment Tar 0.0.18
>
> Attachments: OAK-4450-oak-run.patch
>
>
> The {{ReadOnlyFileStore}} class currently simply overrides the {{FileStore}}
> class replacing all mutator methods with a trivial implementation. This
> approach however leaks into its ancestor as the read only store needs to pass
> a flag to the constructor of its super class so some fields can be
> instantiated properly for the read only case.
> We should clean this up to properly separate the read only and the r/w store.
> Most likely we should factor the commonalities into a common, abstract base
> class.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (OAK-1312) Bundle nodes into a document
[ https://issues.apache.org/jira/browse/OAK-1312?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15568502#comment-15568502 ] Chetan Mehrotra commented on OAK-1312: -- Opened OAK-4928 to track this > Bundle nodes into a document > > > Key: OAK-1312 > URL: https://issues.apache.org/jira/browse/OAK-1312 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: core, documentmk >Reporter: Marcel Reutegger >Assignee: Chetan Mehrotra > Labels: performance > Fix For: 1.6 > > Attachments: OAK-1312-meta-prop-handling.patch, > OAK-1312-review-v1.diff, OAK-1312-review-v2.diff > > > For very fine grained content with many nodes and only few properties per > node it would be more efficient to bundle multiple nodes into a single > MongoDB document. Mostly reading would benefit because there are less > roundtrips to the backend. At the same time storage footprint would be lower > because metadata overhead is per document. > Feature branch - > https://github.com/chetanmeh/jackrabbit-oak/compare/trunk...chetanmeh:OAK-1312 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (OAK-4926) o.a.j.o.s.s.c.StandbyClientSyncExecution#isLocal should expect missing segment
[
https://issues.apache.org/jira/browse/OAK-4926?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Francesco Mari resolved OAK-4926.
-
Resolution: Fixed
Assignee: Francesco Mari (was: Timothee Maret)
Fixed at r1764442.
> o.a.j.o.s.s.c.StandbyClientSyncExecution#isLocal should expect missing segment
> --
>
> Key: OAK-4926
> URL: https://issues.apache.org/jira/browse/OAK-4926
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: segment-tar
>Affects Versions: Segment Tar 0.0.14
>Reporter: Timothee Maret
>Assignee: Francesco Mari
> Fix For: Segment Tar 0.0.16
>
> Attachments: OAK-4926.patch, OAK-4926.patch
>
>
> Currently the method
> {{org.apache.jackrabbit.oak.segment.standby.client.StandbyClientSyncExecution#isLocal}}
> does invoke
> {code}
> referencedId.getSegment();
> {code}
> in order to read the referenced segment. In case of missing segment, the
> {{ReferenceId.getSegment}} does throw a SNFE *and* logs an ERROR level
> statement. The SNFE is needed but not the log statement in this case.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (OAK-4928) Use Mongo sub document structure with bundling feature
Chetan Mehrotra created OAK-4928: Summary: Use Mongo sub document structure with bundling feature Key: OAK-4928 URL: https://issues.apache.org/jira/browse/OAK-4928 Project: Jackrabbit Oak Issue Type: Improvement Components: mongomk Reporter: Chetan Mehrotra Assignee: Chetan Mehrotra The MongoDocumentStore could leverage sub document structure when persisting map entries with relative paths. That way many duplicate path prefixes could be avoided. It would be MongoDocumentStore specific and transparent to the DocumentNodeStore. The UpdateOp and also the in-memory Document representation would still have the full relative paths for bundled nodes/properties. In any case, this enhancement should be discussed first in a separate issue. Based on [~mreutegg] [comment|https://issues.apache.org/jira/browse/OAK-1312?focusedCommentId=15503050=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-15503050] -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (OAK-4883) Missing BlobGarbageCollection MBean on standby instance
[
https://issues.apache.org/jira/browse/OAK-4883?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15568482#comment-15568482
]
Timothee Maret commented on OAK-4883:
-
[~frm] I assume you mean that line [0]. If so, it behaves the same as before
the patch in OAK-4089. A node store instance is build however it is registered
only if the instance is *not* a primary [1].
The patch keeps the goal of OAK-4089, by not registering the observation
subsystem as mentioned in [2].
AFAIU, a node store instance is required in order to build the {{BlobGCMBean}}.
I may be wrong about that or maybe there's a way to get the required
information to build the {{BlobGCMBean}}. If so I'd be happy to update the
patch.
[0]
https://github.com/tmaret/jackrabbit-oak/blob/OAK-4883/oak-segment-tar/src/main/java/org/apache/jackrabbit/oak/segment/SegmentNodeStoreService.java#L339
[1]
https://github.com/tmaret/jackrabbit-oak/blob/OAK-4883/oak-segment-tar/src/main/java/org/apache/jackrabbit/oak/segment/SegmentNodeStoreService.java#L340
[2]
https://github.com/apache/jackrabbit-oak/blob/2b6c2f5340f3b6485dda5c493f6343d232c883e9/oak-segment/src/main/java/org/apache/jackrabbit/oak/plugins/segment/SegmentNodeStoreService.java#L595
> Missing BlobGarbageCollection MBean on standby instance
> ---
>
> Key: OAK-4883
> URL: https://issues.apache.org/jira/browse/OAK-4883
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: segment-tar, segmentmk
>Reporter: Alex Parvulescu
>Assignee: Timothee Maret
> Labels: gc
> Attachments: OAK-4883.patch
>
>
> The {{BlobGarbageCollection}} MBean is no longer available on a standby
> instance, this affects non-shared datastore setups (on a shared datastore
> you'd only need to run blob gc on the primary).
> This change was introduced by OAK-4089 (and backported to 1.4 branch with
> OAK-4093).
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (OAK-4883) Missing BlobGarbageCollection MBean on standby instance
[
https://issues.apache.org/jira/browse/OAK-4883?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15568442#comment-15568442
]
Francesco Mari commented on OAK-4883:
-
[~marett], the patch looks incorrect to me. The condition at line 339 allows a
NodeStore to be registered if the 'standby' configuration property is true,
while we don't want to register a NodeStore if the instance is supposed to work
with the standby semantics.
> Missing BlobGarbageCollection MBean on standby instance
> ---
>
> Key: OAK-4883
> URL: https://issues.apache.org/jira/browse/OAK-4883
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: segment-tar, segmentmk
>Reporter: Alex Parvulescu
>Assignee: Timothee Maret
> Labels: gc
> Attachments: OAK-4883.patch
>
>
> The {{BlobGarbageCollection}} MBean is no longer available on a standby
> instance, this affects non-shared datastore setups (on a shared datastore
> you'd only need to run blob gc on the primary).
> This change was introduced by OAK-4089 (and backported to 1.4 branch with
> OAK-4093).
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (OAK-4911) Can not read node Property when move code into a Thread (Java)
[
https://issues.apache.org/jira/browse/OAK-4911?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15568404#comment-15568404
]
Chetan Mehrotra commented on OAK-4911:
--
I believe what you are observing is write skew [1]. Which session does the
preview generation thread uses? Is it created after the file is saved or its a
long living session? If later then you need to do explicit refresh
[1]
https://jackrabbit.apache.org/oak/docs/differences.html#Session_state_and_refresh_behaviour
> Can not read node Property when move code into a Thread (Java)
> --
>
> Key: OAK-4911
> URL: https://issues.apache.org/jira/browse/OAK-4911
> Project: Jackrabbit Oak
> Issue Type: Bug
>Affects Versions: 1.3.10
> Environment: MAC OS X
>Reporter: amin zamani
> Attachments: java-code.txt
>
>
> Hallo,
> we develop an application and everything is working as it should. We upload
> documents and for each document a new preview file (node) should be
> generated. It works well when we execute the code synchron. But because of
> the fact that the generation of a preview file (like PDF format) can take
> very long time we decided to move the preview generation code into a usual
> java thread so that after the user is upload a document the website is
> responding very quick and does not wait till the preview file is generated
> but the preview file is generated parallel.
> No the problem: As soon as I move the same code regarding to the preview file
> generation into a usual thread (no modifications to the logic, only a thread
> is bordered to it) suddenly the node path does not exist, this is the error:
> -
> Caused by: javax.jcr.PathNotFoundException: jcr:lastModifiedBy not found on
> /jcr:system/jcr:versionStorage/7e/f8/5b/7ef85b25-4598-4476-82df-446eb3a08a90/1.0/jcr:frozenNode/jcr:content
> at
> org.apache.jackrabbit.oak.jcr.session.NodeImpl$11.perform(NodeImpl.java:631)
> at
> org.apache.jackrabbit.oak.jcr.session.NodeImpl$11.perform(NodeImpl.java:625)
> at
> org.apache.jackrabbit.oak.jcr.delegate.SessionDelegate.perform(SessionDelegate.java:207)
> at
> org.apache.jackrabbit.oak.jcr.session.ItemImpl.perform(ItemImpl.java:112)
> at
> org.apache.jackrabbit.oak.jcr.session.NodeImpl.getProperty(NodeImpl.java:625)
> at
> com.westernacher.noah.util.content_repository.JcrUtil.getStringProperty(JcrUtil.java:35)
> ---
> In my point of view this is a bug. This is the code that works:
> Example:
> /// 1) User Upload document through browser in our web app..
> // 2) ... document uploaded and saved in OAK CR
> // 3) Now generate the preview:
> updateDocumentPreview(documentId);
>
> Now the same in a thread that does not work:
> => I have only moved the method "updateDocumentPreview(documentId);" in a
> Thread (Java 8):
> //Same code as before except the last line replaced by following lines:
> Runnable run = ()-> {updateDocumentPreview(documentId);}
> new Thread(run).start(); //Start the thread to generate a document preview
> --
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (OAK-4916) Add support for excluding commits to BackgroundObserver
[
https://issues.apache.org/jira/browse/OAK-4916?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15568342#comment-15568342
]
Stefan Egli commented on OAK-4916:
--
One way to do this would be to make the {{BackgroundObserver}} a
{{FilteringAwareObserver}} such that it could get the 'skip' signal from the
upstream, new '{{FilteringObserver}}'. It would be another variant to what
Chetan's composition pattern, however the BackgroundObserver would still have
to maintain about the same logic in {{contentChanged}} wrt skipped changes as
now: the goal of prefiltering is to shrink the queue of the BackgroundObserver
and for that we do have to make some adaptions there. Surely there are other
variants than what I came up with, but I doubt it's possible without any change
in the BackgroundObserver.
I'll work on a next iteration based on these 2 feedbacks, Thx!
> Add support for excluding commits to BackgroundObserver
> ---
>
> Key: OAK-4916
> URL: https://issues.apache.org/jira/browse/OAK-4916
> Project: Jackrabbit Oak
> Issue Type: Technical task
> Components: core
>Affects Versions: 1.5.11
>Reporter: Stefan Egli
>Assignee: Stefan Egli
> Fix For: 1.6
>
> Attachments: OAK-4916.patch
>
>
> As part of pre-filtering commits it would be useful to have support in the
> BackgroundObserver (in general) that would allow to exclude certain commits
> from being added to the (BackgroundObserver's) queue, thus keeping the queue
> smaller. The actual filtering is up to subclasses.
> The suggested implementation is as follows:
> * a new method {{isExcluded}} is introduced which represents a subclass hook
> for filtering
> * excluded commits are not added to the queue
> * when multiple commits are excluded subsequently, this is collapsed
> * the first non-excluded commit (ContentChange) added to the queue is marked
> with the last non-excluded root state as the 'previous root'
> * downstream Observers are notified of the exclusion of a commit via a
> special CommitInfo {{NOOP_CHANGE}}: this instructs it to exclude this change
> while at the same time 'fast-forwarding' the root state to the new one.
> ** this extra token is one way of solving the problem that
> {{Observer.contentChanged}} represents a diff between two states but does not
> transport the 'from' state explicitly - that is implicitly taken from the
> previous call to {{contentChanged}}. Thus using such a gap token
> ({{NOOP_CHANGE}}) seems to be the only way to instruct Observers to skip a
> change.
> To repeat: whoever extends BackgroundObserver with filtering must be aware of
> the new {{NOOP_CHANGE}} token. Anyone not doing filtering will not get any
> {{NOOP_CHANGE}} tokens though.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (OAK-4924) avoid CommitInfo==null in contentChanged call in SegmentNodeStore.refresh
[
https://issues.apache.org/jira/browse/OAK-4924?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15568339#comment-15568339
]
Chetan Mehrotra commented on OAK-4924:
--
bq. Which means that we can't prefilter async index updates
Supporting that would require following change
# {{AsyncIndexUpdate#mergeWithConcurrencyCheck}} - It should pass a CommitInfo
with {{CommitContext}} set. See {{MutableRoot}}
# You would need to explicitly include the ChangeCollector ValidatorProvider in
the {{CompositeHook}}.
This would then ensure that at least on cluster node where async index runs
CommitInfo has ChangeSet populated
> avoid CommitInfo==null in contentChanged call in SegmentNodeStore.refresh
> -
>
> Key: OAK-4924
> URL: https://issues.apache.org/jira/browse/OAK-4924
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: segmentmk
>Affects Versions: 1.5.12
>Reporter: Stefan Egli
>Assignee: Stefan Egli
>
> Currently
> [SegmentNodeStore.refreshHead|https://github.com/apache/jackrabbit-oak/blob/d82f9b21d02a7eaf856f546e778118161d71b760/oak-segment-tar/src/main/java/org/apache/jackrabbit/oak/segment/SegmentNodeStore.java#L231]
> calls {{contentChanged}} with null as the CommitInfo. This is problematic
> for prefiltering (OAK-4796, OAK-4907 et al) as for that a ChangeSet of
> changed items in a commit is stored in the CommitContext in the CommitInfo.
> Thus it would be useful to not send null but a CommitInfo that has the
> equivalent meaning of null but is a new object for each call (so that the
> ChangeSet can be set).
> [~mduerig], [~frm], [~alex.parvulescu] wdyt?
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (OAK-4924) avoid CommitInfo==null in contentChanged call in SegmentNodeStore.refresh
[
https://issues.apache.org/jira/browse/OAK-4924?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alex Parvulescu updated OAK-4924:
-
Fix Version/s: (was: 1.6)
> avoid CommitInfo==null in contentChanged call in SegmentNodeStore.refresh
> -
>
> Key: OAK-4924
> URL: https://issues.apache.org/jira/browse/OAK-4924
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: segmentmk
>Affects Versions: 1.5.12
>Reporter: Stefan Egli
>Assignee: Stefan Egli
>
> Currently
> [SegmentNodeStore.refreshHead|https://github.com/apache/jackrabbit-oak/blob/d82f9b21d02a7eaf856f546e778118161d71b760/oak-segment-tar/src/main/java/org/apache/jackrabbit/oak/segment/SegmentNodeStore.java#L231]
> calls {{contentChanged}} with null as the CommitInfo. This is problematic
> for prefiltering (OAK-4796, OAK-4907 et al) as for that a ChangeSet of
> changed items in a commit is stored in the CommitContext in the CommitInfo.
> Thus it would be useful to not send null but a CommitInfo that has the
> equivalent meaning of null but is a new object for each call (so that the
> ChangeSet can be set).
> [~mduerig], [~frm], [~alex.parvulescu] wdyt?
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (OAK-4907) Collect changes (paths, nts, props..) of a commit in a validator
[ https://issues.apache.org/jira/browse/OAK-4907?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15568323#comment-15568323 ] Chetan Mehrotra commented on OAK-4907: -- bq. In theory it should also be OK for the ChangeCollector to add a new CommitContext (which it indeed doesn't do now) when it's not there - and in this case the check for EMPTY would avoid that. Yes that would have been ideal. See OAK-4640 for background on why this route was not taken > Collect changes (paths, nts, props..) of a commit in a validator > > > Key: OAK-4907 > URL: https://issues.apache.org/jira/browse/OAK-4907 > Project: Jackrabbit Oak > Issue Type: Technical task > Components: core >Affects Versions: 1.5.11 >Reporter: Stefan Egli >Assignee: Stefan Egli > Fix For: 1.6 > > Attachments: OAK-4907.patch, OAK-4907.v2.patch > > > It would be useful to collect a set of changes of a commit (eg in a > validator) that could later be used in an Observer for eg prefiltering. > Such a change collector should collect paths, nodetypes, properties, > node-names (and perhaps more at a later stage) of all changes and store the > result in the CommitInfo's CommitContext. > Note that this is a result of > [discussions|https://issues.apache.org/jira/browse/OAK-4796?focusedCommentId=15550962=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-15550962] > around design in OAK-4796 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (OAK-4924) avoid CommitInfo==null in contentChanged call in SegmentNodeStore.refresh
[
https://issues.apache.org/jira/browse/OAK-4924?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Egli resolved OAK-4924.
--
Resolution: Invalid
Assignee: Stefan Egli
Chetan's right, its ok there to pass null (or EMPTY, but that's equivalent and
only a detail in this context). I was confusing this with assuming that commit
hooks (thus the ChangeCollector) would be applied afterwards - which it isn't
of course, it's just a direct notification to the Observers.
Which means that given the ChangeCollector is part of the commit hook execution
(only), it can't be applied in this case. Which means that we can't prefilter
async index updates - which is somewhat suboptimal. So if we wanted to fix that
we'd have to find another solution - but that's independent of this null.
Hence closing this ticket as invalid. Thx!
> avoid CommitInfo==null in contentChanged call in SegmentNodeStore.refresh
> -
>
> Key: OAK-4924
> URL: https://issues.apache.org/jira/browse/OAK-4924
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: segmentmk
>Affects Versions: 1.5.12
>Reporter: Stefan Egli
>Assignee: Stefan Egli
> Fix For: 1.6
>
>
> Currently
> [SegmentNodeStore.refreshHead|https://github.com/apache/jackrabbit-oak/blob/d82f9b21d02a7eaf856f546e778118161d71b760/oak-segment-tar/src/main/java/org/apache/jackrabbit/oak/segment/SegmentNodeStore.java#L231]
> calls {{contentChanged}} with null as the CommitInfo. This is problematic
> for prefiltering (OAK-4796, OAK-4907 et al) as for that a ChangeSet of
> changed items in a commit is stored in the CommitContext in the CommitInfo.
> Thus it would be useful to not send null but a CommitInfo that has the
> equivalent meaning of null but is a new object for each call (so that the
> ChangeSet can be set).
> [~mduerig], [~frm], [~alex.parvulescu] wdyt?
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (OAK-4907) Collect changes (paths, nts, props..) of a commit in a validator
[ https://issues.apache.org/jira/browse/OAK-4907?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15568297#comment-15568297 ] Stefan Egli commented on OAK-4907: -- Thx [~chetanm], a few comments on the points: bq. 1. Instead of special casing for EMPTY ... I see, I guess while the two variants aren't really equivalent they are both not ideal. In theory it should also be OK for the ChangeCollector to add a _new_ CommitContext (which it indeed doesn't do now) when it's not there - and in this case the check for EMPTY would avoid that. But we don't have that at the moment, so I guess we can go with the assumption that 'someone else' sets the CommitContext (as is happening in commit() atm). I guess what I'm saying is that I find both solutions suboptimal, but I'll go for your variant. bq. 2. I see following 3 boolean vars always being set to true good point - now after the dust (of initial development) has settled it's indeed obvious that the variables can be combined into one. bq. 3. Log the limits/config will do bq. 4. Keep the child name as instance variable good idea bq. 5. Use Iterables#addAll. good idea bq. 6. testNull test is failing for me indeed does for me too - that's due to the late-incoming addition of skipping EMPTY bq. May be we should split this class in two. certainly bq. Also some coverage around overflow case would be good to have sure > Collect changes (paths, nts, props..) of a commit in a validator > > > Key: OAK-4907 > URL: https://issues.apache.org/jira/browse/OAK-4907 > Project: Jackrabbit Oak > Issue Type: Technical task > Components: core >Affects Versions: 1.5.11 >Reporter: Stefan Egli >Assignee: Stefan Egli > Fix For: 1.6 > > Attachments: OAK-4907.patch, OAK-4907.v2.patch > > > It would be useful to collect a set of changes of a commit (eg in a > validator) that could later be used in an Observer for eg prefiltering. > Such a change collector should collect paths, nodetypes, properties, > node-names (and perhaps more at a later stage) of all changes and store the > result in the CommitInfo's CommitContext. > Note that this is a result of > [discussions|https://issues.apache.org/jira/browse/OAK-4796?focusedCommentId=15550962=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-15550962] > around design in OAK-4796 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (OAK-4927) FileStore compaction should account for multiple valid checkpoints
[
https://issues.apache.org/jira/browse/OAK-4927?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15568276#comment-15568276
]
Alex Parvulescu commented on OAK-4927:
--
right, simplest fix is to remove the warning (same as OAK-4371), next best
option is to increase the number that triggers this warning to (at least) 4.
Also, I don't think you are supposed to run online compaction on 1.4, it's not
reliable enough.
> FileStore compaction should account for multiple valid checkpoints
> --
>
> Key: OAK-4927
> URL: https://issues.apache.org/jira/browse/OAK-4927
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: segmentmk
>Affects Versions: 1.4
>Reporter: Chetan Mehrotra
>Assignee: Alex Parvulescu
>Priority: Minor
> Labels: candidate_oak_1_4
> Fix For: 1.6
>
>
> With Oak 1.4 we have setup which configure multiple async indexers which lead
> to multiple checkpoint present in the system. OAK-4043 addressed that in
> oak-run. However currently the
> {{org.apache.jackrabbit.oak.plugins.segment.file.FileStore#compact}} logs a
> warning if more than one checkpoint is found.
> {noformat}
> 22:34:21.797 [main] WARN o.a.j.o.p.segment.file.FileStore - TarMK GC #0:
> compaction found 2 checkpoints, you might need to run checkpoint cleanup
> {noformat}
> This warning should be fixed
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (OAK-4926) o.a.j.o.s.s.c.StandbyClientSyncExecution#isLocal should expect missing segment
[
https://issues.apache.org/jira/browse/OAK-4926?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15568265#comment-15568265
]
Timothee Maret commented on OAK-4926:
-
Thanks [~frm] for looking at this and for the suggestion. Please find a
simplified patch attached.
> o.a.j.o.s.s.c.StandbyClientSyncExecution#isLocal should expect missing segment
> --
>
> Key: OAK-4926
> URL: https://issues.apache.org/jira/browse/OAK-4926
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: segment-tar
>Affects Versions: Segment Tar 0.0.14
>Reporter: Timothee Maret
>Assignee: Timothee Maret
> Fix For: Segment Tar 0.0.16
>
> Attachments: OAK-4926.patch, OAK-4926.patch
>
>
> Currently the method
> {{org.apache.jackrabbit.oak.segment.standby.client.StandbyClientSyncExecution#isLocal}}
> does invoke
> {code}
> referencedId.getSegment();
> {code}
> in order to read the referenced segment. In case of missing segment, the
> {{ReferenceId.getSegment}} does throw a SNFE *and* logs an ERROR level
> statement. The SNFE is needed but not the log statement in this case.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (OAK-4926) o.a.j.o.s.s.c.StandbyClientSyncExecution#isLocal should expect missing segment
[
https://issues.apache.org/jira/browse/OAK-4926?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Timothee Maret updated OAK-4926:
Attachment: OAK-4926.patch
> o.a.j.o.s.s.c.StandbyClientSyncExecution#isLocal should expect missing segment
> --
>
> Key: OAK-4926
> URL: https://issues.apache.org/jira/browse/OAK-4926
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: segment-tar
>Affects Versions: Segment Tar 0.0.14
>Reporter: Timothee Maret
>Assignee: Timothee Maret
> Fix For: Segment Tar 0.0.16
>
> Attachments: OAK-4926.patch, OAK-4926.patch
>
>
> Currently the method
> {{org.apache.jackrabbit.oak.segment.standby.client.StandbyClientSyncExecution#isLocal}}
> does invoke
> {code}
> referencedId.getSegment();
> {code}
> in order to read the referenced segment. In case of missing segment, the
> {{ReferenceId.getSegment}} does throw a SNFE *and* logs an ERROR level
> statement. The SNFE is needed but not the log statement in this case.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (OAK-4835) Provide generic option to interrupt online revision cleanup
[ https://issues.apache.org/jira/browse/OAK-4835?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alex Parvulescu resolved OAK-4835. -- Resolution: Fixed Fix Version/s: (was: 1.5.13) 1.5.12 this issue was tracking the api changes needed for the subtasks to be tackled. all the needed changes are in, so marking as fixed (was fixed as a part of 1.5.12, but it did not make the release notes). > Provide generic option to interrupt online revision cleanup > --- > > Key: OAK-4835 > URL: https://issues.apache.org/jira/browse/OAK-4835 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: core >Reporter: Alex Parvulescu >Assignee: Alex Parvulescu > Labels: compaction, gc, management, monitoring > Fix For: 1.6, 1.5.12 > > > JMX binding for stopping a running compaction process -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (OAK-4835) Provide generic option to interrupt online revision cleanup
[ https://issues.apache.org/jira/browse/OAK-4835?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alex Parvulescu reassigned OAK-4835: Assignee: Michael Dürig (was: Alex Parvulescu) > Provide generic option to interrupt online revision cleanup > --- > > Key: OAK-4835 > URL: https://issues.apache.org/jira/browse/OAK-4835 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: core >Reporter: Alex Parvulescu >Assignee: Michael Dürig > Labels: compaction, gc, management, monitoring > Fix For: 1.6, 1.5.12 > > > JMX binding for stopping a running compaction process -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (OAK-4817) QueryEngineSettings without MBean
[ https://issues.apache.org/jira/browse/OAK-4817?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Mueller updated OAK-4817: Attachment: OAK-4817.patch OAK-4817.patch This introduces a new class QueryEngineSettingsMBeanImpl that wraps QueryEngineSettings. And QueryEngineSettings no longer extends AnnotatedStandardMBean (only QueryEngineSettingsMBeanImpl is). There are wrap() and unwrap() methods, to convert a QueryEngineSettings to a QueryEngineSettingsMBeanImpl, and back. [~edivad] and [~chetanm], could you review the patch please? > QueryEngineSettings without MBean > - > > Key: OAK-4817 > URL: https://issues.apache.org/jira/browse/OAK-4817 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: query >Reporter: Thomas Mueller >Assignee: Thomas Mueller > Fix For: 1.6 > > Attachments: OAK-4817.patch > > > QueryEngineSettings is currently an MBean, and constructing a new instance is > expensive. This is seem in some oak-core security components. The MBean > functionality should be decoupled. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (OAK-4467) Upgrade commons-io to 2.5 and remove ReversedLinesFileReader
[
https://issues.apache.org/jira/browse/OAK-4467?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15568162#comment-15568162
]
Julian Reschke commented on OAK-4467:
-
Exactly :-).
> Upgrade commons-io to 2.5 and remove ReversedLinesFileReader
>
>
> Key: OAK-4467
> URL: https://issues.apache.org/jira/browse/OAK-4467
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: auth-external, blob, commons, core, examples, parent,
> pojosr, run, segment-tar, segmentmk, webapp
>Reporter: Michael Dürig
>Assignee: Michael Dürig
> Labels: technical_debt
> Fix For: Segment Tar 0.0.16
>
> Attachments: OAK_4467.patch
>
>
> For OAK-2605 we copied the source of {{ReversedLinesFileReader}} to Oak to
> get the fix for IO-471 in. As this is now fixed in {{commons-io}} 2.5, I
> suggest we upgrade our dependency and remove that duplicated class.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (OAK-4467) Upgrade commons-io to 2.5 and remove ReversedLinesFileReader
[
https://issues.apache.org/jira/browse/OAK-4467?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15568141#comment-15568141
]
Michael Dürig commented on OAK-4467:
I don't think so. This would force all customer still having commons-io 2.4 in
its container to also bump it to 2.5.
> Upgrade commons-io to 2.5 and remove ReversedLinesFileReader
>
>
> Key: OAK-4467
> URL: https://issues.apache.org/jira/browse/OAK-4467
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: auth-external, blob, commons, core, examples, parent,
> pojosr, run, segment-tar, segmentmk, webapp
>Reporter: Michael Dürig
>Assignee: Michael Dürig
> Labels: technical_debt
> Fix For: Segment Tar 0.0.16
>
> Attachments: OAK_4467.patch
>
>
> For OAK-2605 we copied the source of {{ReversedLinesFileReader}} to Oak to
> get the fix for IO-471 in. As this is now fixed in {{commons-io}} 2.5, I
> suggest we upgrade our dependency and remove that duplicated class.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (OAK-4467) Upgrade commons-io to 2.5 and remove ReversedLinesFileReader
[
https://issues.apache.org/jira/browse/OAK-4467?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15568107#comment-15568107
]
Julian Reschke commented on OAK-4467:
-
can't we require commons-io 2.5?
(I'd like to backport so that we can get rid of the workaround in the other
branches...)
> Upgrade commons-io to 2.5 and remove ReversedLinesFileReader
>
>
> Key: OAK-4467
> URL: https://issues.apache.org/jira/browse/OAK-4467
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: auth-external, blob, commons, core, examples, parent,
> pojosr, run, segment-tar, segmentmk, webapp
>Reporter: Michael Dürig
>Assignee: Michael Dürig
> Labels: technical_debt
> Fix For: Segment Tar 0.0.16
>
> Attachments: OAK_4467.patch
>
>
> For OAK-2605 we copied the source of {{ReversedLinesFileReader}} to Oak to
> get the fix for IO-471 in. As this is now fixed in {{commons-io}} 2.5, I
> suggest we upgrade our dependency and remove that duplicated class.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (OAK-4467) Upgrade commons-io to 2.5 and remove ReversedLinesFileReader
[
https://issues.apache.org/jira/browse/OAK-4467?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Dürig updated OAK-4467:
---
Labels: technical_debt (was: candidate_oak_1_2 candidate_oak_1_4
technical_debt)
> Upgrade commons-io to 2.5 and remove ReversedLinesFileReader
>
>
> Key: OAK-4467
> URL: https://issues.apache.org/jira/browse/OAK-4467
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: auth-external, blob, commons, core, examples, parent,
> pojosr, run, segment-tar, segmentmk, webapp
>Reporter: Michael Dürig
>Assignee: Michael Dürig
> Labels: technical_debt
> Fix For: Segment Tar 0.0.16
>
> Attachments: OAK_4467.patch
>
>
> For OAK-2605 we copied the source of {{ReversedLinesFileReader}} to Oak to
> get the fix for IO-471 in. As this is now fixed in {{commons-io}} 2.5, I
> suggest we upgrade our dependency and remove that duplicated class.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (OAK-4467) Upgrade commons-io to 2.5 and remove ReversedLinesFileReader
[
https://issues.apache.org/jira/browse/OAK-4467?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15568097#comment-15568097
]
Michael Dürig commented on OAK-4467:
No, I wouldn't do this as this will break consumers who provide still the old
dependency (commons-io 2.4).
> Upgrade commons-io to 2.5 and remove ReversedLinesFileReader
>
>
> Key: OAK-4467
> URL: https://issues.apache.org/jira/browse/OAK-4467
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: auth-external, blob, commons, core, examples, parent,
> pojosr, run, segment-tar, segmentmk, webapp
>Reporter: Michael Dürig
>Assignee: Michael Dürig
> Labels: candidate_oak_1_2, candidate_oak_1_4, technical_debt
> Fix For: Segment Tar 0.0.16
>
> Attachments: OAK_4467.patch
>
>
> For OAK-2605 we copied the source of {{ReversedLinesFileReader}} to Oak to
> get the fix for IO-471 in. As this is now fixed in {{commons-io}} 2.5, I
> suggest we upgrade our dependency and remove that duplicated class.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (OAK-2605) Support for additional encodings needed in ReversedLinesFileReader
[ https://issues.apache.org/jira/browse/OAK-2605?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15568071#comment-15568071 ] Michael Dürig commented on OAK-2605: ? > Support for additional encodings needed in ReversedLinesFileReader > -- > > Key: OAK-2605 > URL: https://issues.apache.org/jira/browse/OAK-2605 > Project: Jackrabbit Oak > Issue Type: Bug > Components: segmentmk >Affects Versions: 1.1.7 > Environment: Windows 2012 R2 Japanese > Windows 2012 R2 Korean > Windows 2012 R2 Simplified Chinese > Windows 2012 R2 Traditional Chinese >Reporter: Leandro Reis >Assignee: Michael Dürig > Fix For: 1.1.8 > > Attachments: OAK-2605.patch > > > I'm working on a product that uses Commons IO via Jackrabbit Oak. In the > process of testing the launch of such product on Japanese Windows 2012 > Server R2, I came across the following exception: > "(java.io.UnsupportedEncodingException: Encoding windows-31j is not supported > yet (feel free to submit a patch))" > windows-31j is the IANA name for Windows code page 932 (Japanese), and is > returned by Charset.defaultCharset(), used in > org.apache.commons.io.input.ReversedLinesFileReader [0]. > A patch for this issue was provided in > https://issues.apache.org/jira/browse/IO-471 . > It also includes changes needed to support Chinese Simplified, Chinese > Traditional and Korean. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (OAK-4467) Upgrade commons-io to 2.5 and remove ReversedLinesFileReader
[
https://issues.apache.org/jira/browse/OAK-4467?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15568065#comment-15568065
]
Julian Reschke commented on OAK-4467:
-
This should be backported, right?
> Upgrade commons-io to 2.5 and remove ReversedLinesFileReader
>
>
> Key: OAK-4467
> URL: https://issues.apache.org/jira/browse/OAK-4467
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: auth-external, blob, commons, core, examples, parent,
> pojosr, run, segment-tar, segmentmk, webapp
>Reporter: Michael Dürig
>Assignee: Michael Dürig
> Labels: candidate_oak_1_2, candidate_oak_1_4, technical_debt
> Fix For: Segment Tar 0.0.16
>
> Attachments: OAK_4467.patch
>
>
> For OAK-2605 we copied the source of {{ReversedLinesFileReader}} to Oak to
> get the fix for IO-471 in. As this is now fixed in {{commons-io}} 2.5, I
> suggest we upgrade our dependency and remove that duplicated class.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (OAK-4467) Upgrade commons-io to 2.5 and remove ReversedLinesFileReader
[
https://issues.apache.org/jira/browse/OAK-4467?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Julian Reschke updated OAK-4467:
Labels: candidate_oak_1_2 candidate_oak_1_4 technical_debt (was:
technical_debt)
> Upgrade commons-io to 2.5 and remove ReversedLinesFileReader
>
>
> Key: OAK-4467
> URL: https://issues.apache.org/jira/browse/OAK-4467
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: auth-external, blob, commons, core, examples, parent,
> pojosr, run, segment-tar, segmentmk, webapp
>Reporter: Michael Dürig
>Assignee: Michael Dürig
> Labels: candidate_oak_1_2, candidate_oak_1_4, technical_debt
> Fix For: Segment Tar 0.0.16
>
> Attachments: OAK_4467.patch
>
>
> For OAK-2605 we copied the source of {{ReversedLinesFileReader}} to Oak to
> get the fix for IO-471 in. As this is now fixed in {{commons-io}} 2.5, I
> suggest we upgrade our dependency and remove that duplicated class.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (OAK-2605) Support for additional encodings needed in ReversedLinesFileReader
[ https://issues.apache.org/jira/browse/OAK-2605?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15568063#comment-15568063 ] Julian Reschke commented on OAK-2605: - trunk: [r1665898|http://svn.apache.org/r1665898] [r1665833|http://svn.apache.org/r1665833] > Support for additional encodings needed in ReversedLinesFileReader > -- > > Key: OAK-2605 > URL: https://issues.apache.org/jira/browse/OAK-2605 > Project: Jackrabbit Oak > Issue Type: Bug > Components: segmentmk >Affects Versions: 1.1.7 > Environment: Windows 2012 R2 Japanese > Windows 2012 R2 Korean > Windows 2012 R2 Simplified Chinese > Windows 2012 R2 Traditional Chinese >Reporter: Leandro Reis >Assignee: Michael Dürig > Fix For: 1.1.8 > > Attachments: OAK-2605.patch > > > I'm working on a product that uses Commons IO via Jackrabbit Oak. In the > process of testing the launch of such product on Japanese Windows 2012 > Server R2, I came across the following exception: > "(java.io.UnsupportedEncodingException: Encoding windows-31j is not supported > yet (feel free to submit a patch))" > windows-31j is the IANA name for Windows code page 932 (Japanese), and is > returned by Charset.defaultCharset(), used in > org.apache.commons.io.input.ReversedLinesFileReader [0]. > A patch for this issue was provided in > https://issues.apache.org/jira/browse/IO-471 . > It also includes changes needed to support Chinese Simplified, Chinese > Traditional and Korean. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (OAK-4924) avoid CommitInfo==null in contentChanged call in SegmentNodeStore.refresh
[
https://issues.apache.org/jira/browse/OAK-4924?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15568035#comment-15568035
]
Alex Parvulescu commented on OAK-4924:
--
bq. Stefan Egli I think that usage is fine. Similar would be the case if
DocumentNodeStore where external changes are pushed.
[~chetanm] cold you clarify what usage you are referring to? I'm not sure if
you are advocating for adding the empty commit info or against it.
> avoid CommitInfo==null in contentChanged call in SegmentNodeStore.refresh
> -
>
> Key: OAK-4924
> URL: https://issues.apache.org/jira/browse/OAK-4924
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: segmentmk
>Affects Versions: 1.5.12
>Reporter: Stefan Egli
> Fix For: 1.6
>
>
> Currently
> [SegmentNodeStore.refreshHead|https://github.com/apache/jackrabbit-oak/blob/d82f9b21d02a7eaf856f546e778118161d71b760/oak-segment-tar/src/main/java/org/apache/jackrabbit/oak/segment/SegmentNodeStore.java#L231]
> calls {{contentChanged}} with null as the CommitInfo. This is problematic
> for prefiltering (OAK-4796, OAK-4907 et al) as for that a ChangeSet of
> changed items in a commit is stored in the CommitContext in the CommitInfo.
> Thus it would be useful to not send null but a CommitInfo that has the
> equivalent meaning of null but is a new object for each call (so that the
> ChangeSet can be set).
> [~mduerig], [~frm], [~alex.parvulescu] wdyt?
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (OAK-4467) Upgrade commons-io to 2.5 and remove ReversedLinesFileReader
[
https://issues.apache.org/jira/browse/OAK-4467?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Dürig resolved OAK-4467.
Resolution: Fixed
Fix Version/s: (was: Segment Tar 0.0.22)
Segment Tar 0.0.16
Fixed at http://svn.apache.org/viewvc?rev=1764402=rev
> Upgrade commons-io to 2.5 and remove ReversedLinesFileReader
>
>
> Key: OAK-4467
> URL: https://issues.apache.org/jira/browse/OAK-4467
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: auth-external, blob, commons, core, examples, parent,
> pojosr, run, segment-tar, segmentmk, webapp
>Reporter: Michael Dürig
>Assignee: Michael Dürig
> Labels: technical_debt
> Fix For: Segment Tar 0.0.16
>
> Attachments: OAK_4467.patch
>
>
> For OAK-2605 we copied the source of {{ReversedLinesFileReader}} to Oak to
> get the fix for IO-471 in. As this is now fixed in {{commons-io}} 2.5, I
> suggest we upgrade our dependency and remove that duplicated class.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (OAK-4926) o.a.j.o.s.s.c.StandbyClientSyncExecution#isLocal should expect missing segment
[
https://issues.apache.org/jira/browse/OAK-4926?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15568025#comment-15568025
]
Francesco Mari commented on OAK-4926:
-
I think the patch can be further simplified by using
{{FileStore.containsSegment()}} instead. [~marett], can you give a try at this
solution?
> o.a.j.o.s.s.c.StandbyClientSyncExecution#isLocal should expect missing segment
> --
>
> Key: OAK-4926
> URL: https://issues.apache.org/jira/browse/OAK-4926
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: segment-tar
>Affects Versions: Segment Tar 0.0.14
>Reporter: Timothee Maret
>Assignee: Timothee Maret
> Fix For: Segment Tar 0.0.16
>
> Attachments: OAK-4926.patch
>
>
> Currently the method
> {{org.apache.jackrabbit.oak.segment.standby.client.StandbyClientSyncExecution#isLocal}}
> does invoke
> {code}
> referencedId.getSegment();
> {code}
> in order to read the referenced segment. In case of missing segment, the
> {{ReferenceId.getSegment}} does throw a SNFE *and* logs an ERROR level
> statement. The SNFE is needed but not the log statement in this case.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (OAK-4916) Add support for excluding commits to BackgroundObserver
[
https://issues.apache.org/jira/browse/OAK-4916?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15567975#comment-15567975
]
Michael Dürig commented on OAK-4916:
Without looking at the code very much, it seems we are overloading
{{BackgroundObserver}} with too many concerns. That class should only be
concerned about turning a synchronous observer into an asynchronous one. I
would prefer a compositional approach here where a pre filtering observer would
synchronously see all content changes and pass the filtered ones along to the
background observer.
> Add support for excluding commits to BackgroundObserver
> ---
>
> Key: OAK-4916
> URL: https://issues.apache.org/jira/browse/OAK-4916
> Project: Jackrabbit Oak
> Issue Type: Technical task
> Components: core
>Affects Versions: 1.5.11
>Reporter: Stefan Egli
>Assignee: Stefan Egli
> Fix For: 1.6
>
> Attachments: OAK-4916.patch
>
>
> As part of pre-filtering commits it would be useful to have support in the
> BackgroundObserver (in general) that would allow to exclude certain commits
> from being added to the (BackgroundObserver's) queue, thus keeping the queue
> smaller. The actual filtering is up to subclasses.
> The suggested implementation is as follows:
> * a new method {{isExcluded}} is introduced which represents a subclass hook
> for filtering
> * excluded commits are not added to the queue
> * when multiple commits are excluded subsequently, this is collapsed
> * the first non-excluded commit (ContentChange) added to the queue is marked
> with the last non-excluded root state as the 'previous root'
> * downstream Observers are notified of the exclusion of a commit via a
> special CommitInfo {{NOOP_CHANGE}}: this instructs it to exclude this change
> while at the same time 'fast-forwarding' the root state to the new one.
> ** this extra token is one way of solving the problem that
> {{Observer.contentChanged}} represents a diff between two states but does not
> transport the 'from' state explicitly - that is implicitly taken from the
> previous call to {{contentChanged}}. Thus using such a gap token
> ({{NOOP_CHANGE}}) seems to be the only way to instruct Observers to skip a
> change.
> To repeat: whoever extends BackgroundObserver with filtering must be aware of
> the new {{NOOP_CHANGE}} token. Anyone not doing filtering will not get any
> {{NOOP_CHANGE}} tokens though.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (OAK-4916) Add support for excluding commits to BackgroundObserver
[
https://issues.apache.org/jira/browse/OAK-4916?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15567937#comment-15567937
]
Chetan Mehrotra edited comment on OAK-4916 at 10/12/16 7:39 AM:
Somehow not very comfortable with {{NOOP_CHANGE}} based protocol for
communicating filtering.
May be we introduce new interfaces
# ContentChangeFilter - This would be passed to {{BackgroundObserver}} and
would be responsible for determining if given change should be included in the
queue or not. By default {{BackgroundObserver}} would
{{ContentChangeFilter#DEFAULT}}. Observers which support prefiltering would
provide there own implementation. This is similar to current proposed approach
just using composition over inheritence!
{code}
public interface ContentChangeFilter {
ContentChangeFilter DEFAULT = new ContentChangeFilter() {
@Override
public boolean includeChange(CommitInfo info) {
return true
}
};
boolean includeChange(CommitInfo info);
}
{code}
# FilteringAwareObserver - Any observer which allows prefiltering would also
implement this interface. And instead of {{NOOP_CHANGE}} based convention
{{BackgroundObserver}} would invoke the {{resetPreviousRoot}} to indicate that
base root state needs to be adjusted.
{code}
public interface FilteringAwareObserver extends Observer{
/**
* Invoked to enable such observers to reset there previous root
* to given NodeState
*
* @param root previous NodeState root
*/
void resetPreviousRoot(NodeState root);
}
{code}
Another approach would be to make such observer state less i.e. they do not
track the previous state and we pass in previous state and
{{BackgroundObserver}} maintains a tuple
{code}
void contentChanged(@Nullable NodeState before, @Nonnull NodeState after,
@Nullable CommitInfo info);
{code}
[~mduerig] Would have better thoughts here ;)
was (Author: chetanm):
Somehow not very comfortable with {{NOOP_CHANGE}} based protocol for
communicating filtering.
May be we introduce new interfaces
# ContentChangeFilter - This would be passed to {{BackgroundObserver}} and
would be responsible for determining if given change should be included in the
queue or not. By default {{BackgroundObserver}} would
{{ContentChangeFilter#DEFAULT}}. Observers which support prefiltering would
provide there own implementation. Kind of composition over inheritence
{code}
public interface ContentChangeFilter {
ContentChangeFilter DEFAULT = new ContentChangeFilter() {
@Override
public boolean includeChange(CommitInfo info) {
return true
}
};
boolean includeChange(CommitInfo info);
}
{code}
# FilteringAwareObserver - Any observer which allows prefiltering would also
implement this interface. And instead of {{NOOP_CHANGE}} based convention
{{BackgroundObserver}} would invoke the {{resetPreviousRoot}} to indicate that
base root state needs to be adjusted.
{code}
public interface FilteringAwareObserver extends Observer{
/**
* Invoked to enable such observers to reset there previous root
* to given NodeState
*
* @param root previous NodeState root
*/
void resetPreviousRoot(NodeState root);
}
{code}
Another approach would be to make such observer state less i.e. they do not
track the previous state and we pass in previous state and
{{BackgroundObserver}} maintains a tuple
{code}
void contentChanged(@Nullable NodeState before, @Nonnull NodeState after,
@Nullable CommitInfo info);
{code}
[~mduerig] Would have better thoughts here ;)
> Add support for excluding commits to BackgroundObserver
> ---
>
> Key: OAK-4916
> URL: https://issues.apache.org/jira/browse/OAK-4916
> Project: Jackrabbit Oak
> Issue Type: Technical task
> Components: core
>Affects Versions: 1.5.11
>Reporter: Stefan Egli
>Assignee: Stefan Egli
> Fix For: 1.6
>
> Attachments: OAK-4916.patch
>
>
> As part of pre-filtering commits it would be useful to have support in the
> BackgroundObserver (in general) that would allow to exclude certain commits
> from being added to the (BackgroundObserver's) queue, thus keeping the queue
> smaller. The actual filtering is up to subclasses.
> The suggested implementation is as follows:
> * a new method {{isExcluded}} is introduced which represents a subclass hook
> for filtering
> * excluded commits are not added to the queue
> * when multiple commits are excluded subsequently, this is collapsed
> * the first non-excluded commit (ContentChange) added to the queue is marked
> with the last non-excluded root state as the 'previous root'
> * downstream Observers are notified of the exclusion of a commit via a
> special CommitInfo
[jira] [Commented] (OAK-4916) Add support for excluding commits to BackgroundObserver
[
https://issues.apache.org/jira/browse/OAK-4916?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15567937#comment-15567937
]
Chetan Mehrotra commented on OAK-4916:
--
Somehow not very comfortable with {{NOOP_CHANGE}} based protocol for
communicating filtering.
May be we introduce new interfaces
# ContentChangeFilter - This would be passed to {{BackgroundObserver}} and
would be responsible for determining if given change should be included in the
queue or not. By default {{BackgroundObserver}} would
{{ContentChangeFilter#DEFAULT}}. Observers which support prefiltering would
provide there own implementation. Kind of composition over inheritence
{code}
public interface ContentChangeFilter {
ContentChangeFilter DEFAULT = new ContentChangeFilter() {
@Override
public boolean includeChange(CommitInfo info) {
return true
}
};
boolean includeChange(CommitInfo info);
}
{code}
# FilteringAwareObserver - Any observer which allows prefiltering would also
implement this interface. And instead of {{NOOP_CHANGE}} based convention
{{BackgroundObserver}} would invoke the {{resetPreviousRoot}} to indicate that
base root state needs to be adjusted.
{code}
public interface FilteringAwareObserver extends Observer{
/**
* Invoked to enable such observers to reset there previous root
* to given NodeState
*
* @param root previous NodeState root
*/
void resetPreviousRoot(NodeState root);
}
{code}
Another approach would be to make such observer state less i.e. they do not
track the previous state and we pass in previous state and
{{BackgroundObserver}} maintains a tuple
{code}
void contentChanged(@Nullable NodeState before, @Nonnull NodeState after,
@Nullable CommitInfo info);
{code}
[~mduerig] Would have better thoughts here ;)
> Add support for excluding commits to BackgroundObserver
> ---
>
> Key: OAK-4916
> URL: https://issues.apache.org/jira/browse/OAK-4916
> Project: Jackrabbit Oak
> Issue Type: Technical task
> Components: core
>Affects Versions: 1.5.11
>Reporter: Stefan Egli
>Assignee: Stefan Egli
> Fix For: 1.6
>
> Attachments: OAK-4916.patch
>
>
> As part of pre-filtering commits it would be useful to have support in the
> BackgroundObserver (in general) that would allow to exclude certain commits
> from being added to the (BackgroundObserver's) queue, thus keeping the queue
> smaller. The actual filtering is up to subclasses.
> The suggested implementation is as follows:
> * a new method {{isExcluded}} is introduced which represents a subclass hook
> for filtering
> * excluded commits are not added to the queue
> * when multiple commits are excluded subsequently, this is collapsed
> * the first non-excluded commit (ContentChange) added to the queue is marked
> with the last non-excluded root state as the 'previous root'
> * downstream Observers are notified of the exclusion of a commit via a
> special CommitInfo {{NOOP_CHANGE}}: this instructs it to exclude this change
> while at the same time 'fast-forwarding' the root state to the new one.
> ** this extra token is one way of solving the problem that
> {{Observer.contentChanged}} represents a diff between two states but does not
> transport the 'from' state explicitly - that is implicitly taken from the
> previous call to {{contentChanged}}. Thus using such a gap token
> ({{NOOP_CHANGE}}) seems to be the only way to instruct Observers to skip a
> change.
> To repeat: whoever extends BackgroundObserver with filtering must be aware of
> the new {{NOOP_CHANGE}} token. Anyone not doing filtering will not get any
> {{NOOP_CHANGE}} tokens though.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (OAK-4924) avoid CommitInfo==null in contentChanged call in SegmentNodeStore.refresh
[
https://issues.apache.org/jira/browse/OAK-4924?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15567829#comment-15567829
]
Chetan Mehrotra commented on OAK-4924:
--
[~egli] I think that usage is fine. Similar would be the case if
DocumentNodeStore where external changes are pushed.
And in any case from this call onwards the CommitInfo should not be modified
and mutable state should be build up at time of commit itself. And that is done
in the {{merge}} call where commit info is passed from caller code and for JCR
commits the MutableRoot sets up the CommitContext
> avoid CommitInfo==null in contentChanged call in SegmentNodeStore.refresh
> -
>
> Key: OAK-4924
> URL: https://issues.apache.org/jira/browse/OAK-4924
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: segmentmk
>Affects Versions: 1.5.12
>Reporter: Stefan Egli
> Fix For: 1.6
>
>
> Currently
> [SegmentNodeStore.refreshHead|https://github.com/apache/jackrabbit-oak/blob/d82f9b21d02a7eaf856f546e778118161d71b760/oak-segment-tar/src/main/java/org/apache/jackrabbit/oak/segment/SegmentNodeStore.java#L231]
> calls {{contentChanged}} with null as the CommitInfo. This is problematic
> for prefiltering (OAK-4796, OAK-4907 et al) as for that a ChangeSet of
> changed items in a commit is stored in the CommitContext in the CommitInfo.
> Thus it would be useful to not send null but a CommitInfo that has the
> equivalent meaning of null but is a new object for each call (so that the
> ChangeSet can be set).
> [~mduerig], [~frm], [~alex.parvulescu] wdyt?
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (OAK-4907) Collect changes (paths, nts, props..) of a commit in a validator
[
https://issues.apache.org/jira/browse/OAK-4907?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15567808#comment-15567808
]
Chetan Mehrotra commented on OAK-4907:
--
Patch looks good and test coverage is good!.
Some minor comments
# Instead of special casing for EMPTY it would be better to check if the
{{CommitInfo}} has {{CommitContext}} set. If yes then validator can opt in
otherwise opt out. And then {{CollectorSupport}} can just refer to
{{CommitContext}}
{code}
if (info == null || info == CommitInfo.EMPTY) {
// then we cannot do change-collecting, as we can't store
// it in the info
return null;
}
{code}
# I see following 3 boolean vars always being set to true. May be replace 3
with single var like {{changed}}
{code}
// record a change at the current path (which is the
parent of this property)
addParentPathOnLeave = true;
// and with the current node name
addParentNodeNameOnLeave = true;
// additionally, add parent's nodeType on leave too
addParentNodeTypeOnLeave = true;
{code}
# Log the limits/config at info level in activate method
# Keep the child name as instance variable to avoid computing it again
{code}
if (addParentNodeNameOnLeave) {
support.getParentNodeNames().add(getName(path));
}
{code}
# Use {{Iterables#addAll}}. This avoid creating unnecessary list instance and
is bit optimized for collection based iterable (which is the case here). Doing
all this would ensure that overhead of validator is minimal!
{code}
support.getParentNodeTypes().addAll(Lists.newArrayList(parentNodeOrNull.getNames("jcr:mixinTypes")));
{code}
# {{testNull}} test is failing for me
h4. ChangeSet
May be we should split this class in two.
*ChangeSetBuilder*
{code}
public class ChangeSetBuilder {
private final int maxItems;
private final int maxPathDepth;
private final Set parentPaths = Sets.newHashSet();
private boolean parentPathOverflow;
public ChangeSetBuilder(int maxItems, int maxPathDepth) {
this.maxItems = maxItems;
this.maxPathDepth = maxPathDepth;
}
public ChangeSetBuilder addParentPath(String path){
if (parentPaths.size() > maxItems){
parentPathOverflow = true;
parentPaths.clear();
}
if (!parentPathOverflow) {
parentPaths.add(path);
}
return this;
}
public ChangeSet build(){
return new ChangeSet(...)
}
}
{code}
This class
* Just collects the changes and take care of limits
* Is mutable
* Used by Validator and not to be used by clients
*ChangeSet*
{code}
public class ChangeSet {
@CheckForNull
public Set getParentPaths() {
}
}
{code}
* Immutable class
* Has accessors marked with {{CheckForNull}}. With null being an indication
that this information was not collected and observer should do the hard work
{noformat}
* To limit memory usage, the ChangeSet has a limit on the number of items,
each,
* that it collects. If one of those items reach the limit this is called
* an 'overflow' and the corresponding item type is marked as having
'overflown'.
* Downstream Observers should thus check if a particular item has overflown
* or not.
{noformat}
This can be updated to indicate "how" overflow case can be determined i.e. by
checking if the set returned is null
Also some coverage around overflow case would be good to have
> Collect changes (paths, nts, props..) of a commit in a validator
>
>
> Key: OAK-4907
> URL: https://issues.apache.org/jira/browse/OAK-4907
> Project: Jackrabbit Oak
> Issue Type: Technical task
> Components: core
>Affects Versions: 1.5.11
>Reporter: Stefan Egli
>Assignee: Stefan Egli
> Fix For: 1.6
>
> Attachments: OAK-4907.patch, OAK-4907.v2.patch
>
>
> It would be useful to collect a set of changes of a commit (eg in a
> validator) that could later be used in an Observer for eg prefiltering.
> Such a change collector should collect paths, nodetypes, properties,
> node-names (and perhaps more at a later stage) of all changes and store the
> result in the CommitInfo's CommitContext.
> Note that this is a result of
> [discussions|https://issues.apache.org/jira/browse/OAK-4796?focusedCommentId=15550962=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-15550962]
> around design in OAK-4796
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (OAK-4927) FileStore compaction should account for multiple valid checkpoints
[
https://issues.apache.org/jira/browse/OAK-4927?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15567806#comment-15567806
]
Michael Dürig commented on OAK-4927:
For Segment Tar we removed that check and the warning that goes along with it.
See OAK-4371.
> FileStore compaction should account for multiple valid checkpoints
> --
>
> Key: OAK-4927
> URL: https://issues.apache.org/jira/browse/OAK-4927
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: segmentmk
>Affects Versions: 1.4
>Reporter: Chetan Mehrotra
>Assignee: Alex Parvulescu
>Priority: Minor
> Labels: candidate_oak_1_4
> Fix For: 1.6
>
>
> With Oak 1.4 we have setup which configure multiple async indexers which lead
> to multiple checkpoint present in the system. OAK-4043 addressed that in
> oak-run. However currently the
> {{org.apache.jackrabbit.oak.plugins.segment.file.FileStore#compact}} logs a
> warning if more than one checkpoint is found.
> {noformat}
> 22:34:21.797 [main] WARN o.a.j.o.p.segment.file.FileStore - TarMK GC #0:
> compaction found 2 checkpoints, you might need to run checkpoint cleanup
> {noformat}
> This warning should be fixed
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (OAK-4902) Blob GC completion time should be logged in millis
[ https://issues.apache.org/jira/browse/OAK-4902?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Amit Jain resolved OAK-4902. Resolution: Fixed Fix Version/s: 1.5.13 Done with http://svn.apache.org/viewvc?rev=1764388=rev > Blob GC completion time should be logged in millis > -- > > Key: OAK-4902 > URL: https://issues.apache.org/jira/browse/OAK-4902 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: blob >Reporter: Amit Jain >Assignee: Amit Jain >Priority: Minor > Fix For: 1.6, 1.5.13 > > > MarkSweepGarbageCollector logs the completion time with changing units > depending on the time taken - ms, s, min, h etc. This makes it difficult to > write scripts to grep the completion time. So, additionally the completion > time should also log in milliseconds. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (OAK-4827) Backport OAK-3415 into 1.2.x
[ https://issues.apache.org/jira/browse/OAK-4827?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15567723#comment-15567723 ] Chetan Mehrotra commented on OAK-4827: -- [~dominique.jaeggi] Going forward it would be helpful if we can also update the fix version field in issue being backported Also unless backport involves lots of work we can avoid opening separate task for backport work. This reduces noise in release notes > Backport OAK-3415 into 1.2.x > > > Key: OAK-4827 > URL: https://issues.apache.org/jira/browse/OAK-4827 > Project: Jackrabbit Oak > Issue Type: Task > Components: core >Affects Versions: 1.2.19 >Reporter: Alex COLLIGNON >Assignee: Dominique Jäggi > Fix For: 1.2.20 > > > The ask is to backport the log improvement tracked under OAK-3415 into the > 1.2.x branch. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (OAK-3415) AccessControlValidator: checkValidAccessControlledNode should mention node name in error message
[
https://issues.apache.org/jira/browse/OAK-3415?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Chetan Mehrotra updated OAK-3415:
-
Fix Version/s: 1.2.20
> AccessControlValidator: checkValidAccessControlledNode should mention node
> name in error message
>
>
> Key: OAK-3415
> URL: https://issues.apache.org/jira/browse/OAK-3415
> Project: Jackrabbit Oak
> Issue Type: Wish
> Components: core
>Reporter: Axel Hanikel
>Assignee: angela
>Priority: Minor
> Fix For: 1.4, 1.3.9, 1.2.20
>
> Attachments: OAK-3415.patch
>
>
> In order to make troubleshooting easier, the
> {{AccessControlValidator#checkValidAccessControlledNode}} should mention the
> offending node name in the error message.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
