[jira] [Commented] (JCRVLT-378) WorkspaceFilter.contains return false negative
[
https://issues.apache.org/jira/browse/JCRVLT-378?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16934694#comment-16934694
]
Mark Adamcin commented on JCRVLT-378:
-
Ah, I see what you mean. Based on the page you linked, it does appear that
there should be a special case for using only relative path patterns, which
just requires that the first character is not a {{/}}. Does this work?
{code:java}
{code}
I guess this is more of a special "ACL export" case, as described in the
comment in AggregateImpl:
{color:#808080}// otherwise create sub node and collect items if needed
{color}{color:#808080}// but only if the node is either an ancestor or is
included
{color}{color:#808080}// or if the workspace filter set contains relative
pattern (ACL export case).{color}
Looking at AggregateImpl.getArtifacts(), it appears this might not collect
{{_rep_policy.xml}} files, and instead only collect {{.content.xml}} files, so
maybe this would also require some docview refactoring to actually include the
ACLs that you are intending to include.
{code:java}
public ArtifactSet getArtifacts() throws RepositoryException {
if (artifacts == null) {
assertAttached();
load();
artifacts = (ArtifactSetImpl) aggregator.createArtifacts(this);
if (filterArtifacts) {
// filter out all non-directory and non .content.xml artifacts
ArtifactSetImpl na = new ArtifactSetImpl();
na.addAll(artifacts);
for (Artifact a: na.values()) {
if (a.getType() != ArtifactType.DIRECTORY) {
if
(!".content.xml".equals(Text.getName(a.getPlatformPath( {
artifacts.remove(a);
}
}
}
}
}
return artifacts;
{code}
> WorkspaceFilter.contains return false negative
> --
>
> Key: JCRVLT-378
> URL: https://issues.apache.org/jira/browse/JCRVLT-378
> Project: Jackrabbit FileVault
> Issue Type: Bug
> Components: vlt
>Reporter: Konrad Windszus
>Priority: Major
>
> For this workspace filter
> {code}
>
>
>
>
> {code}
> The call of {{WorkspaceFilter.contains("/var/acs-commons")}} returns
> {{false}}.
> This is unexpected because this is the root path itself.
> So this node should be installed (including all direct properties) and only
> sub nodes are being filtered with the includes/excludes.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Comment Edited] (JCRVLT-378) WorkspaceFilter.contains return false negative
[
https://issues.apache.org/jira/browse/JCRVLT-378?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16934619#comment-16934619
]
Konrad Windszus edited comment on JCRVLT-378 at 9/20/19 6:07 PM:
-
HI [~madamcin]
Thanks for your input. I was aware of the implicit exclude, but it is
explicitly stated in
https://jackrabbit.apache.org/filevault/filter.html#Usage_for_Export
bq. It is important to know, that only the nodes that match the filter are
actually traversed, which can lead to unexpected results.
So I would expect that in case {{filter.contains("/var/acs-commons")}} returns
{{false}}. for above filter it would not descend into child nodes because the
parent node does not match in the first place.
That would mean that in almost all cases I would have to add for a whitelisting
pattern the root node path itself as first include to make sure the child
nodes are really included in the export.
was (Author: kwin):
HI [~madamcin]
Thanks for your input. I was aware of the implicit exclude, but it is
explicitly stated in
https://jackrabbit.apache.org/filevault/filter.html#Usage_for_Export
bq. It is important to know, that only the nodes that match the filter are
actually traversed, which can lead to unexpected results.
So I would expect that in case {{filter.contains("/var/acs-commons")}} returns
{{false}}. for above filter it would not descend into child nodes because the
parent node does not match in the first place.
> WorkspaceFilter.contains return false negative
> --
>
> Key: JCRVLT-378
> URL: https://issues.apache.org/jira/browse/JCRVLT-378
> Project: Jackrabbit FileVault
> Issue Type: Bug
> Components: vlt
>Reporter: Konrad Windszus
>Priority: Major
>
> For this workspace filter
> {code}
>
>
>
>
> {code}
> The call of {{WorkspaceFilter.contains("/var/acs-commons")}} returns
> {{false}}.
> This is unexpected because this is the root path itself.
> So this node should be installed (including all direct properties) and only
> sub nodes are being filtered with the includes/excludes.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (JCRVLT-378) WorkspaceFilter.contains return false negative
[
https://issues.apache.org/jira/browse/JCRVLT-378?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16934619#comment-16934619
]
Konrad Windszus commented on JCRVLT-378:
HI [~madamcin]
Thanks for your input. I was aware of the implicit exclude, but it is
explicitly stated in
https://jackrabbit.apache.org/filevault/filter.html#Usage_for_Export
bq. It is important to know, that only the nodes that match the filter are
actually traversed, which can lead to unexpected results.
So I would expect that in case {{filter.contains("/var/acs-commons")}} returns
{{false}}. for above filter it would not descend into child nodes because the
parent node does not match in the first place.
> WorkspaceFilter.contains return false negative
> --
>
> Key: JCRVLT-378
> URL: https://issues.apache.org/jira/browse/JCRVLT-378
> Project: Jackrabbit FileVault
> Issue Type: Bug
> Components: vlt
>Reporter: Konrad Windszus
>Priority: Major
>
> For this workspace filter
> {code}
>
>
>
>
> {code}
> The call of {{WorkspaceFilter.contains("/var/acs-commons")}} returns
> {{false}}.
> This is unexpected because this is the root path itself.
> So this node should be installed (including all direct properties) and only
> sub nodes are being filtered with the includes/excludes.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Comment Edited] (JCRVLT-378) WorkspaceFilter.contains return false negative
[
https://issues.apache.org/jira/browse/JCRVLT-378?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16934596#comment-16934596
]
Mark Adamcin edited comment on JCRVLT-378 at 9/20/19 5:23 PM:
--
[~kwin] I think this might be a wider convention for fuzzy default include
behavior.
It uses the opposite type of the first include/exclude as the default return
value. I believe this is done to eliminate boilerplate
elements when the intent was to include only specific descendants of a filtered
root.
The specific line with this effect is
{{boolean result = !entries.get(0).include;}}
{code:java}
/**
* Evaluates the filters if this set does {@link #covers(String) cover} the
* given item. otherwise {@code false} is returned.
* The result of the evaluation is the polarity of the last matched path.
* If no filter matches it returns {@code true}
* if the first filter is an exclude filter or if no filter is defined;
* {@code false} if the first filter is an include filter.
*
* @param path the path to check
* @return {@code true} if this set matches the item
*/
public boolean contains(@Nonnull String path) {
if (!covers(path)) {
return false;
}
List> entries = getEntries();
if (entries.isEmpty()) {
return true;
} else {
boolean result = !entries.get(0).include;
for (Entry entry: entries) {
if (entry.filter.matches(path)) {
result = entry.include;
}
}
return result;
}
}
{code}
was (Author: madamcin):
[~kwin] I think this might be a wider convention for fuzzy default include
behavior.
It uses the opposite type of the first include/exclude as the default return
value. I believe this is done to eliminate boilerplate
elements when the intent was to include only specific descendants of a filtered
root.
The specific line with this effect is `boolean result =
!entries.get(0).include;`
{code:java}
/**
* Evaluates the filters if this set does {@link #covers(String) cover} the
* given item. otherwise {@code false} is returned.
* The result of the evaluation is the polarity of the last matched path.
* If no filter matches it returns {@code true}
* if the first filter is an exclude filter or if no filter is defined;
* {@code false} if the first filter is an include filter.
*
* @param path the path to check
* @return {@code true} if this set matches the item
*/
public boolean contains(@Nonnull String path) {
if (!covers(path)) {
return false;
}
List> entries = getEntries();
if (entries.isEmpty()) {
return true;
} else {
boolean result = !entries.get(0).include;
for (Entry entry: entries) {
if (entry.filter.matches(path)) {
result = entry.include;
}
}
return result;
}
}
{code}
> WorkspaceFilter.contains return false negative
> --
>
> Key: JCRVLT-378
> URL: https://issues.apache.org/jira/browse/JCRVLT-378
> Project: Jackrabbit FileVault
> Issue Type: Bug
> Components: vlt
>Reporter: Konrad Windszus
>Priority: Major
>
> For this workspace filter
> {code}
>
>
>
>
> {code}
> The call of {{WorkspaceFilter.contains("/var/acs-commons")}} returns
> {{false}}.
> This is unexpected because this is the root path itself.
> So this node should be installed (including all direct properties) and only
> sub nodes are being filtered with the includes/excludes.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Comment Edited] (JCRVLT-378) WorkspaceFilter.contains return false negative
[
https://issues.apache.org/jira/browse/JCRVLT-378?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16934596#comment-16934596
]
Mark Adamcin edited comment on JCRVLT-378 at 9/20/19 5:22 PM:
--
[~kwin] I think this might be a wider convention for fuzzy default include
behavior.
It uses the opposite type of the first include/exclude as the default return
value. I believe this is done to eliminate boilerplate
elements when the intent was to include only specific descendants of a filtered
root.
The specific line with this effect is `boolean result =
!entries.get(0).include;`
{code:java}
/**
* Evaluates the filters if this set does {@link #covers(String) cover} the
* given item. otherwise {@code false} is returned.
* The result of the evaluation is the polarity of the last matched path.
* If no filter matches it returns {@code true}
* if the first filter is an exclude filter or if no filter is defined;
* {@code false} if the first filter is an include filter.
*
* @param path the path to check
* @return {@code true} if this set matches the item
*/
public boolean contains(@Nonnull String path) {
if (!covers(path)) {
return false;
}
List> entries = getEntries();
if (entries.isEmpty()) {
return true;
} else {
boolean result = !entries.get(0).include;
for (Entry entry: entries) {
if (entry.filter.matches(path)) {
result = entry.include;
}
}
return result;
}
}
{code}
was (Author: madamcin):
[~kwin] I think this might be a wider convention for fuzzy default include
behavior.
It uses the opposite type of the first include/exclude as the default return
value. I believe this is done to eliminate boilerplate
elements when the intent was to include only specific descendants of a filtered
root.
{code:java}
/**
* Evaluates the filters if this set does {@link #covers(String) cover} the
* given item. otherwise {@code false} is returned.
* The result of the evaluation is the polarity of the last matched path.
* If no filter matches it returns {@code true}
* if the first filter is an exclude filter or if no filter is defined;
* {@code false} if the first filter is an include filter.
*
* @param path the path to check
* @return {@code true} if this set matches the item
*/
public boolean contains(@Nonnull String path) {
if (!covers(path)) {
return false;
}
List> entries = getEntries();
if (entries.isEmpty()) {
return true;
} else {
boolean result = !entries.get(0).include;
for (Entry entry: entries) {
if (entry.filter.matches(path)) {
result = entry.include;
}
}
return result;
}
}
{code}
> WorkspaceFilter.contains return false negative
> --
>
> Key: JCRVLT-378
> URL: https://issues.apache.org/jira/browse/JCRVLT-378
> Project: Jackrabbit FileVault
> Issue Type: Bug
> Components: vlt
>Reporter: Konrad Windszus
>Priority: Major
>
> For this workspace filter
> {code}
>
>
>
>
> {code}
> The call of {{WorkspaceFilter.contains("/var/acs-commons")}} returns
> {{false}}.
> This is unexpected because this is the root path itself.
> So this node should be installed (including all direct properties) and only
> sub nodes are being filtered with the includes/excludes.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (JCRVLT-378) WorkspaceFilter.contains return false negative
[
https://issues.apache.org/jira/browse/JCRVLT-378?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16934596#comment-16934596
]
Mark Adamcin commented on JCRVLT-378:
-
[~kwin] I think this might be a wider convention for fuzzy default include
behavior.
It uses the opposite type of the first include/exclude as the default return
value. I believe this is done to eliminate boilerplate
elements when the intent was to include only specific descendants of a filtered
root.
{code:java}
/**
* Evaluates the filters if this set does {@link #covers(String) cover} the
* given item. otherwise {@code false} is returned.
* The result of the evaluation is the polarity of the last matched path.
* If no filter matches it returns {@code true}
* if the first filter is an exclude filter or if no filter is defined;
* {@code false} if the first filter is an include filter.
*
* @param path the path to check
* @return {@code true} if this set matches the item
*/
public boolean contains(@Nonnull String path) {
if (!covers(path)) {
return false;
}
List> entries = getEntries();
if (entries.isEmpty()) {
return true;
} else {
boolean result = !entries.get(0).include;
for (Entry entry: entries) {
if (entry.filter.matches(path)) {
result = entry.include;
}
}
return result;
}
}
{code}
> WorkspaceFilter.contains return false negative
> --
>
> Key: JCRVLT-378
> URL: https://issues.apache.org/jira/browse/JCRVLT-378
> Project: Jackrabbit FileVault
> Issue Type: Bug
> Components: vlt
>Reporter: Konrad Windszus
>Priority: Major
>
> For this workspace filter
> {code}
>
>
>
>
> {code}
> The call of {{WorkspaceFilter.contains("/var/acs-commons")}} returns
> {{false}}.
> This is unexpected because this is the root path itself.
> So this node should be installed (including all direct properties) and only
> sub nodes are being filtered with the includes/excludes.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (JCRVLT-378) WorkspaceFilter.contains return false negative
[
https://issues.apache.org/jira/browse/JCRVLT-378?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16934526#comment-16934526
]
Konrad Windszus commented on JCRVLT-378:
[~tripod] WDYT?
> WorkspaceFilter.contains return false negative
> --
>
> Key: JCRVLT-378
> URL: https://issues.apache.org/jira/browse/JCRVLT-378
> Project: Jackrabbit FileVault
> Issue Type: Bug
> Components: vlt
>Reporter: Konrad Windszus
>Priority: Major
>
> For this workspace filter
> {code}
>
>
>
>
> {code}
> The call of {{WorkspaceFilter.contains("/var/acs-commons")}} returns
> {{false}}.
> This is unexpected because this is the root path itself.
> So this node should be installed (including all direct properties) and only
> sub nodes are being filtered with the includes/excludes.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (JCRVLT-378) WorkspaceFilter.contains return false negative
Konrad Windszus created JCRVLT-378:
--
Summary: WorkspaceFilter.contains return false negative
Key: JCRVLT-378
URL: https://issues.apache.org/jira/browse/JCRVLT-378
Project: Jackrabbit FileVault
Issue Type: Bug
Components: vlt
Reporter: Konrad Windszus
For this workspace filter
{code}
{code}
The call of {{WorkspaceFilter.contains("/var/acs-commons")}} returns {{false}}.
This is unexpected because this is the root path itself.
So this node should be installed (including all direct properties) and only sub
nodes are being filtered with the includes/excludes.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (JCRVLT-374) assembling a content-package consumes much memory
[
https://issues.apache.org/jira/browse/JCRVLT-374?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16934421#comment-16934421
]
Mark Adamcin commented on JCRVLT-374:
-
[~joerghoh] I attached a prototype patch that simply adds the includes. I don't
have time at the moment to fully reproduce the behavior locally, so I hope it
works :)
> assembling a content-package consumes much memory
> -
>
> Key: JCRVLT-374
> URL: https://issues.apache.org/jira/browse/JCRVLT-374
> Project: Jackrabbit FileVault
> Issue Type: Improvement
> Components: Packaging
>Affects Versions: 3.2.8
>Reporter: Jörg Hoh
>Priority: Major
> Attachments: JCRVLT-374-proto.patch, filevault.log.gz
>
>
> I came across a situation that packaging a huge subtree
> (/jcr:system/jcr:versionStorage) (bad idea, I know) caused a huge spike in
> memory usage, which caused lots of FullGCs (due to AllocationFailures).
> I have several stacktraces from that time, which all look very similar to
> this one:
> {noformat}
> qtp1597826410-38130" prio=5 tid=0x94f2 nid=0x runnable
>java.lang.Thread.State: RUNNABLE
> at
> org.apache.jackrabbit.oak.segment.SegmentNodeBuilder.createChildBuilder(SegmentNodeBuilder.java:147)
> at
> org.apache.jackrabbit.oak.plugins.memory.MemoryNodeBuilder.getChildNode(MemoryNodeBuilder.java:330)
> at
> org.apache.jackrabbit.oak.core.SecureNodeBuilder.(SecureNodeBuilder.java:110)
> at
> org.apache.jackrabbit.oak.core.SecureNodeBuilder.getChildNode(SecureNodeBuilder.java:327)
> at
> org.apache.jackrabbit.oak.core.MutableTree.getTree(MutableTree.java:288)
> at
> org.apache.jackrabbit.oak.core.MutableRoot.getTree(MutableRoot.java:220)
> at
> org.apache.jackrabbit.oak.core.MutableRoot.getTree(MutableRoot.java:69)
> at
> org.apache.jackrabbit.oak.jcr.session.WorkspaceImpl$1.getTypes(WorkspaceImpl.java:85)
> at
> org.apache.jackrabbit.oak.plugins.nodetype.ReadOnlyNodeTypeManager.isNodeType(ReadOnlyNodeTypeManager.java:293)
> at
> org.apache.jackrabbit.oak.jcr.session.NodeImpl$24.perform(NodeImpl.java:931)
> at
> org.apache.jackrabbit.oak.jcr.session.NodeImpl$24.perform(NodeImpl.java:926)
> 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.isNodeType(NodeImpl.java:926)
> at
> org.apache.jackrabbit.vault.fs.impl.aggregator.FileAggregator.matches(FileAggregator.java:66)
> at
> org.apache.jackrabbit.vault.fs.impl.AggregatorProvider.getAggregator(AggregatorProvider.java:68)
> at
> org.apache.jackrabbit.vault.fs.impl.AggregateManagerImpl.getAggregator(AggregateManagerImpl.java:455)
> at
> org.apache.jackrabbit.vault.fs.impl.AggregateImpl.prepare(AggregateImpl.java:720)
> at
> org.apache.jackrabbit.vault.fs.impl.AggregateImpl.prepare(AggregateImpl.java:733)
> at
> org.apache.jackrabbit.vault.fs.impl.AggregateImpl.prepare(AggregateImpl.java:733)
> at
> org.apache.jackrabbit.vault.fs.impl.AggregateImpl.prepare(AggregateImpl.java:733)
> at
> org.apache.jackrabbit.vault.fs.impl.AggregateImpl.prepare(AggregateImpl.java:733)
> at
> org.apache.jackrabbit.vault.fs.impl.AggregateImpl.prepare(AggregateImpl.java:733)
> at
> org.apache.jackrabbit.vault.fs.impl.AggregateImpl.collect(AggregateImpl.java:684)
> at
> org.apache.jackrabbit.vault.fs.impl.AggregateImpl.prepare(AggregateImpl.java:747)
> at
> org.apache.jackrabbit.vault.fs.impl.AggregateImpl.load(AggregateImpl.java:657)
> at
> org.apache.jackrabbit.vault.fs.impl.AggregateImpl.getArtifacts(AggregateImpl.java:259)
> at
> org.apache.jackrabbit.vault.fs.impl.VaultFileImpl.(VaultFileImpl.java:101)
> at
> org.apache.jackrabbit.vault.fs.impl.VaultFileSystemImpl.(VaultFileSystemImpl.java:120)
> at org.apache.jackrabbit.vault.fs.Mounter.mount(Mounter.java:64)
> at
> org.apache.jackrabbit.vault.packaging.impl.PackageManagerImpl.assemble(PackageManagerImpl.java:141)
> at
> org.apache.jackrabbit.vault.packaging.impl.PackageManagerImpl.assemble(PackageManagerImpl.java:102)
> at
> org.apache.jackrabbit.vault.packaging.impl.JcrPackageManagerImpl.assemble(JcrPackageManagerImpl.java:358)
> at
> org.apache.jackrabbit.vault.packaging.impl.JcrPackageManagerImpl.assemble(JcrPackageManagerImpl.java:324)
> {noformat}
> It seems to me that vault is traversing the complete tree and also storing
> some information of every traversed node in memory.
> For validation I enabled trace logging for {{org.apache.jac
[jira] [Updated] (JCRVLT-374) assembling a content-package consumes much memory
[
https://issues.apache.org/jira/browse/JCRVLT-374?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mark Adamcin updated JCRVLT-374:
Attachment: JCRVLT-374-proto.patch
> assembling a content-package consumes much memory
> -
>
> Key: JCRVLT-374
> URL: https://issues.apache.org/jira/browse/JCRVLT-374
> Project: Jackrabbit FileVault
> Issue Type: Improvement
> Components: Packaging
>Affects Versions: 3.2.8
>Reporter: Jörg Hoh
>Priority: Major
> Attachments: JCRVLT-374-proto.patch, filevault.log.gz
>
>
> I came across a situation that packaging a huge subtree
> (/jcr:system/jcr:versionStorage) (bad idea, I know) caused a huge spike in
> memory usage, which caused lots of FullGCs (due to AllocationFailures).
> I have several stacktraces from that time, which all look very similar to
> this one:
> {noformat}
> qtp1597826410-38130" prio=5 tid=0x94f2 nid=0x runnable
>java.lang.Thread.State: RUNNABLE
> at
> org.apache.jackrabbit.oak.segment.SegmentNodeBuilder.createChildBuilder(SegmentNodeBuilder.java:147)
> at
> org.apache.jackrabbit.oak.plugins.memory.MemoryNodeBuilder.getChildNode(MemoryNodeBuilder.java:330)
> at
> org.apache.jackrabbit.oak.core.SecureNodeBuilder.(SecureNodeBuilder.java:110)
> at
> org.apache.jackrabbit.oak.core.SecureNodeBuilder.getChildNode(SecureNodeBuilder.java:327)
> at
> org.apache.jackrabbit.oak.core.MutableTree.getTree(MutableTree.java:288)
> at
> org.apache.jackrabbit.oak.core.MutableRoot.getTree(MutableRoot.java:220)
> at
> org.apache.jackrabbit.oak.core.MutableRoot.getTree(MutableRoot.java:69)
> at
> org.apache.jackrabbit.oak.jcr.session.WorkspaceImpl$1.getTypes(WorkspaceImpl.java:85)
> at
> org.apache.jackrabbit.oak.plugins.nodetype.ReadOnlyNodeTypeManager.isNodeType(ReadOnlyNodeTypeManager.java:293)
> at
> org.apache.jackrabbit.oak.jcr.session.NodeImpl$24.perform(NodeImpl.java:931)
> at
> org.apache.jackrabbit.oak.jcr.session.NodeImpl$24.perform(NodeImpl.java:926)
> 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.isNodeType(NodeImpl.java:926)
> at
> org.apache.jackrabbit.vault.fs.impl.aggregator.FileAggregator.matches(FileAggregator.java:66)
> at
> org.apache.jackrabbit.vault.fs.impl.AggregatorProvider.getAggregator(AggregatorProvider.java:68)
> at
> org.apache.jackrabbit.vault.fs.impl.AggregateManagerImpl.getAggregator(AggregateManagerImpl.java:455)
> at
> org.apache.jackrabbit.vault.fs.impl.AggregateImpl.prepare(AggregateImpl.java:720)
> at
> org.apache.jackrabbit.vault.fs.impl.AggregateImpl.prepare(AggregateImpl.java:733)
> at
> org.apache.jackrabbit.vault.fs.impl.AggregateImpl.prepare(AggregateImpl.java:733)
> at
> org.apache.jackrabbit.vault.fs.impl.AggregateImpl.prepare(AggregateImpl.java:733)
> at
> org.apache.jackrabbit.vault.fs.impl.AggregateImpl.prepare(AggregateImpl.java:733)
> at
> org.apache.jackrabbit.vault.fs.impl.AggregateImpl.prepare(AggregateImpl.java:733)
> at
> org.apache.jackrabbit.vault.fs.impl.AggregateImpl.collect(AggregateImpl.java:684)
> at
> org.apache.jackrabbit.vault.fs.impl.AggregateImpl.prepare(AggregateImpl.java:747)
> at
> org.apache.jackrabbit.vault.fs.impl.AggregateImpl.load(AggregateImpl.java:657)
> at
> org.apache.jackrabbit.vault.fs.impl.AggregateImpl.getArtifacts(AggregateImpl.java:259)
> at
> org.apache.jackrabbit.vault.fs.impl.VaultFileImpl.(VaultFileImpl.java:101)
> at
> org.apache.jackrabbit.vault.fs.impl.VaultFileSystemImpl.(VaultFileSystemImpl.java:120)
> at org.apache.jackrabbit.vault.fs.Mounter.mount(Mounter.java:64)
> at
> org.apache.jackrabbit.vault.packaging.impl.PackageManagerImpl.assemble(PackageManagerImpl.java:141)
> at
> org.apache.jackrabbit.vault.packaging.impl.PackageManagerImpl.assemble(PackageManagerImpl.java:102)
> at
> org.apache.jackrabbit.vault.packaging.impl.JcrPackageManagerImpl.assemble(JcrPackageManagerImpl.java:358)
> at
> org.apache.jackrabbit.vault.packaging.impl.JcrPackageManagerImpl.assemble(JcrPackageManagerImpl.java:324)
> {noformat}
> It seems to me that vault is traversing the complete tree and also storing
> some information of every traversed node in memory.
> For validation I enabled trace logging for {{org.apache.jackrabbit.vault.fs}}
> and tried to reproduce locally to package the complete
> {{/jcr:system/jcr:versionStorage}} in a package.
> {noformat}
> [...]
> 19.09.2019 20:06:08.792 *TRACE* [qt
[jira] [Updated] (JCRVLT-377) text files in repo with missing svn:eol-style=native setting
[ https://issues.apache.org/jira/browse/JCRVLT-377?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Julian Reschke updated JCRVLT-377: -- Attachment: eolstyle.diff Status: Patch Available (was: Open) > text files in repo with missing svn:eol-style=native setting > > > Key: JCRVLT-377 > URL: https://issues.apache.org/jira/browse/JCRVLT-377 > Project: Jackrabbit FileVault > Issue Type: Improvement >Reporter: Julian Reschke >Priority: Trivial > Attachments: eolstyle.diff > > > ...this makes it harder for people on Windows to produce patches. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (JCRVLT-377) text files in repo with missing svn:eol-style=native setting
Julian Reschke created JCRVLT-377: - Summary: text files in repo with missing svn:eol-style=native setting Key: JCRVLT-377 URL: https://issues.apache.org/jira/browse/JCRVLT-377 Project: Jackrabbit FileVault Issue Type: Improvement Reporter: Julian Reschke ...this makes it harder for people on Windows to produce patches. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (JCRVLT-376) test cases leak temp files
[ https://issues.apache.org/jira/browse/JCRVLT-376?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Julian Reschke updated JCRVLT-376: -- Attachment: JCRVLT-376.diff Status: Patch Available (was: Open) > test cases leak temp files > -- > > Key: JCRVLT-376 > URL: https://issues.apache.org/jira/browse/JCRVLT-376 > Project: Jackrabbit FileVault > Issue Type: Improvement > Components: vlt >Reporter: Julian Reschke >Priority: Minor > Attachments: JCRVLT-376.diff > > > Many files matching "vaulttest*zip" are left in the tmp folder when running > tests. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (JCRVLT-376) test cases leak temp files
Julian Reschke created JCRVLT-376: - Summary: test cases leak temp files Key: JCRVLT-376 URL: https://issues.apache.org/jira/browse/JCRVLT-376 Project: Jackrabbit FileVault Issue Type: Improvement Components: vlt Reporter: Julian Reschke Many files matching "vaulttest*zip" are left in the tmp folder when running tests. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (JCRVLT-375) Vault contains AEM specific nodetypes
[ https://issues.apache.org/jira/browse/JCRVLT-375?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16934244#comment-16934244 ] Tobias Bocanegra commented on JCRVLT-375: - there are not many products that use filevault - and we don't have a good extension mechanism for the configs :-) I'm happy to add more configs for other products, if needed. But we cannot remove those w/o breaking AEM. > Vault contains AEM specific nodetypes > - > > Key: JCRVLT-375 > URL: https://issues.apache.org/jira/browse/JCRVLT-375 > Project: Jackrabbit FileVault > Issue Type: Improvement > Components: vlt >Affects Versions: 3.2.8 >Reporter: Jörg Hoh >Priority: Major > > The vault sourcecode [1] and also the binary packages of vault contain > proprietary nodetypes of Adobe Experience Manager (cq:Widget, cq:EditConfig, > ...) > Shouldn't that get removed? > [1]https://github.com/apache/jackrabbit-filevault/blob/trunk/vault-core/src/main/resources/org/apache/jackrabbit/vault/fs/config/defaultConfig-1.1.xml -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (JCRVLT-375) Vault contains AEM specific nodetypes
[ https://issues.apache.org/jira/browse/JCRVLT-375?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16934243#comment-16934243 ] Konrad Windszus commented on JCRVLT-375: I think this is a duplicate of https://issues.apache.org/jira/browse/JCRVLT-1. > Vault contains AEM specific nodetypes > - > > Key: JCRVLT-375 > URL: https://issues.apache.org/jira/browse/JCRVLT-375 > Project: Jackrabbit FileVault > Issue Type: Improvement > Components: vlt >Affects Versions: 3.2.8 >Reporter: Jörg Hoh >Priority: Major > > The vault sourcecode [1] and also the binary packages of vault contain > proprietary nodetypes of Adobe Experience Manager (cq:Widget, cq:EditConfig, > ...) > Shouldn't that get removed? > [1]https://github.com/apache/jackrabbit-filevault/blob/trunk/vault-core/src/main/resources/org/apache/jackrabbit/vault/fs/config/defaultConfig-1.1.xml -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (JCRVLT-374) assembling a content-package consumes much memory
[
https://issues.apache.org/jira/browse/JCRVLT-374?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16934233#comment-16934233
]
Jörg Hoh commented on JCRVLT-374:
-
[~madamcin]: If you can provide me a patch, I could test it :-)
> assembling a content-package consumes much memory
> -
>
> Key: JCRVLT-374
> URL: https://issues.apache.org/jira/browse/JCRVLT-374
> Project: Jackrabbit FileVault
> Issue Type: Improvement
> Components: Packaging
>Affects Versions: 3.2.8
>Reporter: Jörg Hoh
>Priority: Major
> Attachments: filevault.log.gz
>
>
> I came across a situation that packaging a huge subtree
> (/jcr:system/jcr:versionStorage) (bad idea, I know) caused a huge spike in
> memory usage, which caused lots of FullGCs (due to AllocationFailures).
> I have several stacktraces from that time, which all look very similar to
> this one:
> {noformat}
> qtp1597826410-38130" prio=5 tid=0x94f2 nid=0x runnable
>java.lang.Thread.State: RUNNABLE
> at
> org.apache.jackrabbit.oak.segment.SegmentNodeBuilder.createChildBuilder(SegmentNodeBuilder.java:147)
> at
> org.apache.jackrabbit.oak.plugins.memory.MemoryNodeBuilder.getChildNode(MemoryNodeBuilder.java:330)
> at
> org.apache.jackrabbit.oak.core.SecureNodeBuilder.(SecureNodeBuilder.java:110)
> at
> org.apache.jackrabbit.oak.core.SecureNodeBuilder.getChildNode(SecureNodeBuilder.java:327)
> at
> org.apache.jackrabbit.oak.core.MutableTree.getTree(MutableTree.java:288)
> at
> org.apache.jackrabbit.oak.core.MutableRoot.getTree(MutableRoot.java:220)
> at
> org.apache.jackrabbit.oak.core.MutableRoot.getTree(MutableRoot.java:69)
> at
> org.apache.jackrabbit.oak.jcr.session.WorkspaceImpl$1.getTypes(WorkspaceImpl.java:85)
> at
> org.apache.jackrabbit.oak.plugins.nodetype.ReadOnlyNodeTypeManager.isNodeType(ReadOnlyNodeTypeManager.java:293)
> at
> org.apache.jackrabbit.oak.jcr.session.NodeImpl$24.perform(NodeImpl.java:931)
> at
> org.apache.jackrabbit.oak.jcr.session.NodeImpl$24.perform(NodeImpl.java:926)
> 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.isNodeType(NodeImpl.java:926)
> at
> org.apache.jackrabbit.vault.fs.impl.aggregator.FileAggregator.matches(FileAggregator.java:66)
> at
> org.apache.jackrabbit.vault.fs.impl.AggregatorProvider.getAggregator(AggregatorProvider.java:68)
> at
> org.apache.jackrabbit.vault.fs.impl.AggregateManagerImpl.getAggregator(AggregateManagerImpl.java:455)
> at
> org.apache.jackrabbit.vault.fs.impl.AggregateImpl.prepare(AggregateImpl.java:720)
> at
> org.apache.jackrabbit.vault.fs.impl.AggregateImpl.prepare(AggregateImpl.java:733)
> at
> org.apache.jackrabbit.vault.fs.impl.AggregateImpl.prepare(AggregateImpl.java:733)
> at
> org.apache.jackrabbit.vault.fs.impl.AggregateImpl.prepare(AggregateImpl.java:733)
> at
> org.apache.jackrabbit.vault.fs.impl.AggregateImpl.prepare(AggregateImpl.java:733)
> at
> org.apache.jackrabbit.vault.fs.impl.AggregateImpl.prepare(AggregateImpl.java:733)
> at
> org.apache.jackrabbit.vault.fs.impl.AggregateImpl.collect(AggregateImpl.java:684)
> at
> org.apache.jackrabbit.vault.fs.impl.AggregateImpl.prepare(AggregateImpl.java:747)
> at
> org.apache.jackrabbit.vault.fs.impl.AggregateImpl.load(AggregateImpl.java:657)
> at
> org.apache.jackrabbit.vault.fs.impl.AggregateImpl.getArtifacts(AggregateImpl.java:259)
> at
> org.apache.jackrabbit.vault.fs.impl.VaultFileImpl.(VaultFileImpl.java:101)
> at
> org.apache.jackrabbit.vault.fs.impl.VaultFileSystemImpl.(VaultFileSystemImpl.java:120)
> at org.apache.jackrabbit.vault.fs.Mounter.mount(Mounter.java:64)
> at
> org.apache.jackrabbit.vault.packaging.impl.PackageManagerImpl.assemble(PackageManagerImpl.java:141)
> at
> org.apache.jackrabbit.vault.packaging.impl.PackageManagerImpl.assemble(PackageManagerImpl.java:102)
> at
> org.apache.jackrabbit.vault.packaging.impl.JcrPackageManagerImpl.assemble(JcrPackageManagerImpl.java:358)
> at
> org.apache.jackrabbit.vault.packaging.impl.JcrPackageManagerImpl.assemble(JcrPackageManagerImpl.java:324)
> {noformat}
> It seems to me that vault is traversing the complete tree and also storing
> some information of every traversed node in memory.
> For validation I enabled trace logging for {{org.apache.jackrabbit.vault.fs}}
> and tried to reproduce locally to package the complete
> {{/jcr:system/jcr:versionStorage}} in a package.
> {nofo
[jira] [Created] (JCRVLT-375) Vault contains AEM specific nodetypes
Jörg Hoh created JCRVLT-375: --- Summary: Vault contains AEM specific nodetypes Key: JCRVLT-375 URL: https://issues.apache.org/jira/browse/JCRVLT-375 Project: Jackrabbit FileVault Issue Type: Improvement Components: vlt Affects Versions: 3.2.8 Reporter: Jörg Hoh The vault sourcecode [1] and also the binary packages of vault contain proprietary nodetypes of Adobe Experience Manager (cq:Widget, cq:EditConfig, ...) Shouldn't that get removed? [1]https://github.com/apache/jackrabbit-filevault/blob/trunk/vault-core/src/main/resources/org/apache/jackrabbit/vault/fs/config/defaultConfig-1.1.xml -- This message was sent by Atlassian Jira (v8.3.4#803005)
