[jira] [Resolved] (SLING-7754) Implement passive DistributionQueue in the repository

[Marius Petria (JIRA)]

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

Marius Petria resolved SLING-7754.
--
   Resolution: Fixed
Fix Version/s: Content Distribution Core 0.3.6

Thanks [~marett] for the review,

I added some more tests and commited in [1]. The implementation details you 
mentioned can be safely postponed.


[1] 
https://github.com/apache/sling-org-apache-sling-distribution-core/commit/6a3670c1cfe1779aff3f9fe9e1b4df04b4e112cd

> Implement passive DistributionQueue in the repository
> -
>
> Key: SLING-7754
> URL: https://issues.apache.org/jira/browse/SLING-7754
> Project: Sling
>  Issue Type: Improvement
>  Components: Content Distribution
>Reporter: Marius Petria
>Assignee: Marius Petria
>Priority: Major
> Fix For: Content Distribution Core 0.3.6
>
>  Time Spent: 40m
>  Remaining Estimate: 0h
>
> In order to minimize dependency on Sling Jobs and improve performance we 
> should offer an implementation passive queues in JCR.
> Passive queues are distribution queues [1] for which no queue processor is 
> defined. They are only used to store items and do not need rebalancing 
> between instances. They just need to be stored and fetched (FIFO semantics) 
> and this can easily be implemented in JCR with a simpler implementation that 
> does not use querying (querying for jobs is problematic like OAK-7495 shows).
> [1] 
> https://github.com/apache/sling-org-apache-sling-distribution-core/blob/master/src/main/java/org/apache/sling/distribution/queue/spi/DistributionQueue.java



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (SLING-7754) Implement passive DistributionQueue in the repository

[Marius Petria (JIRA)]

[ 
https://issues.apache.org/jira/browse/SLING-7754?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16645022#comment-16645022
 ] 

Marius Petria commented on SLING-7754:
--

[~marett] I created a DistributionQueue implementation based on Resources in 
(/var/sling/distribution/queues)

A queue is structured the same way as sling events (bucketed by create date). 
The order is maintained by the repository, it is the order in which the items 
are written to the repository. There is also a cleanup task that removes empty 
folders that runs every 5 minutes. The code is in [1] if you want to have a 
look.

{code}
queueRoot (sling:OrderedFolder)
- 2018 (sling:OrderedFolder)
   - 10 (sling:OrderedFolder)
- 10 (sling:OrderedFolder)
- 17 (sling:OrderedFolder)
   - 59 (sling:OrderedFolder)
 - distrq-guid (nt:unstructured)
{code}


[1] https://github.com/apache/sling-org-apache-sling-distribution-core/pull/12

> Implement passive DistributionQueue in the repository
> -
>
> Key: SLING-7754
> URL: https://issues.apache.org/jira/browse/SLING-7754
> Project: Sling
>  Issue Type: Improvement
>  Components: Content Distribution
>Reporter: Marius Petria
>Assignee: Marius Petria
>Priority: Major
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> In order to minimize dependency on Sling Jobs and improve performance we 
> should offer an implementation passive queues in JCR.
> Passive queues are distribution queues [1] for which no queue processor is 
> defined. They are only used to store items and do not need rebalancing 
> between instances. They just need to be stored and fetched (FIFO semantics) 
> and this can easily be implemented in JCR with a simpler implementation that 
> does not use querying (querying for jobs is problematic like OAK-7495 shows).
> [1] 
> https://github.com/apache/sling-org-apache-sling-distribution-core/blob/master/src/main/java/org/apache/sling/distribution/queue/spi/DistributionQueue.java



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Comment Edited] (SLING-7754) Implement passive DistributionQueue in JCR

[Marius Petria (JIRA)]

[ 
https://issues.apache.org/jira/browse/SLING-7754?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16522146#comment-16522146
 ] 

Marius Petria edited comment on SLING-7754 at 6/25/18 11:12 AM:


[~bdelacretaz] this is a feature for Sling Content Distribution and refers to 
offering an implementation of DistributionQueue interface [1] for distribution 
usecase. It is not about offering an alternative implementation of Sling Jobs.

SCD uses queues in two ways: 
- active queues: for which a queue processor can be defined; typically used for 
delivering items in forward distribution usecases.
- passive queues: for which no queue processor is defined; typically used for 
storing items (with a FIFO semantics) in reverse distribution usecases

As passive queues are just used for storing items until they are fetched and 
removed they do not need the entire machinery of Sling Jobs for 
assigning/unassigning jobs to processors and can easily be implemented in 
repository without relying on querying. The current Sling Jobs implementation 
relies heavily on JCR queries for implementing some of the API (getJobById, 
removeJobById, findJobs), and that proved to be both a performance and a 
reliability issue for SCD.

[1] 
https://github.com/apache/sling-org-apache-sling-distribution-core/blob/master/src/main/java/org/apache/sling/distribution/queue/spi/DistributionQueue.java


was (Author: mpetria):
[~bdelacretaz] this is a feature for Sling Content Distribution and refers to 
offering an implementation of DistributionQueue interface [1] for distribution 
usecase. It is not about offering an alternative implementation of Sling Jobs.

SCD uses queues in two ways: 
- active queues: for which a queue processor can be defined; typically used for 
delivering items in forward distribution usecases.
- passive queues: for which no queue processor is defined; typically used for 
storing items (with a FIFO semantics) in reverse distribution usecases

As passive queues ar just used for storing until items are pulled and removed 
they do not need the entire machinery of Sling Jobs and can easily be 
implemented in repository without relying on querying. The current Sling Jobs 
implementation relies heavily on JCR queries for implementing some of the API 
(getJobById, removeJobById, findJobs), and that proved to be both a performance 
and a reliability issue for SCD.

[1] 
https://github.com/apache/sling-org-apache-sling-distribution-core/blob/master/src/main/java/org/apache/sling/distribution/queue/spi/DistributionQueue.java

> Implement passive DistributionQueue in JCR
> --
>
> Key: SLING-7754
> URL: https://issues.apache.org/jira/browse/SLING-7754
> Project: Sling
>  Issue Type: Improvement
>  Components: Content Distribution
>Reporter: Marius Petria
>Assignee: Marius Petria
>Priority: Major
>
> In order to minimize dependency on Sling Jobs and improve performance we 
> should offer an implementation passive queues in JCR.
> Passive queues are distribution queues [1] for which no queue processor is 
> defined. They are only used to store items and do not need rebalancing 
> between instances. They just need to be stored and fetched (FIFO semantics) 
> and this can easily be implemented in JCR with a simpler implementation that 
> does not use querying (querying for jobs is problematic like OAK-7495 shows).
> [1] 
> https://github.com/apache/sling-org-apache-sling-distribution-core/blob/master/src/main/java/org/apache/sling/distribution/queue/spi/DistributionQueue.java



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (SLING-7754) Implement passive DistributionQueue in JCR

[Marius Petria (JIRA)]

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

Marius Petria updated SLING-7754:
-
Description: 
In order to minimize dependency on Sling Jobs and improve performance we should 
offer an implementation passive queues in JCR.

Passive queues are distribution queues [1] for which no queue processor is 
defined. They are only used to store items and do not need rebalancing between 
instances. They just need to be stored and fetched (FIFO semantics) and this 
can easily be implemented in JCR with a simpler implementation that does not 
use querying (querying for jobs is problematic like OAK-7495 shows).

[1] 
https://github.com/apache/sling-org-apache-sling-distribution-core/blob/master/src/main/java/org/apache/sling/distribution/queue/spi/DistributionQueue.java

  was:In order to minimize dependency on Sling Jobs and improve performance we 
should offer an implementation passive queues in JCR.


> Implement passive DistributionQueue in JCR
> --
>
> Key: SLING-7754
> URL: https://issues.apache.org/jira/browse/SLING-7754
> Project: Sling
>  Issue Type: Improvement
>  Components: Content Distribution
>Reporter: Marius Petria
>Assignee: Marius Petria
>Priority: Major
>
> In order to minimize dependency on Sling Jobs and improve performance we 
> should offer an implementation passive queues in JCR.
> Passive queues are distribution queues [1] for which no queue processor is 
> defined. They are only used to store items and do not need rebalancing 
> between instances. They just need to be stored and fetched (FIFO semantics) 
> and this can easily be implemented in JCR with a simpler implementation that 
> does not use querying (querying for jobs is problematic like OAK-7495 shows).
> [1] 
> https://github.com/apache/sling-org-apache-sling-distribution-core/blob/master/src/main/java/org/apache/sling/distribution/queue/spi/DistributionQueue.java



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (SLING-7754) Implement passive queues in JCR

[Marius Petria (JIRA)]

[ 
https://issues.apache.org/jira/browse/SLING-7754?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16522146#comment-16522146
 ] 

Marius Petria commented on SLING-7754:
--

[~bdelacretaz] this is a feature for Sling Content Distribution and refers to 
offering an implementation of DistributionQueue interface [1] for distribution 
usecase. It is not about offering an alternative implementation of Sling Jobs.

SCD uses queues in two ways: 
- active queues: for which a queue processor can be defined; typically used for 
delivering items in forward distribution usecases.
- passive queues: for which no queue processor is defined; typically used for 
storing items (with a FIFO semantics) in reverse distribution usecases

As passive queues ar just used for storing until items are pulled and removed 
they do not need the entire machinery of Sling Jobs and can easily be 
implemented in repository without relying on querying. The current Sling Jobs 
implementation relies heavily on JCR queries for implementing some of the API 
(getJobById, removeJobById, findJobs), and that proved to be both a performance 
and a reliability issue for SCD.

[1] 
https://github.com/apache/sling-org-apache-sling-distribution-core/blob/master/src/main/java/org/apache/sling/distribution/queue/spi/DistributionQueue.java

> Implement passive queues in JCR
> ---
>
> Key: SLING-7754
> URL: https://issues.apache.org/jira/browse/SLING-7754
> Project: Sling
>  Issue Type: Improvement
>  Components: Content Distribution
>Reporter: Marius Petria
>Assignee: Marius Petria
>Priority: Major
>
> In order to minimize dependency on Sling Jobs and improve performance we 
> should offer an implementation passive queues in JCR.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (SLING-7754) Implement passive DistributionQueue in JCR

[Marius Petria (JIRA)]

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

Marius Petria updated SLING-7754:
-
Summary: Implement passive DistributionQueue in JCR  (was: Implement 
passive queues in JCR)

> Implement passive DistributionQueue in JCR
> --
>
> Key: SLING-7754
> URL: https://issues.apache.org/jira/browse/SLING-7754
> Project: Sling
>  Issue Type: Improvement
>  Components: Content Distribution
>Reporter: Marius Petria
>Assignee: Marius Petria
>Priority: Major
>
> In order to minimize dependency on Sling Jobs and improve performance we 
> should offer an implementation passive queues in JCR.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Created] (SLING-7754) Implement passive queues in JCR

[Marius Petria (JIRA)]

Marius Petria created SLING-7754:


 Summary: Implement passive queues in JCR
 Key: SLING-7754
 URL: https://issues.apache.org/jira/browse/SLING-7754
 Project: Sling
  Issue Type: Improvement
  Components: Content Distribution
Reporter: Marius Petria
Assignee: Marius Petria


In order to minimize dependency on Sling Jobs and improve performance we should 
offer an implementation passive queues in JCR.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Reopened] (SLING-7730) Distribution package is lost if there is an installation error on receiver side

[Marius Petria (JIRA)]

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

Marius Petria reopened SLING-7730:
--

Hi [~simone.tripodi], I am reopening this issue as we should provide an option 
on the vault package builder whether to run in strict mode or not (the default 
should be strict true). I want us to mitigate the possible impact of some 
usecases where this used to work and suddenly it will casue blocked queues.

> Distribution package is lost if there is an installation error on receiver 
> side
> ---
>
> Key: SLING-7730
> URL: https://issues.apache.org/jira/browse/SLING-7730
> Project: Sling
>  Issue Type: Bug
>  Components: Content Distribution
>Affects Versions: Content Distribution Core 0.2.10
>Reporter: Simone Tripodi
>Assignee: Simone Tripodi
>Priority: Major
> Fix For: Content Distribution Core 0.3.0
>
> Attachments: SLING-7730.patch
>
>
> There is a little test to reproduce the error:
> * register namespaces on each:
> ** Sender
> *** URI = http://testsender
> *** Prefix = test
> ** Receiver
> *** URI = http://testreceiver
> *** Prefix = test
> * Create a resource on Sender
> * Add a property "test:testprop = testvalue" to the resource.
> On the Sender, SCD will indicate that this was a success, but on Receiver, 
> the resource is still missing:
> {code}
> 22.05.2018 18:29:42.881 *ERROR* [127.0.0.1 [1527010182811] POST 
> /libs/sling/distribution/services/importers/default HTTP/1.1] 
> org.apache.jackrabbit.vault.fs.impl.io.GenericArtifactHandler Error while 
> parsing null: {}
> org.xml.sax.SAXException: Unknown namespace URI: http://testauthor
>   at 
> org.apache.jackrabbit.vault.fs.impl.io.DocViewSAXImporter.startPrefixMapping(DocViewSAXImporter.java:511)
>  [org.apache.jackrabbit.vault:3.1.44]
> {code}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Resolved] (SLING-7747) Send a http response error code if distribution package cannot be exported

[Marius Petria (JIRA)]

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

Marius Petria resolved SLING-7747.
--
   Resolution: Fixed
Fix Version/s: Content Distribution Core 0.3.0

Fixed in  [1]

 

[1]https://github.com/apache/sling-org-apache-sling-distribution-core/commit/07a4c30adb053e8b4181736cd61ce28acf23e6e6

> Send a http response error code if distribution package cannot be exported
> --
>
> Key: SLING-7747
> URL: https://issues.apache.org/jira/browse/SLING-7747
> Project: Sling
>  Issue Type: Bug
>Affects Versions: Content Distribution Core 0.2.10
>Reporter: Marius Petria
>Assignee: Marius Petria
>Priority: Major
> Fix For: Content Distribution Core 0.3.0
>
>
> In DistributionPackageExporterServlet [1] an error is logged if the package 
> cannot be copied but it should also be signaled to the calling party by not 
> sending 200 status code.
>  
> [1]https://github.com/apache/sling-org-apache-sling-distribution-core/blob/7317793d754205b47c1edb24d259c725a12d4b67/src/main/java/org/apache/sling/distribution/servlet/DistributionPackageExporterServlet.java#L110



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Created] (SLING-7747) Send a http response error code if distribution package cannot be exported

[Marius Petria (JIRA)]

Marius Petria created SLING-7747:


 Summary: Send a http response error code if distribution package 
cannot be exported
 Key: SLING-7747
 URL: https://issues.apache.org/jira/browse/SLING-7747
 Project: Sling
  Issue Type: Bug
Affects Versions: Content Distribution Core 0.2.10
Reporter: Marius Petria
Assignee: Marius Petria


In DistributionPackageExporterServlet [1] an error is logged if the package 
cannot be copied but it should also be signaled to the calling party by not 
sending 200 status code.

 

[1]https://github.com/apache/sling-org-apache-sling-distribution-core/blob/7317793d754205b47c1edb24d259c725a12d4b67/src/main/java/org/apache/sling/distribution/servlet/DistributionPackageExporterServlet.java#L110



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Created] (SLING-7733) Do not rewrite DistributionRequests until passed to Serializer

[Marius Petria (JIRA)]

Marius Petria created SLING-7733:


 Summary: Do not rewrite DistributionRequests until passed to 
Serializer
 Key: SLING-7733
 URL: https://issues.apache.org/jira/browse/SLING-7733
 Project: Sling
  Issue Type: Improvement
  Components: Content Distribution
Reporter: Marius Petria
Assignee: Marius Petria
 Fix For: Content Distribution Core 0.3.0


The AbstractDistributionPackageBuilder rewrites certain paths before creating a 
package. This should be the responsibility of the serializer.


[1] 
https://github.com/apache/sling-org-apache-sling-distribution-core/blob/a4da85cf8e8fa4538b6a8e93380d3c03182bb9e0/src/main/java/org/apache/sling/distribution/packaging/impl/AbstractDistributionPackageBuilder.java#L67



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Resolved] (SLING-7714) SCD FileVault packages created with root filter which removes ACEs

[Marius Petria (JIRA)]

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

Marius Petria resolved SLING-7714.
--
   Resolution: Fixed
Fix Version/s: Content Distribution Core 0.3.0

> SCD FileVault packages created with root filter which removes ACEs
> --
>
> Key: SLING-7714
> URL: https://issues.apache.org/jira/browse/SLING-7714
> Project: Sling
>  Issue Type: Bug
>  Components: Content Distribution
>Affects Versions: Content Distribution Core 0.2.10
>Reporter: Ankit Aggarwal
>Assignee: Timothee Maret
>Priority: Major
> Fix For: Content Distribution Core 0.3.0
>
> Attachments: CQ-4245994.patch, CQ-4245994_2.patch, 
> CQ-4245994_3.patch, faulty-pkg-4503-1.0.zip, pkg-4503-additionnal.zip, 
> pkg-4503-base.zip, pre-SP2-1.0.zip
>
>
> After upgrading the customer stage instances, it has been observed that the 
> user synchronization is broken.
> After investigation, I observed that not only the user sync is broken but 
> possible the whole instance, as many "rep:policy" nodes have been removed.
>  
> h4. Steps to reproduce
>  # start a 3 instances (1 author, 2 publishers) setup on AEM 6.3
>  # enable the user synchronization following the documentation
>  # upgrade publishers to SP2, then author
>  # create a new user on pub1
>  
> Expected result:
> User is propagated/synchronized on pub2 without side-effect
>  
> Actual result:
> User is propagated/synchronized on pub2, but the following rep:policy nodes 
> are removed (maybe non exhaustive list):
>  * /rep:policy
>  * /home/rep:policy
>  * /home/users/rep:policy
>  
> I reproduce this issue and tested again the procedure, but I disabled the 
> sync agent on Author, so that I could retrieve the package being replicated 
> on the other publisher (pub2) to inspect its definition.
>  
> [faulty-pkg-4503-1.0.zip^!/images/icons/link_attachment_7.gif!^|https://issues.apache.org/secure/attachment/2594552/2594552_faulty-pkg-4503-1.0.zip]
>  is a raw package containing the "/var/sling/distribution" and 
> "/var/eventing/jobs/unassigned" of pub1 where I created the new user post-SP2 
> install, if you require more details.
>  
> [pkg-4503-base.zip^!/images/icons/link_attachment_7.gif!^|https://issues.apache.org/secure/attachment/2594549/2594549_pkg-4503-base.zip]
>  and 
> [pkg-4503-additionnal.zip^!/images/icons/link_attachment_7.gif!^|https://issues.apache.org/secure/attachment/2594550/2594550_pkg-4503-additionnal.zip]
>  are the actual packages that will be distributed by SCD, and installed on 
> pub2. I extracted them from 
> [faulty-pkg-4503-1.0.zip^!/images/icons/link_attachment_7.gif!^|https://issues.apache.org/secure/attachment/2594552/2594552_faulty-pkg-4503-1.0.zip]
>  from the following path 
> "faulty-pkg-4503-1.0.zip\jcr_root\var\sling\distribution\packages\socialpubsync-vlt\data\dstrpck-1528203802286-58c3aa28-a83a-4a74-a781-e48e5415a541\"
>  and "dstrpck-1528203802288-c6416288-9b4d-43cc-8967-c09215bd6a91" (they are 
> the "bin" file renamed).
>  
> Checking their _META-INF\vault\filter.xml,_ I think that the filter 
> definition is incorrect:
> {code:java}
> 
>   
> 
>   
>   
> 
>   
>   
> {code}
>  
> *The last entry with filter on "/" looks suspicious.*
>  
> On a pre-SP2 instance, I have the following which is correct:
> {code:java}
> 
>   
> 
>   
>   
> 
>   
> {code}
>  
> I assume that the ACL are merged and as the filter is pointing to "/" and the 
> package doesn't have any rep:policy for any nodes in the hierarchy, it is 
> removing the existing ones.
>  
> PS: I have some instances setup to share if needed.
> *Btw now that the issue is qualified I guess you only need to setup one 
> single publisher, enable usersync, and create a new user. This should trigger 
> the package creation containing the invalid filter definition.*



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (SLING-7714) SCD FileVault packages created with root filter which removes ACEs

[Marius Petria (JIRA)]

[ 
https://issues.apache.org/jira/browse/SLING-7714?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16511370#comment-16511370
 ] 

Marius Petria commented on SLING-7714:
--

I applied the first patch to SCD and filled JCRVLT-305 to track the filter.xml 
problem.

> SCD FileVault packages created with root filter which removes ACEs
> --
>
> Key: SLING-7714
> URL: https://issues.apache.org/jira/browse/SLING-7714
> Project: Sling
>  Issue Type: Bug
>  Components: Content Distribution
>Affects Versions: Content Distribution Core 0.2.10
>Reporter: Ankit Aggarwal
>Assignee: Timothee Maret
>Priority: Major
> Attachments: CQ-4245994.patch, CQ-4245994_2.patch, 
> CQ-4245994_3.patch, faulty-pkg-4503-1.0.zip, pkg-4503-additionnal.zip, 
> pkg-4503-base.zip, pre-SP2-1.0.zip
>
>
> After upgrading the customer stage instances, it has been observed that the 
> user synchronization is broken.
> After investigation, I observed that not only the user sync is broken but 
> possible the whole instance, as many "rep:policy" nodes have been removed.
>  
> h4. Steps to reproduce
>  # start a 3 instances (1 author, 2 publishers) setup on AEM 6.3
>  # enable the user synchronization following the documentation
>  # upgrade publishers to SP2, then author
>  # create a new user on pub1
>  
> Expected result:
> User is propagated/synchronized on pub2 without side-effect
>  
> Actual result:
> User is propagated/synchronized on pub2, but the following rep:policy nodes 
> are removed (maybe non exhaustive list):
>  * /rep:policy
>  * /home/rep:policy
>  * /home/users/rep:policy
>  
> I reproduce this issue and tested again the procedure, but I disabled the 
> sync agent on Author, so that I could retrieve the package being replicated 
> on the other publisher (pub2) to inspect its definition.
>  
> [faulty-pkg-4503-1.0.zip^!/images/icons/link_attachment_7.gif!^|https://issues.apache.org/secure/attachment/2594552/2594552_faulty-pkg-4503-1.0.zip]
>  is a raw package containing the "/var/sling/distribution" and 
> "/var/eventing/jobs/unassigned" of pub1 where I created the new user post-SP2 
> install, if you require more details.
>  
> [pkg-4503-base.zip^!/images/icons/link_attachment_7.gif!^|https://issues.apache.org/secure/attachment/2594549/2594549_pkg-4503-base.zip]
>  and 
> [pkg-4503-additionnal.zip^!/images/icons/link_attachment_7.gif!^|https://issues.apache.org/secure/attachment/2594550/2594550_pkg-4503-additionnal.zip]
>  are the actual packages that will be distributed by SCD, and installed on 
> pub2. I extracted them from 
> [faulty-pkg-4503-1.0.zip^!/images/icons/link_attachment_7.gif!^|https://issues.apache.org/secure/attachment/2594552/2594552_faulty-pkg-4503-1.0.zip]
>  from the following path 
> "faulty-pkg-4503-1.0.zip\jcr_root\var\sling\distribution\packages\socialpubsync-vlt\data\dstrpck-1528203802286-58c3aa28-a83a-4a74-a781-e48e5415a541\"
>  and "dstrpck-1528203802288-c6416288-9b4d-43cc-8967-c09215bd6a91" (they are 
> the "bin" file renamed).
>  
> Checking their _META-INF\vault\filter.xml,_ I think that the filter 
> definition is incorrect:
> {code:java}
> 
>   
> 
>   
>   
> 
>   
>   
> {code}
>  
> *The last entry with filter on "/" looks suspicious.*
>  
> On a pre-SP2 instance, I have the following which is correct:
> {code:java}
> 
>   
> 
>   
>   
> 
>   
> {code}
>  
> I assume that the ACL are merged and as the filter is pointing to "/" and the 
> package doesn't have any rep:policy for any nodes in the hierarchy, it is 
> removing the existing ones.
>  
> PS: I have some instances setup to share if needed.
> *Btw now that the issue is qualified I guess you only need to setup one 
> single publisher, enable usersync, and create a new user. This should trigger 
> the package creation containing the invalid filter definition.*



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (SLING-7714) SCD FileVault packages created with root filter which removes ACEs

[Marius Petria (JIRA)]

[ 
https://issues.apache.org/jira/browse/SLING-7714?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16510700#comment-16510700
 ] 

Marius Petria commented on SLING-7714:
--

[~marett] I think we have 2 things to solve:
1. make it work without property filters (these were added recently and they 
are not used a lot)
2. make it work with property filters
I am trying to split this in two because maybe we can solve 1 without fixing 
filevault. I think for that 
[CQ-4245994.patch|https://issues.apache.org/jira/secure/attachment/12926890/CQ-4245994.patch]
 looks to be the best. Even if the resulting filter.xml looks like a "deep 
filter" (with not include pattern) only the distributed node is packaged.

> SCD FileVault packages created with root filter which removes ACEs
> --
>
> Key: SLING-7714
> URL: https://issues.apache.org/jira/browse/SLING-7714
> Project: Sling
>  Issue Type: Bug
>  Components: Content Distribution
>Affects Versions: Content Distribution Core 0.2.10
>Reporter: Ankit Aggarwal
>Assignee: Timothee Maret
>Priority: Major
> Attachments: CQ-4245994.patch, CQ-4245994_2.patch, 
> CQ-4245994_3.patch, faulty-pkg-4503-1.0.zip, pkg-4503-additionnal.zip, 
> pkg-4503-base.zip, pre-SP2-1.0.zip
>
>
> After upgrading the customer stage instances (this is ManagedService), it has 
> been observed that the user synchronization si broken.
> After investigation, I observed that not only the user sync is broken but 
> possible the whole instance, as many "rep:policy" nodes have been removed.
>  
> h4. Steps to reproduce
>  # start a 3 instances (1 author, 2 publishers) setup on AEM 6.3
>  # enable the user synchronization following the documentation
>  # upgrade publishers to SP2, then author
>  # create a new user on pub1
>  
> Expected result:
> User is propagated/synchronized on pub2 without side-effect
>  
> Actual result:
> User is propagated/synchronized on pub2, but the following rep:policy nodes 
> are removed (maybe non exhaustive list):
>  * /rep:policy
>  * /home/rep:policy
>  * /home/users/rep:policy
>  
> I reproduce this issue and tested again the procedure, but I disabled the 
> sync agent on Author, so that I could retrieve the package being replicated 
> on the other publisher (pub2) to inspect its definition.
>  
> [faulty-pkg-4503-1.0.zip^!/images/icons/link_attachment_7.gif|width=7,height=7,align=absmiddle!^|https://issues.apache.org/secure/attachment/2594552/2594552_faulty-pkg-4503-1.0.zip]
>  is a raw package containing the "/var/sling/distribution" and 
> "/var/eventing/jobs/unassigned" of pub1 where I created the new user post-SP2 
> install, if you require more details.
>  
> [pkg-4503-base.zip^!/images/icons/link_attachment_7.gif|width=7,height=7,align=absmiddle!^|https://issues.apache.org/secure/attachment/2594549/2594549_pkg-4503-base.zip]
>  and 
> [pkg-4503-additionnal.zip^!/images/icons/link_attachment_7.gif|width=7,height=7,align=absmiddle!^|https://issues.apache.org/secure/attachment/2594550/2594550_pkg-4503-additionnal.zip]
>  are the actual packages that will be distributed by SCD, and installed on 
> pub2. I extracted them from 
> [faulty-pkg-4503-1.0.zip^!/images/icons/link_attachment_7.gif|width=7,height=7,align=absmiddle!^|https://issues.apache.org/secure/attachment/2594552/2594552_faulty-pkg-4503-1.0.zip]
>  from the following path 
> "faulty-pkg-4503-1.0.zip\jcr_root\var\sling\distribution\packages\socialpubsync-vlt\data\dstrpck-1528203802286-58c3aa28-a83a-4a74-a781-e48e5415a541\"
>  and "dstrpck-1528203802288-c6416288-9b4d-43cc-8967-c09215bd6a91" (they are 
> the "bin" file renamed).
>  
> Checking their _META-INF\vault\filter.xml,_ I think that the filter 
> definition is incorrect:
> {code:java}
> 
>   
> 
>   
>   
> 
>   
>   
> {code}
>  
> *The last entry with filter on "/" looks suspicious.*
>  
> On a pre-SP2 instance, I have the following which is correct:
> {code:java}
> 
>   
> 
>   
>   
> 
>   
> {code}
>  
> I assume that the ACL are merged and as the filter is pointing to "/" and the 
> package doesn't have any rep:policy for any nodes in the hierarchy, it is 
> removing the existing ones.
>  
> PS: I have some instances setup to share if needed.
> *Btw now that the issue is qualified I guess you only need to setup one 
> single publisher, enable usersync, and create a new user. This should trigger 
> the package creation containing the invalid filter definition.*



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (SLING-7714) User/Groups vault packages are getting created with wrong filters

[Marius Petria (JIRA)]

[ 
https://issues.apache.org/jira/browse/SLING-7714?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16506029#comment-16506029
 ] 

Marius Petria commented on SLING-7714:
--

Thanks [~aagarwa]. I think the second patch, that ignores property filters all 
together if they are not set, is the safest.

> User/Groups vault packages are getting created with wrong filters
> -
>
> Key: SLING-7714
> URL: https://issues.apache.org/jira/browse/SLING-7714
> Project: Sling
>  Issue Type: Bug
>  Components: Content Distribution
>Affects Versions: Content Distribution Core 0.2.10
>Reporter: Ankit Aggarwal
>Assignee: Timothee Maret
>Priority: Major
> Attachments: CQ-4245994.patch, CQ-4245994_2.patch, 
> faulty-pkg-4503-1.0.zip, pkg-4503-additionnal.zip, pkg-4503-base.zip, 
> pre-SP2-1.0.zip
>
>
> After upgrading the customer stage instances (this is ManagedService), it has 
> been observed that the user synchronization si broken.
> After investigation, I observed that not only the user sync is broken but 
> possible the whole instance, as many "rep:policy" nodes have been removed.
>  
> h4. Steps to reproduce
>  # start a 3 instances (1 author, 2 publishers) setup on AEM 6.3
>  # enable the user synchronization following the documentation
>  # upgrade publishers to SP2, then author
>  # create a new user on pub1
>  
> Expected result:
> User is propagated/synchronized on pub2 without side-effect
>  
> Actual result:
> User is propagated/synchronized on pub2, but the following rep:policy nodes 
> are removed (maybe non exhaustive list):
>  * /rep:policy
>  * /home/rep:policy
>  * /home/users/rep:policy
>  
> I reproduce this issue and tested again the procedure, but I disabled the 
> sync agent on Author, so that I could retrieve the package being replicated 
> on the other publisher (pub2) to inspect its definition.
>  
> [faulty-pkg-4503-1.0.zip^!/images/icons/link_attachment_7.gif|width=7,height=7,align=absmiddle!^|https://issues.apache.org/secure/attachment/2594552/2594552_faulty-pkg-4503-1.0.zip]
>  is a raw package containing the "/var/sling/distribution" and 
> "/var/eventing/jobs/unassigned" of pub1 where I created the new user post-SP2 
> install, if you require more details.
>  
> [pkg-4503-base.zip^!/images/icons/link_attachment_7.gif|width=7,height=7,align=absmiddle!^|https://issues.apache.org/secure/attachment/2594549/2594549_pkg-4503-base.zip]
>  and 
> [pkg-4503-additionnal.zip^!/images/icons/link_attachment_7.gif|width=7,height=7,align=absmiddle!^|https://issues.apache.org/secure/attachment/2594550/2594550_pkg-4503-additionnal.zip]
>  are the actual packages that will be distributed by SCD, and installed on 
> pub2. I extracted them from 
> [faulty-pkg-4503-1.0.zip^!/images/icons/link_attachment_7.gif|width=7,height=7,align=absmiddle!^|https://issues.apache.org/secure/attachment/2594552/2594552_faulty-pkg-4503-1.0.zip]
>  from the following path 
> "faulty-pkg-4503-1.0.zip\jcr_root\var\sling\distribution\packages\socialpubsync-vlt\data\dstrpck-1528203802286-58c3aa28-a83a-4a74-a781-e48e5415a541\"
>  and "dstrpck-1528203802288-c6416288-9b4d-43cc-8967-c09215bd6a91" (they are 
> the "bin" file renamed).
>  
> Checking their _META-INF\vault\filter.xml,_ I think that the filter 
> definition is incorrect:
> {code:java}
> 
>   
> 
>   
>   
> 
>   
>   
> {code}
>  
> *The last entry with filter on "/" looks suspicious.*
>  
> On a pre-SP2 instance, I have the following which is correct:
> {code:java}
> 
>   
> 
>   
>   
> 
>   
> {code}
>  
> I assume that the ACL are merged and as the filter is pointing to "/" and the 
> package doesn't have any rep:policy for any nodes in the hierarchy, it is 
> removing the existing ones.
>  
> PS: I have some instances setup to share if needed.
> *Btw now that the issue is qualified I guess you only need to setup one 
> single publisher, enable usersync, and create a new user. This should trigger 
> the package creation containing the invalid filter definition.*



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Reopened] (SLING-7360) Support creation of DistributionPackages for delete by DistributionContentSerializer

[Marius Petria (JIRA)]

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

Marius Petria reopened SLING-7360:
--

I am reopening this issue in order to find a solution that does not introduce 
major backwards incompatibility issues.

[1] 
https://github.com/apache/sling-org-apache-sling-distribution-core/commit/3b959a72a555af2da29363a1e3cde2ae3b157fae

> Support creation of DistributionPackages for delete by 
> DistributionContentSerializer
> 
>
> Key: SLING-7360
> URL: https://issues.apache.org/jira/browse/SLING-7360
> Project: Sling
>  Issue Type: Improvement
>  Components: Content Distribution
>Reporter: Dirk Rudolph
>Assignee: Dirk Rudolph
>Priority: Minor
> Fix For: Content Distribution Core 0.3.0
>
>
> For the integration into systems or then sling, that support 
> creation/deletion as part of their API [1], we can implement a 
> {{DistributionContentSerializer}} writing the format the API expects. That 
> currently works well for creation but not for deletion because both 
> {{FileDistributionPackageBuilder}} and {{ResourceDistributionPackageBuilder}} 
> inherit from {{AbstractDistributionPackageBuilder}} which [returns a 
> SimpleDistributionPackage|https://github.com/apache/sling-org-apache-sling-distribution-core/blob/master/src/main/java/org/apache/sling/distribution/packaging/impl/AbstractDistributionPackageBuilder.java#L72]
>  for {{DistributionRequestType.DELETE}}. 
> The other system's API might expect a different format then the one written 
> by {{SimpleDistributionPackage}} so it would be create if it would be 
> possible to delegate the creation of a deletion package to the serializer as 
> well, in case the serializer supports that.
> [1] 
> https://lucene.apache.org/solr/guide/7_2/uploading-data-with-index-handlers.html



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Reopened] (SLING-7357) Send Content-Type header along with the DistributionPackage's content in forward distribution

[Marius Petria (JIRA)]

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

Marius Petria reopened SLING-7357:
--

I am reopening this issue in order to find a solution that does not introduce 
major backwards incompatibility.

[1] 
https://github.com/apache/sling-org-apache-sling-distribution-core/commit/4a8b9ace5859f9f79ee674a8887010e092746e84

> Send Content-Type header along with the DistributionPackage's content in 
> forward distribution
> -
>
> Key: SLING-7357
> URL: https://issues.apache.org/jira/browse/SLING-7357
> Project: Sling
>  Issue Type: Improvement
>  Components: Content Distribution
>Reporter: Dirk Rudolph
>Assignee: Dirk Rudolph
>Priority: Minor
> Fix For: Content Distribution Core 0.3.0
>
>
> Currently SimpleHttpDistributionTransport only adds Connection and Digest 
> http header (if configured to do so) to the http request. When integrating 
> into other systems then sling the API might require the content type of the 
> package transmitted to be present. 
> I see to options to support that:
> a) implement configureable headers for the http transport similar to the 
> timeouts. This might clash with headers set by the implementation
> b) let the serializer specify the type of the content it generates. This will 
> be an API change in the core bundle.
> From my perspective b) will be simpler to implement.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Resolved] (SLING-7555) Remove ghost packages from distribution agent queue

[Marius Petria (JIRA)]

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

Marius Petria resolved SLING-7555.
--
Resolution: Fixed
  Assignee: Marius Petria

Fixed in 
https://github.com/apache/sling-org-apache-sling-distribution-core/commit/ee2c3dd0591d0f2c2a4b3a15f726f866c81e1ed3

> Remove ghost packages from distribution agent queue
> ---
>
> Key: SLING-7555
> URL: https://issues.apache.org/jira/browse/SLING-7555
> Project: Sling
>  Issue Type: Improvement
>  Components: Content Distribution
>Affects Versions: Content Distribution Core 0.2.10
>Reporter: Marius Petria
>Assignee: Marius Petria
>Priority: Major
> Fix For: Content Distribution Core 0.3.0
>
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> Currently, (see [1]) an agent exporter only logs an error when a "ghost 
> package" is encountered (a queue entry without a binary). We should log this 
> as an error and remove the item from the queue in order to avoid stuck queues.
>  
>  
> [1]https://github.com/apache/sling-org-apache-sling-distribution-core/blob/master/src/main/java/org/apache/sling/distribution/packaging/impl/exporter/AgentDistributionPackageExporter.java#L102



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (SLING-7357) Send Content-Type header along with the DistributionPackage's content in forward distribution

[Marius Petria (JIRA)]

[ 
https://issues.apache.org/jira/browse/SLING-7357?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16489089#comment-16489089
 ] 

Marius Petria commented on SLING-7357:
--

This issue introduced a breaking change in {{DistributionContentSerializer}}. 
We should aim to keep backwards compatibility and I think we should revisit the 
way this was implemented. The mime type is an interoperability feature and 
could have been added as a http configuration option on the agent.

> Send Content-Type header along with the DistributionPackage's content in 
> forward distribution
> -
>
> Key: SLING-7357
> URL: https://issues.apache.org/jira/browse/SLING-7357
> Project: Sling
>  Issue Type: Improvement
>  Components: Content Distribution
>Reporter: Dirk Rudolph
>Assignee: Dirk Rudolph
>Priority: Minor
> Fix For: Content Distribution Core 0.3.0
>
>
> Currently SimpleHttpDistributionTransport only adds Connection and Digest 
> http header (if configured to do so) to the http request. When integrating 
> into other systems then sling the API might require the content type of the 
> package transmitted to be present. 
> I see to options to support that:
> a) implement configureable headers for the http transport similar to the 
> timeouts. This might clash with headers set by the implementation
> b) let the serializer specify the type of the content it generates. This will 
> be an API change in the core bundle.
> From my perspective b) will be simpler to implement.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Created] (SLING-7667) Place distribution packages in buckets to support smoothly tens of thousands of packages

[Marius Petria (JIRA)]

Marius Petria created SLING-7667:


 Summary: Place distribution packages in buckets to support 
smoothly tens of thousands of packages
 Key: SLING-7667
 URL: https://issues.apache.org/jira/browse/SLING-7667
 Project: Sling
  Issue Type: Improvement
  Components: Content Distribution
Affects Versions: Content Distribution Core 0.2.10
Reporter: Marius Petria


All distribution packages created 
{{/var/sling/distribution/vlt/packages/data}}. There is a remarkable slowdown 
when there are more than 20k packages in the folder.

We would need to create the packages in buckets to have a more manageable size 
of items in a folder.
Proposal of bucketing:
- one level
- 100 fixed buckets (to avoid bucket deletion and management)
- created on demand

{{.../packages/data/03/packageid}}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (SLING-7667) Place distribution packages in buckets to support smoothly tens of thousands of packages

[Marius Petria (JIRA)]

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

Marius Petria updated SLING-7667:
-
Description: 
All distribution packages created 
{{/var/sling/distribution/vlt/packages/data}}. There is a remarkable slowdown 
when there are more than 20k packages in the folder.

We would need to create the packages in buckets to have a more manageable size 
of items in a folder.
Proposal of bucketing:
- one level
- 100 fixed buckets (to avoid bucket deletion and management)
- created on demand

{{.../packages/data/03/packageid}}
{{.../packages/data/99/packageid}}

  was:
All distribution packages created 
{{/var/sling/distribution/vlt/packages/data}}. There is a remarkable slowdown 
when there are more than 20k packages in the folder.

We would need to create the packages in buckets to have a more manageable size 
of items in a folder.
Proposal of bucketing:
- one level
- 100 fixed buckets (to avoid bucket deletion and management)
- created on demand

{{.../packages/data/03/packageid}}


> Place distribution packages in buckets to support smoothly tens of thousands 
> of packages
> 
>
> Key: SLING-7667
> URL: https://issues.apache.org/jira/browse/SLING-7667
> Project: Sling
>  Issue Type: Improvement
>  Components: Content Distribution
>Affects Versions: Content Distribution Core 0.2.10
>Reporter: Marius Petria
>Priority: Major
>
> All distribution packages created 
> {{/var/sling/distribution/vlt/packages/data}}. There is a remarkable slowdown 
> when there are more than 20k packages in the folder.
> We would need to create the packages in buckets to have a more manageable 
> size of items in a folder.
> Proposal of bucketing:
> - one level
> - 100 fixed buckets (to avoid bucket deletion and management)
> - created on demand
> {{.../packages/data/03/packageid}}
> {{.../packages/data/99/packageid}}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (SLING-7555) Remove ghost packages from distribution agent queue

[Marius Petria (JIRA)]

[ 
https://issues.apache.org/jira/browse/SLING-7555?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16453639#comment-16453639
 ] 

Marius Petria commented on SLING-7555:
--

[~marett] you are right, ideally we should not have ghost packages, it is 
obvious that this situation is an anomaly. However, I think that should be 
tracked in another issue: "investigate and avoid ghost packages", but we should 
also have a more robust treatment when these cases arise because such a package 
blocks the entire sync. 

 

 

> Remove ghost packages from distribution agent queue
> ---
>
> Key: SLING-7555
> URL: https://issues.apache.org/jira/browse/SLING-7555
> Project: Sling
>  Issue Type: Improvement
>  Components: Content Distribution
>Affects Versions: Content Distribution Core 0.2.10
>Reporter: Marius Petria
>Priority: Major
> Fix For: Content Distribution Core 0.3.0
>
>
> Currently, (see [1]) an agent exporter only logs an error when a "ghost 
> package" is encountered (a queue entry without a binary). We should log this 
> as an error and remove the item from the queue in order to avoid stuck queues.
>  
>  
> [1]https://github.com/apache/sling-org-apache-sling-distribution-core/blob/master/src/main/java/org/apache/sling/distribution/packaging/impl/exporter/AgentDistributionPackageExporter.java#L102



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Resolved] (SLING-7620) Bypassing Ghost Packages in SCD

[Marius Petria (JIRA)]

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

Marius Petria resolved SLING-7620.
--
Resolution: Duplicate

Thanks [~ankitagarwaladobe] for the report, the issue is already tracked in 
SLING-7555 so I will close this and follow up on that one. 

> Bypassing Ghost Packages in SCD
> ---
>
> Key: SLING-7620
> URL: https://issues.apache.org/jira/browse/SLING-7620
> Project: Sling
>  Issue Type: Bug
>  Components: Content Distribution
>Affects Versions: Content Distribution Core 0.2.8
>Reporter: Ankit Aggarwal
>Priority: Major
>
> Sometimes the distribution package gets deleted from the queue [0] but the 
> actual item in the distribution queue [1] is not deleted leading it become a 
> Ghost Package. Because of this same item is picked up again and again 
> resulting in queue blocking and repeated warnings: 
> {quote}19.03.2018 15:10:04.130 *WARN* [10.43.32.54 [1521486603947] POST 
> /libs/sling/distribution/services/exporters/socialpubsync-reverse HTTP/1.1] 
> org.apache.sling.distribution.packaging.impl.exporter.AgentDistributionPackageExporter
>  cannot get package DistributionPackageInfo\{ request.type=ADD, 
> request.paths=[/home/groups/umuc/tus/cmit/cmit372/2188/027346-01-2188-OL1-6380/tnWOVAWBzaSHIzeDWana/rep:policy]}
> {quote}
> We need to make the code fail safe to handle such situations i.e. deleting 
> the item in the distribution queue if it is not able to find the 
> corresponding package. 
> [0] /var/sling/distribution/packages/socialpubsync-vlt/data
> [1] 
> /var/eventing/jobs/unassigned/org.apache.sling.distribution.queue.socialpubsync-reverse.default
>  
> cc: [~marett], [~mpetria]



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Created] (SLING-7555) Remove ghost packages from distribution agent queue

[Marius Petria (JIRA)]

Marius Petria created SLING-7555:


 Summary: Remove ghost packages from distribution agent queue
 Key: SLING-7555
 URL: https://issues.apache.org/jira/browse/SLING-7555
 Project: Sling
  Issue Type: Improvement
  Components: Content Distribution
Affects Versions: Content Distribution Core 0.2.10
Reporter: Marius Petria
 Fix For: Content Distribution Core 0.3.0


Currently, (see [1]) an agent exporter only logs an error when a "ghost 
package" is encountered (a queue entry without a binary). We should log this as 
an error and remove the item from the queue in order to avoid stuck queues.

 

 

[1]https://github.com/apache/sling-org-apache-sling-distribution-core/blob/master/src/main/java/org/apache/sling/distribution/packaging/impl/exporter/AgentDistributionPackageExporter.java#L102



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (SLING-7472) Simplify factory mapping

[Marius Petria (JIRA)]

[ 
https://issues.apache.org/jira/browse/SLING-7472?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16387865#comment-16387865
 ] 

Marius Petria commented on SLING-7472:
--

I am following up on the suggestion from [1]. IIUC the proposal is to identify 
the OSGI factory based on the {{kind}} parameter sent by a user. This will be 
done using an OSGI filter (e.g. (kind=agent)) to retrieve the matching 
factories.
 # In principle factories should be uniquely identified by {{kind}} and 
{{type}} properties. The {{kinds}} are (almost) fixed but the need is to be 
able to extend the {{types}} range (e.g. provide new type of agents).
 # We would do, of course, validation that {{kind}} value is in the accepted 
list (and that could also work for the {{type}})
 # However, how do we ensure that this filter is not matched by other 
configurations accidentally?

 

[1]  
https://issues.apache.org/jira/browse/SLING-7468?focusedCommentId=16352160=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-16352160
 

> Simplify factory mapping
> 
>
> Key: SLING-7472
> URL: https://issues.apache.org/jira/browse/SLING-7472
> Project: Sling
>  Issue Type: Improvement
>  Components: Content Distribution
>Reporter: Timothee Maret
>Priority: Major
> Fix For: Content Distribution Core 0.3.0
>
>
> As detailed in 
> [SLING-7468|https://issues.apache.org/jira/browse/SLING-7468?focusedCommentId=16352160=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-16352160],
>  we could simplify the mapping of factory configurations, by setting the 
> component type in each factory. 
> This requires cleaning up the OSGI properties already set in some SCD 
> factories.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (SLING-7468) Allow to configure the Distribution Resource Provider

[Marius Petria (JIRA)]

[ 
https://issues.apache.org/jira/browse/SLING-7468?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16386222#comment-16386222
 ] 

Marius Petria commented on SLING-7468:
--

Still, it is a very powerful tool: a (configurable) gate to configAdmin :). I 
will try to understand the extensibility need in order to see if we can solve 
it in a more restricted way. I fear that others might use it for their own 
scenarios to access random configurations.

> Allow to configure the Distribution Resource Provider
> -
>
> Key: SLING-7468
> URL: https://issues.apache.org/jira/browse/SLING-7468
> Project: Sling
>  Issue Type: Improvement
>  Components: Content Distribution
>Reporter: Timothee Maret
>Assignee: Timothee Maret
>Priority: Major
> Fix For: Content Distribution Core 0.3.0
>
>
> SCD maintain its own Resource Provider
> https://github.com/apache/sling-org-apache-sling-distribution-core/tree/master/src/main/java/org/apache/sling/distribution/resources
> The implementation maps OSGI configurations and services as sling resources.
> The implementation is not flexible to allow plugging a custom agent in the 
> resource tree.
> The mapping seems to be done currently in enums, for instance
> https://github.com/apache/sling-org-apache-sling-distribution-core/blob/master/src/main/java/org/apache/sling/distribution/component/impl/DistributionComponentKind.java
> This issue is about making the configuration flexible (OSGI properties) or 
> even configuration-less (figure out the mappings at runtime). As a side 
> effect, the implementation may be simplified. 
> [~teofili],[~simone.tripodi] FYI



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (SLING-7468) Allow to configure the Distribution Resource Provider

[Marius Petria (JIRA)]

[ 
https://issues.apache.org/jira/browse/SLING-7468?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16386079#comment-16386079
 ] 

Marius Petria commented on SLING-7468:
--

[~marett] I haven't looked yet at your patch but I wanted to share something 
from the initial design intent. From a security perspective there should be 
very little flexibility on what configs should be exposed as resources. We 
should hardcode the exact osgi factories that are available through the 
provider to avoid random osgi config editing. As I said, I do not know if your 
patch violates this principle, so if the comment is misplaced please ignore it.

> Allow to configure the Distribution Resource Provider
> -
>
> Key: SLING-7468
> URL: https://issues.apache.org/jira/browse/SLING-7468
> Project: Sling
>  Issue Type: Improvement
>  Components: Content Distribution
>Reporter: Timothee Maret
>Assignee: Timothee Maret
>Priority: Major
> Fix For: Content Distribution Core 0.3.0
>
>
> SCD maintain its own Resource Provider
> https://github.com/apache/sling-org-apache-sling-distribution-core/tree/master/src/main/java/org/apache/sling/distribution/resources
> The implementation maps OSGI configurations and services as sling resources.
> The implementation is not flexible to allow plugging a custom agent in the 
> resource tree.
> The mapping seems to be done currently in enums, for instance
> https://github.com/apache/sling-org-apache-sling-distribution-core/blob/master/src/main/java/org/apache/sling/distribution/component/impl/DistributionComponentKind.java
> This issue is about making the configuration flexible (OSGI properties) or 
> even configuration-less (figure out the mappings at runtime). As a side 
> effect, the implementation may be simplified. 
> [~teofili],[~simone.tripodi] FYI



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (SLING-5815) Expose DistributionContentSerializer

[Marius Petria (JIRA)]

[ 
https://issues.apache.org/jira/browse/SLING-5815?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15373220#comment-15373220
 ] 

Marius Petria commented on SLING-5815:
--

Another thought on the mapper idea. Mapping can happen for two things: paths 
and properties. The thing is that path mapping might be more difficult to 
support as the serialization format might be hierarchical and mapping to 
another tree might break the format. What I am trying to say is that we could 
split the mapper in two classes: a {{PathMapper}} and a {{PropertiesMapper}} so 
that a serializer that does not support path mapping can throw an exception 
quickly.

> Expose DistributionContentSerializer 
> -
>
> Key: SLING-5815
> URL: https://issues.apache.org/jira/browse/SLING-5815
> Project: Sling
>  Issue Type: Improvement
>  Components: Distribution
>Reporter: Tommaso Teofili
>Assignee: Tommaso Teofili
> Fix For: Content Distribution 0.2.0
>
> Attachments: SLING-5815.0.patch
>
>
> Expose {{DistributionContentSerializer}} API from 
> _org.apache.sling.distribution.core_ in order to allow implementation of 
> custom serialization formats (e.g. Avro and Kryo defined in 
> _org.apache.sling.distribution.extensions_).



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

[jira] [Commented] (SLING-5815) Expose DistributionContentSerializer

[Marius Petria (JIRA)]

[ 
https://issues.apache.org/jira/browse/SLING-5815?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15371395#comment-15371395
 ] 

Marius Petria commented on SLING-5815:
--

One additional thing that can be passed to the serializer is a 
{{ResourceMapper}}. 
{noformat}
Resource ResourceMapper.map(Resource)
{noformat}
The mapper can change path, properties, or even cause to skip a resource (if it 
returns null).
- export will call the mapper for each resource before writing to stream
- import will call the mapper for each resource before writing to repo

I am not sure how easy is to implement this for VLT, but the implementation 
could throw {{NotSupported}} if it does not support mappers.


> Expose DistributionContentSerializer 
> -
>
> Key: SLING-5815
> URL: https://issues.apache.org/jira/browse/SLING-5815
> Project: Sling
>  Issue Type: Improvement
>  Components: Distribution
>Reporter: Tommaso Teofili
>Assignee: Tommaso Teofili
> Fix For: Content Distribution 0.2.0
>
> Attachments: SLING-5815.0.patch
>
>
> Expose {{DistributionContentSerializer}} API from 
> _org.apache.sling.distribution.core_ in order to allow implementation of 
> custom serialization formats (e.g. Avro and Kryo defined in 
> _org.apache.sling.distribution.extensions_).



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

[jira] [Comment Edited] (SLING-5815) Expose DistributionContentSerializer

[Marius Petria (JIRA)]

[ 
https://issues.apache.org/jira/browse/SLING-5815?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15364905#comment-15364905
 ] 

Marius Petria edited comment on SLING-5815 at 7/6/16 7:44 PM:
--

I agree that the DistributionRequest should not be passed to the serializer. 
Some notes on the patch:
1. I think the RR should still be part of the signature and not wrapped in an 
object
2. I am a bit concerned about the path expanding that happens when you want to 
pass only simple paths to the serializer. For a request that contains 
{{+/content/a/.*}} it will have to traverse the entire subtree and potentially 
create a very big list of paths which will end up in the filter.xml. Maybe we 
can define a export structure that contains the minimized information without 
requiring to traverse the tree before passing it to serializer: an ExportFilter 
that contains a set of TreeFilter, each TreeFilter contains a root path and two 
lists of excluded and included PathFilters. So basically passing down to the 
serializer the responsibility of decoding the filters. We can have an utility 
method (ExportFilter.getCoveredPaths(ResourceResolver) or 
ExporterFilterUtils.getCoveredPaths(ExporterFilter, ResourceResolver)) to 
evaluate the paths, and that can be used by Kryo and Avro.


[1] 
https://jackrabbit.apache.org/filevault/apidocs/org/apache/jackrabbit/vault/fs/api/FilterSet.html


was (Author: mpetria):
I agree that the DistributionRequest should not be passed to the serializer. 
Some notes on the patch:
1. I think the RR should still be part of the signature and not wrapped in an 
object
2. I am a bit concerned about the path expanding that happens when you want to 
pass only simple paths to the serializer. For a request that contains 
{{+/content/a/.*}} it will have to traverse the entire subtree and potentially 
create a very big list of paths which will end up in the filter.xml. Maybe we 
can define a export structure that contains the minimized information without 
requiring to traverse the tree before passing it to serializer: an ExportFilter 
that contains a set of TreeFilter, each TreeFilter contains a root path and two 
lists of excluded and included PathFilters. So basically passing down to the 
serializer the responsibility of decoding the filters. Of course we can have an 
utility method (maybe even exposed in API) that can take an ExportFilter and 
produce a list of paths, and that can be used by Kryo and Avro.


[1] 
https://jackrabbit.apache.org/filevault/apidocs/org/apache/jackrabbit/vault/fs/api/FilterSet.html

> Expose DistributionContentSerializer 
> -
>
> Key: SLING-5815
> URL: https://issues.apache.org/jira/browse/SLING-5815
> Project: Sling
>  Issue Type: Improvement
>  Components: Distribution
>Reporter: Tommaso Teofili
>Assignee: Tommaso Teofili
> Fix For: Content Distribution 0.2.0
>
> Attachments: SLING-5815.0.patch
>
>
> Expose {{DistributionContentSerializer}} API from 
> _org.apache.sling.distribution.core_ in order to allow implementation of 
> custom serialization formats (e.g. Avro and Kryo defined in 
> _org.apache.sling.distribution.extensions_).



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

[jira] [Commented] (SLING-5815) Expose DistributionContentSerializer

[Marius Petria (JIRA)]

[ 
https://issues.apache.org/jira/browse/SLING-5815?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15364905#comment-15364905
 ] 

Marius Petria commented on SLING-5815:
--

I agree that the DistributionRequest should not be passed to the serializer. 
Some notes on the patch:
1. I think the RR should still be part of the signature and not wrapped in an 
object
2. I am a bit concerned about the path expanding that happens when you want to 
pass only simple paths to the serializer. For a request that contains 
{{+/content/a/.*}} it will have to traverse the entire subtree and potentially 
create a very big list of paths which will end up in the filter.xml. Maybe we 
can define a export structure that contains the minimized information without 
requiring to traverse the tree before passing it to serializer: an ExportFilter 
that contains a set of TreeFilter, each TreeFilter contains a root path and two 
lists of excluded and included PathFilters. So basically passing down to the 
serializer the responsibility of decoding the filters. Of course we can have an 
utility method (maybe even exposed in API) that can take an ExportFilter and 
produce a list of paths, and that can be used by Kryo and Avro.


[1] 
https://jackrabbit.apache.org/filevault/apidocs/org/apache/jackrabbit/vault/fs/api/FilterSet.html

> Expose DistributionContentSerializer 
> -
>
> Key: SLING-5815
> URL: https://issues.apache.org/jira/browse/SLING-5815
> Project: Sling
>  Issue Type: Improvement
>  Components: Distribution
>Reporter: Tommaso Teofili
>Assignee: Tommaso Teofili
> Fix For: Content Distribution 0.2.0
>
> Attachments: SLING-5815.0.patch
>
>
> Expose {{DistributionContentSerializer}} API from 
> _org.apache.sling.distribution.core_ in order to allow implementation of 
> custom serialization formats (e.g. Avro and Kryo defined in 
> _org.apache.sling.distribution.extensions_).



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

[jira] [Resolved] (SLING-5785) Allow distribution config to be stored in content

[Marius Petria (JIRA)]

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

Marius Petria resolved SLING-5785.
--
Resolution: Fixed

Fixed by allowing the configuration of a resource root under which the 
properties with a certain prefix (eg. {{etc.}}) will be saved. 
Committed revision 1748558.


> Allow distribution config to be stored in content
> -
>
> Key: SLING-5785
> URL: https://issues.apache.org/jira/browse/SLING-5785
> Project: Sling
>  Issue Type: Improvement
>  Components: Distribution
>Reporter: Marius Petria
>Assignee: Marius Petria
> Fix For: Content Distribution 0.2.0
>
>
> Using the distribution endpoint 
> {{/libs/sling/distribution/settings/agents/agentName}} one should be able to 
> also edit replication properties.
> {noformat}
> replication.triggerOnModification=true
> {noformat}



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

[jira] [Updated] (SLING-5785) Allow distribution config to be stored in content

[Marius Petria (JIRA)]

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

Marius Petria updated SLING-5785:
-
Description: 
Using the distribution endpoint 
{{/libs/sling/distribution/settings/agents/agentName}} one should be able to 
also edit replication properties.
{noformat}
replication.triggerOnModification=true
{noformat}

> Allow distribution config to be stored in content
> -
>
> Key: SLING-5785
> URL: https://issues.apache.org/jira/browse/SLING-5785
> Project: Sling
>  Issue Type: Improvement
>  Components: Distribution
>Reporter: Marius Petria
>Assignee: Marius Petria
> Fix For: Content Distribution 0.2.0
>
>
> Using the distribution endpoint 
> {{/libs/sling/distribution/settings/agents/agentName}} one should be able to 
> also edit replication properties.
> {noformat}
> replication.triggerOnModification=true
> {noformat}



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

[jira] [Created] (SLING-5785) Allow distribution config to be stored in content

[Marius Petria (JIRA)]

Marius Petria created SLING-5785:


 Summary: Allow distribution config to be stored in content
 Key: SLING-5785
 URL: https://issues.apache.org/jira/browse/SLING-5785
 Project: Sling
  Issue Type: Improvement
  Components: Distribution
Reporter: Marius Petria
Assignee: Marius Petria
 Fix For: Content Distribution 0.2.0






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

[jira] [Commented] (SLING-5760) Allow to support certificate based authentication in Distribution transport

[Marius Petria (JIRA)]

[ 
https://issues.apache.org/jira/browse/SLING-5760?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15327351#comment-15327351
 ] 

Marius Petria commented on SLING-5760:
--

Hi [~marett],
I briefly looked over the API. Note that {{distribution.core}} does not expose 
API so the {{SimpleDistributionTransportContext}} is not public, hence clients 
that implement a provider need to make their own implementation, and therefore 
they will implement also a {{DistributionContext}}. In my opinion that makes 
{{DistributionContext} a {{ConsumerType}}.

> Allow to support certificate based authentication in Distribution transport
> ---
>
> Key: SLING-5760
> URL: https://issues.apache.org/jira/browse/SLING-5760
> Project: Sling
>  Issue Type: Improvement
>  Components: Distribution
>Affects Versions: Content Distribution Core 0.1.18
>Reporter: Timothee Maret
>Assignee: Timothee Maret
> Fix For: Content Distribution 0.2.0
>
> Attachments: SLING-5760.patch
>
>
> Certificate based authentication is an alternative to the basic 
> authentication currently available for Distribution transport. Certificate 
> based authentication is done during the SSL handshake iff the target instance 
> is configured to require or accept client client authentication. This client 
> authentication scheme is a logical complement when connecting to endpoints 
> serving over https. This result in authenticating both the source and the 
> target using SSL.
> The client certificate and private key are required to complete the SSL 
> handshake. By default, the JRE will use the default {{KeyStore}} to retrieve 
> those informations. However, in some platforms such as Adobe Granite, there 
> is the ability to specify custom {{KeyStore}} based on user. For those 
> platforms, the custom {{KeyStore}} can be provided with a 
> {{javax.net.ssl.SSLContext}} which also contains a custom {{TrustStore}}.
> This issue tracks allowing to leverage certificate based authentication using 
> a custom {{javax.net.ssl.SSLContext}} in Distribution transport.



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

[jira] [Comment Edited] (SLING-5760) Allow to support certificate based authentication in Distribution transport

[Marius Petria (JIRA)]

[ 
https://issues.apache.org/jira/browse/SLING-5760?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15327351#comment-15327351
 ] 

Marius Petria edited comment on SLING-5760 at 6/13/16 1:23 PM:
---

Hi [~marett],
I briefly looked over the API. Note that {{distribution.core}} does not expose 
API so the {{SimpleDistributionTransportContext}} is not public, hence clients 
that implement a provider need to make their own implementation, and therefore 
they will implement also a {{DistributionContext}}. In my opinion that makes 
{{DistributionContext}} a {{ConsumerType}}.


was (Author: mpetria):
Hi [~marett],
I briefly looked over the API. Note that {{distribution.core}} does not expose 
API so the {{SimpleDistributionTransportContext}} is not public, hence clients 
that implement a provider need to make their own implementation, and therefore 
they will implement also a {{DistributionContext}}. In my opinion that makes 
{{DistributionContext} a {{ConsumerType}}.

> Allow to support certificate based authentication in Distribution transport
> ---
>
> Key: SLING-5760
> URL: https://issues.apache.org/jira/browse/SLING-5760
> Project: Sling
>  Issue Type: Improvement
>  Components: Distribution
>Affects Versions: Content Distribution Core 0.1.18
>Reporter: Timothee Maret
>Assignee: Timothee Maret
> Fix For: Content Distribution 0.2.0
>
> Attachments: SLING-5760.patch
>
>
> Certificate based authentication is an alternative to the basic 
> authentication currently available for Distribution transport. Certificate 
> based authentication is done during the SSL handshake iff the target instance 
> is configured to require or accept client client authentication. This client 
> authentication scheme is a logical complement when connecting to endpoints 
> serving over https. This result in authenticating both the source and the 
> target using SSL.
> The client certificate and private key are required to complete the SSL 
> handshake. By default, the JRE will use the default {{KeyStore}} to retrieve 
> those informations. However, in some platforms such as Adobe Granite, there 
> is the ability to specify custom {{KeyStore}} based on user. For those 
> platforms, the custom {{KeyStore}} can be provided with a 
> {{javax.net.ssl.SSLContext}} which also contains a custom {{TrustStore}}.
> This issue tracks allowing to leverage certificate based authentication using 
> a custom {{javax.net.ssl.SSLContext}} in Distribution transport.



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

[jira] [Commented] (SLING-5759) Distribution agents cannot be created via API

[Marius Petria (JIRA)]

[ 
https://issues.apache.org/jira/browse/SLING-5759?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15313879#comment-15313879
 ] 

Marius Petria commented on SLING-5759:
--

Committed revision 1746692.


> Distribution agents cannot be created via API
> -
>
> Key: SLING-5759
> URL: https://issues.apache.org/jira/browse/SLING-5759
> Project: Sling
>  Issue Type: Bug
>  Components: Distribution
>Reporter: Marius Petria
>
> The IT tes 
> {{DistributionAgentResourcesIntegrationTest.testAgentConfigurationResourceCreate}}
>  fails and should be fixed.



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

[jira] [Created] (SLING-5759) Distribution agents cannot be created via API

[Marius Petria (JIRA)]

Marius Petria created SLING-5759:


 Summary: Distribution agents cannot be created via API
 Key: SLING-5759
 URL: https://issues.apache.org/jira/browse/SLING-5759
 Project: Sling
  Issue Type: Bug
  Components: Distribution
Reporter: Marius Petria


The IT tes 
{{DistributionAgentResourcesIntegrationTest.testAgentConfigurationResourceCreate}}
 fails and should be fixed.



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

[jira] [Updated] (SLING-5747) Allow a distribution request to be executed by multiple agents

[Marius Petria (JIRA)]

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

Marius Petria updated SLING-5747:
-
Attachment: SLING-5747.diff

I attached a patch with a new Distributor API. 
{noformat}
Distributor.distribute(String[] agentNames, ResourceResolver, 
DistributionRequest)
{noformat}

This executes the request for all agents by passing also a distributioncontext 
used to cache packages. The LocalDistributionPackageExporter caches packages in 
the context is caching is enabled.

> Allow a distribution request to be executed by multiple agents
> --
>
> Key: SLING-5747
> URL: https://issues.apache.org/jira/browse/SLING-5747
> Project: Sling
>  Issue Type: Improvement
>  Components: Distribution
>Reporter: Marius Petria
>Assignee: Marius Petria
> Attachments: SLING-5747.diff
>
>




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

[jira] [Created] (SLING-5747) Allow a distribution request to be executed by multiple agents

[Marius Petria (JIRA)]

Marius Petria created SLING-5747:


 Summary: Allow a distribution request to be executed by multiple 
agents
 Key: SLING-5747
 URL: https://issues.apache.org/jira/browse/SLING-5747
 Project: Sling
  Issue Type: Improvement
  Components: Distribution
Reporter: Marius Petria
Assignee: Marius Petria






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

[jira] [Created] (SLING-5742) Do not allow registration of agents/exporters/importers with duplicate names

[Marius Petria (JIRA)]

Marius Petria created SLING-5742:


 Summary: Do not allow registration of agents/exporters/importers 
with duplicate names
 Key: SLING-5742
 URL: https://issues.apache.org/jira/browse/SLING-5742
 Project: Sling
  Issue Type: Bug
  Components: Distribution
Affects Versions: Content Distribution Core 0.1.18
Reporter: Marius Petria






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

[jira] [Commented] (SLING-5686) Use distribution package info to pass remote.package.id

[Marius Petria (JIRA)]

[ 
https://issues.apache.org/jira/browse/SLING-5686?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15256414#comment-15256414
 ] 

Marius Petria commented on SLING-5686:
--

Committed revision 1740843.


> Use distribution package info to pass remote.package.id
> ---
>
> Key: SLING-5686
> URL: https://issues.apache.org/jira/browse/SLING-5686
> Project: Sling
>  Issue Type: Improvement
>  Components: Distribution
>Reporter: Marius Petria
>
> Remote package id is passed via http header but we can now pass it as the 
> package info.



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

[jira] [Created] (SLING-5686) Use distribution package info to pass remote.package.id

[Marius Petria (JIRA)]

Marius Petria created SLING-5686:


 Summary: Use distribution package info to pass remote.package.id
 Key: SLING-5686
 URL: https://issues.apache.org/jira/browse/SLING-5686
 Project: Sling
  Issue Type: Improvement
  Components: Distribution
Reporter: Marius Petria


Remote package id is passed via http header but we can now pass it as the 
package info.



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

[jira] [Commented] (SLING-5647) Provide ActiveMQ implementation of the MoM API in SLING-5646

[Marius Petria (JIRA)]

[ 
https://issues.apache.org/jira/browse/SLING-5647?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15245642#comment-15245642
 ] 

Marius Petria commented on SLING-5647:
--

[~ianeboston] how are Sling instances connected, I see that a {{BROKER_URL}} 
must be configured but how are other instances discovered. Does it need to use 
Sling Discovery service, do the instances need to be in an OAK cluster? 
(disclaimer: I am not very familiar with ActiveMQ configuration so the answer 
might be trivial).

> Provide ActiveMQ implementation of the MoM API in SLING-5646
> 
>
> Key: SLING-5647
> URL: https://issues.apache.org/jira/browse/SLING-5647
> Project: Sling
>  Issue Type: Sub-task
>Reporter: Ian Boston
>Assignee: Ian Boston
>
> Provide a default implementation of the MoM API in SLING-5646 using ActiveMQ. 
> The bundle must create and start a running ActiveMQ server without additional 
> intervention and configuration. Ideally the bundle should work in a cluster 
> embedding an ActiveMQ broker into each Sling instance, and ideally the bundle 
> should be able to integrate with an existing ActiveMQ cluster. Based on AMQ 
> documentation all are possible via configuration and no code changes.



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

[jira] [Resolved] (SLING-5633) Importing users fails with OakConstraint0022: Authorizable property rep:principalName may not be altered after user/group creation

[Marius Petria (JIRA)]

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

Marius Petria resolved SLING-5633.
--
   Resolution: Fixed
Fix Version/s: Content Distribution Core 0.1.18

Fixed by allowing setup of autosave threshold

> Importing users fails with OakConstraint0022: Authorizable property 
> rep:principalName may not be altered after user/group creation
> --
>
> Key: SLING-5633
> URL: https://issues.apache.org/jira/browse/SLING-5633
> Project: Sling
>  Issue Type: Bug
>  Components: Distribution
>Affects Versions: Content Distribution Core 0.1.8
>Reporter: Marius Petria
>Assignee: Marius Petria
> Fix For: Content Distribution Core 0.1.18
>
>




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

[jira] [Resolved] (SLING-5577) Distribution package implementation should be independent of serialization

[Marius Petria (JIRA)]

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

Marius Petria resolved SLING-5577.
--
   Resolution: Fixed
 Assignee: Marius Petria  (was: Tommaso Teofili)
Fix Version/s: (was: Content Distribution 0.2.0)
   Content Distribution Core 0.1.18

> Distribution package implementation should be independent of serialization
> --
>
> Key: SLING-5577
> URL: https://issues.apache.org/jira/browse/SLING-5577
> Project: Sling
>  Issue Type: Improvement
>  Components: Distribution
>Reporter: Tommaso Teofili
>Assignee: Marius Petria
> Fix For: Content Distribution Core 0.1.18
>
> Attachments: SLING-5577.0.patch, SLING-5577.1.patch, 
> SLING-5577.2.patch
>
>
> Currently we have different implementations of {{DistributionPackage}} 
> interface in _org.apache.sling.distribution.core_ and 
> _org.apache.sling.distribution.extensions_, some are based on plain files, 
> some on FileVault packages (backed by files or JCR content) however it'd be 
> good that packages would be agnostic to serialization type, simply based on 
> {{Resources}}.



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

[jira] [Resolved] (SLING-5657) Distribution packages persisted in files should also have their refs in files

[Marius Petria (JIRA)]

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

Marius Petria resolved SLING-5657.
--
   Resolution: Fixed
Fix Version/s: Content Distribution Core 0.1.18

> Distribution packages persisted in files should also have their refs in files
> -
>
> Key: SLING-5657
> URL: https://issues.apache.org/jira/browse/SLING-5657
> Project: Sling
>  Issue Type: Improvement
>  Components: Distribution
>Reporter: Marius Petria
> Fix For: Content Distribution Core 0.1.18
>
>




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

[jira] [Resolved] (SLING-5630) Update distribution ITs to use latest vault release

[Marius Petria (JIRA)]

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

Marius Petria resolved SLING-5630.
--
   Resolution: Fixed
Fix Version/s: Content Distribution Core 0.1.18

> Update distribution ITs to use latest vault release 
> 
>
> Key: SLING-5630
> URL: https://issues.apache.org/jira/browse/SLING-5630
> Project: Sling
>  Issue Type: Test
>  Components: Distribution
>Reporter: Marius Petria
>Assignee: Marius Petria
> Fix For: Content Distribution Core 0.1.18
>
>




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

[jira] [Resolved] (SLING-5576) Optimize queue items listing for big number of items by using iterators

[Marius Petria (JIRA)]

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

Marius Petria resolved SLING-5576.
--
   Resolution: Fixed
Fix Version/s: Content Distribution Core 0.1.18

> Optimize queue items listing for big number of items by using iterators
> ---
>
> Key: SLING-5576
> URL: https://issues.apache.org/jira/browse/SLING-5576
> Project: Sling
>  Issue Type: Improvement
>  Components: Distribution
>Reporter: Marius Petria
>Assignee: Marius Petria
> Fix For: Content Distribution Core 0.1.18
>
>
> We should an iterator when retrieving queue items as it can happen to have 
> tens of thousands of items in the queue.



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

[jira] [Commented] (SLING-5576) Optimize queue items listing for big number of items by using iterators

[Marius Petria (JIRA)]

[ 
https://issues.apache.org/jira/browse/SLING-5576?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15239101#comment-15239101
 ] 

Marius Petria commented on SLING-5576:
--

Committed revision 1738924.


> Optimize queue items listing for big number of items by using iterators
> ---
>
> Key: SLING-5576
> URL: https://issues.apache.org/jira/browse/SLING-5576
> Project: Sling
>  Issue Type: Improvement
>  Components: Distribution
>Reporter: Marius Petria
>Assignee: Marius Petria
>
> We should an iterator when retrieving queue items as it can happen to have 
> tens of thousands of items in the queue.



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

[jira] [Commented] (SLING-5657) Distribution packages persisted in files should also have their refs in files

[Marius Petria (JIRA)]

[ 
https://issues.apache.org/jira/browse/SLING-5657?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15234798#comment-15234798
 ] 

Marius Petria commented on SLING-5657:
--

Committed revision 1738560.


> Distribution packages persisted in files should also have their refs in files
> -
>
> Key: SLING-5657
> URL: https://issues.apache.org/jira/browse/SLING-5657
> Project: Sling
>  Issue Type: Improvement
>  Components: Distribution
>Reporter: Marius Petria
>




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

[jira] [Created] (SLING-5657) Distribution packages persisted in files should also have their refs in files

[Marius Petria (JIRA)]

Marius Petria created SLING-5657:


 Summary: Distribution packages persisted in files should also have 
their refs in files
 Key: SLING-5657
 URL: https://issues.apache.org/jira/browse/SLING-5657
 Project: Sling
  Issue Type: Improvement
  Components: Distribution
Reporter: Marius Petria






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

[jira] [Commented] (SLING-5577) Distribution package implementation should be independent of serialization

[Marius Petria (JIRA)]

[ 
https://issues.apache.org/jira/browse/SLING-5577?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15234780#comment-15234780
 ] 

Marius Petria commented on SLING-5577:
--

I commited the refactorization in revision 1738558.


> Distribution package implementation should be independent of serialization
> --
>
> Key: SLING-5577
> URL: https://issues.apache.org/jira/browse/SLING-5577
> Project: Sling
>  Issue Type: Improvement
>  Components: Distribution
>Reporter: Tommaso Teofili
>Assignee: Tommaso Teofili
> Fix For: Content Distribution 0.2.0
>
> Attachments: SLING-5577.0.patch, SLING-5577.1.patch, 
> SLING-5577.2.patch
>
>
> Currently we have different implementations of {{DistributionPackage}} 
> interface in _org.apache.sling.distribution.core_ and 
> _org.apache.sling.distribution.extensions_, some are based on plain files, 
> some on FileVault packages (backed by files or JCR content) however it'd be 
> good that packages would be agnostic to serialization type, simply based on 
> {{Resources}}.



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

[jira] [Commented] (SLING-5640) add import distribution events

[Marius Petria (JIRA)]

[ 
https://issues.apache.org/jira/browse/SLING-5640?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15229829#comment-15229829
 ] 

Marius Petria commented on SLING-5640:
--

Events are triggered in different phases of the distribution flow [1]. I 
understand that you want to listen for 
{{DistributionEventTopics.IMPORTER_PACKAGE_IMPORTED}}.


[1] 
https://github.com/apache/sling/tree/trunk/contrib/extensions/distribution/api/src/main/java/org/apache/sling/distribution/event
[2] 
https://github.com/apache/sling/blob/trunk/contrib/extensions/distribution/api/src/main/java/org/apache/sling/distribution/event/DistributionEventTopics.java#L50

> add import distribution events
> --
>
> Key: SLING-5640
> URL: https://issues.apache.org/jira/browse/SLING-5640
> Project: Sling
>  Issue Type: Bug
>  Components: Distribution
>Reporter: Nicolas Peltier
>
> in order to handle distribution import, it would be handy to have a 
> distribution topic to listen to, ideally with the list of paths changed, or 
> at least the filters. i guess this should be added to the package importers ?



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

[jira] [Created] (SLING-5633) Importing users fails with OakConstraint0022: Authorizable property rep:principalName may not be altered after user/group creation

[Marius Petria (JIRA)]

Marius Petria created SLING-5633:


 Summary: Importing users fails with OakConstraint0022: 
Authorizable property rep:principalName may not be altered after user/group 
creation
 Key: SLING-5633
 URL: https://issues.apache.org/jira/browse/SLING-5633
 Project: Sling
  Issue Type: Bug
  Components: Distribution
Affects Versions: Content Distribution Core 0.1.8
Reporter: Marius Petria
Assignee: Marius Petria






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

[jira] [Commented] (SLING-5630) Update distribution ITs to use latest vault release

[Marius Petria (JIRA)]

[ 
https://issues.apache.org/jira/browse/SLING-5630?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15214145#comment-15214145
 ] 

Marius Petria commented on SLING-5630:
--

Committed revision 1736880.


> Update distribution ITs to use latest vault release 
> 
>
> Key: SLING-5630
> URL: https://issues.apache.org/jira/browse/SLING-5630
> Project: Sling
>  Issue Type: Test
>  Components: Distribution
>Reporter: Marius Petria
>Assignee: Marius Petria
>




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

[jira] [Created] (SLING-5630) Update distribution ITs to use latest vault release

[Marius Petria (JIRA)]

Marius Petria created SLING-5630:


 Summary: Update distribution ITs to use latest vault release 
 Key: SLING-5630
 URL: https://issues.apache.org/jira/browse/SLING-5630
 Project: Sling
  Issue Type: Test
  Components: Distribution
Reporter: Marius Petria
Assignee: Marius Petria






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

[jira] [Commented] (SLING-5619) 3 IT failures in org.apache.sling.distribution.it

[Marius Petria (JIRA)]

[ 
https://issues.apache.org/jira/browse/SLING-5619?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15201121#comment-15201121
 ] 

Marius Petria commented on SLING-5619:
--

I reverted the changes for SLING-5576 (revision 1735543) that introduced the 
failures.


> 3 IT failures in org.apache.sling.distribution.it
> -
>
> Key: SLING-5619
> URL: https://issues.apache.org/jira/browse/SLING-5619
> Project: Sling
>  Issue Type: Bug
>  Components: Extensions
>Reporter: Robert Munteanu
>Assignee: Tommaso Teofili
> Fix For: Content Distribution 0.2.0
>
>
> Both locally and on Jenkins I get the following test failures:
> {noformat}  
> MultipleForwardDistributionTest.testAddContentCheckPassiveQueue:88 
> expected:<0> but was:<1>
>   MultipleQueueDistributionTest.testCopyDistributeQueues:132 expected:<0> but 
> was:<1>
>   MultipleQueueDistributionTest.testDistributeQueues:80 expected:<2> but 
> was:<1>{noformat}
> [~teofili], [~mpetria], any ideas?



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

[jira] [Reopened] (SLING-5576) Optimize queue items listing for big number of items by using iterators

[Marius Petria (JIRA)]

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

Marius Petria reopened SLING-5576:
--

Reopened as this caused IT failures (see SLING-5619).

> Optimize queue items listing for big number of items by using iterators
> ---
>
> Key: SLING-5576
> URL: https://issues.apache.org/jira/browse/SLING-5576
> Project: Sling
>  Issue Type: Improvement
>  Components: Distribution
>Reporter: Marius Petria
>Assignee: Marius Petria
>
> We should an iterator when retrieving queue items as it can happen to have 
> tens of thousands of items in the queue.



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

[jira] [Resolved] (SLING-5619) 3 IT failures in org.apache.sling.distribution.it

[Marius Petria (JIRA)]

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

Marius Petria resolved SLING-5619.
--
   Resolution: Fixed
 Assignee: Marius Petria  (was: Tommaso Teofili)
Fix Version/s: (was: Content Distribution 0.2.0)
   Content Distribution Core 0.1.16

> 3 IT failures in org.apache.sling.distribution.it
> -
>
> Key: SLING-5619
> URL: https://issues.apache.org/jira/browse/SLING-5619
> Project: Sling
>  Issue Type: Bug
>  Components: Extensions
>Reporter: Robert Munteanu
>Assignee: Marius Petria
> Fix For: Content Distribution Core 0.1.16
>
>
> Both locally and on Jenkins I get the following test failures:
> {noformat}  
> MultipleForwardDistributionTest.testAddContentCheckPassiveQueue:88 
> expected:<0> but was:<1>
>   MultipleQueueDistributionTest.testCopyDistributeQueues:132 expected:<0> but 
> was:<1>
>   MultipleQueueDistributionTest.testDistributeQueues:80 expected:<2> but 
> was:<1>{noformat}
> [~teofili], [~mpetria], any ideas?



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

[jira] [Resolved] (SLING-5576) Optimize queue items listing for big number of items by using iterators

[Marius Petria (JIRA)]

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

Marius Petria resolved SLING-5576.
--
Resolution: Fixed

Committed revision 1733486.


> Optimize queue items listing for big number of items by using iterators
> ---
>
> Key: SLING-5576
> URL: https://issues.apache.org/jira/browse/SLING-5576
> Project: Sling
>  Issue Type: Improvement
>  Components: Distribution
>Reporter: Marius Petria
>Assignee: Marius Petria
>
> We should an iterator when retrieving queue items as it can happen to have 
> tens of thousands of items in the queue.



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

[jira] [Commented] (SLING-5578) Json rendering is using recursion for processing flat trees and causes stack overflows

[Marius Petria (JIRA)]

[ 
https://issues.apache.org/jira/browse/SLING-5578?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15175779#comment-15175779
 ] 

Marius Petria commented on SLING-5578:
--

No problem :), just as an historical reference this issue is in Sling probably 
for a long time. The oldest reference that I could find is from 2010.

[1] 
https://github.com/apache/sling/blob/4670a41a230adc0faef1b23ca519022d94045fe4/bundles/servlets/get/src/main/java/org/apache/sling/servlets/get/impl/helpers/ResourceTraversor.java

> Json rendering is using recursion for processing flat trees and causes stack 
> overflows
> --
>
> Key: SLING-5578
> URL: https://issues.apache.org/jira/browse/SLING-5578
> Project: Sling
>  Issue Type: Bug
>  Components: Commons
>Reporter: Marius Petria
> Attachments: SLING-5578.diff, SLING-5578.test.diff
>
>
> {{ResourceTraversor.collectChildren}} is unnecessarily using recursion and 
> causes stack overflows for flat trees.
> Example: for a node with 10k direct children it adds 10k calls on the stack. 
> This should be implemented in an iterative way or at most it should do 
> recursion only for the tree depth.
> [1] 
> https://github.com/apache/sling/blob/7c4a53755aed1211c9af313a3973cd2543a7bbe0/bundles/commons/json/src/main/java/org/apache/sling/commons/json/sling/ResourceTraversor.java#L84



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

[jira] [Commented] (SLING-5578) Json rendering is using recursion for processing flat trees and causes stack overflows

[Marius Petria (JIRA)]

[ 
https://issues.apache.org/jira/browse/SLING-5578?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15175713#comment-15175713
 ] 

Marius Petria commented on SLING-5578:
--

The change is somehow trivial (just three lines of code basically), but I agree 
there should be tests for this class.

> Json rendering is using recursion for processing flat trees and causes stack 
> overflows
> --
>
> Key: SLING-5578
> URL: https://issues.apache.org/jira/browse/SLING-5578
> Project: Sling
>  Issue Type: Bug
>  Components: Commons
>Reporter: Marius Petria
> Attachments: SLING-5578.diff, SLING-5578.test.diff
>
>
> {{ResourceTraversor.collectChildren}} is unnecessarily using recursion and 
> causes stack overflows for flat trees.
> Example: for a node with 10k direct children it adds 10k calls on the stack. 
> This should be implemented in an iterative way or at most it should do 
> recursion only for the tree depth.
> [1] 
> https://github.com/apache/sling/blob/7c4a53755aed1211c9af313a3973cd2543a7bbe0/bundles/commons/json/src/main/java/org/apache/sling/commons/json/sling/ResourceTraversor.java#L84



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

[jira] [Updated] (SLING-5578) Json rendering is using recursion for processing flat trees and causes stack overflows

[Marius Petria (JIRA)]

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

Marius Petria updated SLING-5578:
-
Attachment: SLING-5578.test.diff

I attached a test for the current problem: a node with 20K children causing 
StackOverflow. I will try to write more tests for ResourceTraversor to guard 
againt regressions.

> Json rendering is using recursion for processing flat trees and causes stack 
> overflows
> --
>
> Key: SLING-5578
> URL: https://issues.apache.org/jira/browse/SLING-5578
> Project: Sling
>  Issue Type: Bug
>  Components: Commons
>Reporter: Marius Petria
> Attachments: SLING-5578.diff, SLING-5578.test.diff
>
>
> {{ResourceTraversor.collectChildren}} is unnecessarily using recursion and 
> causes stack overflows for flat trees.
> Example: for a node with 10k direct children it adds 10k calls on the stack. 
> This should be implemented in an iterative way or at most it should do 
> recursion only for the tree depth.
> [1] 
> https://github.com/apache/sling/blob/7c4a53755aed1211c9af313a3973cd2543a7bbe0/bundles/commons/json/src/main/java/org/apache/sling/commons/json/sling/ResourceTraversor.java#L84



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

[jira] [Comment Edited] (SLING-5578) Json rendering is using recursion for processing flat trees and causes stack overflows

[Marius Petria (JIRA)]

[ 
https://issues.apache.org/jira/browse/SLING-5578?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15175584#comment-15175584
 ] 

Marius Petria edited comment on SLING-5578 at 3/2/16 1:29 PM:
--

This can be fixed by doing processing only at first level of recursion. 
[~cziegeler] [~bdelacretaz] can you please have a look?


was (Author: mpetria):
This can be fixed by doing processing only at first level of recursion.

> Json rendering is using recursion for processing flat trees and causes stack 
> overflows
> --
>
> Key: SLING-5578
> URL: https://issues.apache.org/jira/browse/SLING-5578
> Project: Sling
>  Issue Type: Bug
>  Components: Commons
>Reporter: Marius Petria
> Attachments: SLING-5578.diff
>
>
> {{ResourceTraversor.collectChildren}} is unnecessarily using recursion and 
> causes stack overflows for flat trees.
> Example: for a node with 10k direct children it adds 10k calls on the stack. 
> This should be implemented in an iterative way or at most it should do 
> recursion only for the tree depth.
> [1] 
> https://github.com/apache/sling/blob/7c4a53755aed1211c9af313a3973cd2543a7bbe0/bundles/commons/json/src/main/java/org/apache/sling/commons/json/sling/ResourceTraversor.java#L84



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

[jira] [Updated] (SLING-5578) Json rendering is using recursion for processing flat trees and causes stack overflows

[Marius Petria (JIRA)]

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

Marius Petria updated SLING-5578:
-
Attachment: SLING-5578.diff

This can be fixed by doing processing only at first level of recursion.

> Json rendering is using recursion for processing flat trees and causes stack 
> overflows
> --
>
> Key: SLING-5578
> URL: https://issues.apache.org/jira/browse/SLING-5578
> Project: Sling
>  Issue Type: Bug
>  Components: Commons
>Reporter: Marius Petria
> Attachments: SLING-5578.diff
>
>
> {{ResourceTraversor.collectChildren}} is unnecessarily using recursion and 
> causes stack overflows for flat trees.
> Example: for a node with 10k direct children it adds 10k calls on the stack. 
> This should be implemented in an iterative way or at most it should do 
> recursion only for the tree depth.
> [1] 
> https://github.com/apache/sling/blob/7c4a53755aed1211c9af313a3973cd2543a7bbe0/bundles/commons/json/src/main/java/org/apache/sling/commons/json/sling/ResourceTraversor.java#L84



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

[jira] [Created] (SLING-5578) Json rendering is using recursion for processing flat trees and causes stack overflows

[Marius Petria (JIRA)]

Marius Petria created SLING-5578:


 Summary: Json rendering is using recursion for processing flat 
trees and causes stack overflows
 Key: SLING-5578
 URL: https://issues.apache.org/jira/browse/SLING-5578
 Project: Sling
  Issue Type: Bug
  Components: Commons
Reporter: Marius Petria


{{ResourceTraversor.collectChildren}} is unnecessarily using recursion and 
causes stack overflows for flat trees.

Example: for a node with 10k direct children it adds 10k calls on the stack. 
This should be implemented in an iterative way or at most it should do 
recursion only for the tree depth.

[1] 
https://github.com/apache/sling/blob/7c4a53755aed1211c9af313a3973cd2543a7bbe0/bundles/commons/json/src/main/java/org/apache/sling/commons/json/sling/ResourceTraversor.java#L84





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

[jira] [Created] (SLING-5576) Optimize queue items listing for big number of items by using iterators

[Marius Petria (JIRA)]

Marius Petria created SLING-5576:


 Summary: Optimize queue items listing for big number of items by 
using iterators
 Key: SLING-5576
 URL: https://issues.apache.org/jira/browse/SLING-5576
 Project: Sling
  Issue Type: Improvement
  Components: Distribution
Reporter: Marius Petria
Assignee: Marius Petria


We should an iterator when retrieving queue items as it can happen to have tens 
of thousands of items in the queue.



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

[jira] [Resolved] (SLING-5550) Optimize acquire package operation to make fewer saves

[Marius Petria (JIRA)]

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

Marius Petria resolved SLING-5550.
--
Resolution: Fixed

Committed revision 1731829.


> Optimize acquire package operation to make fewer saves
> --
>
> Key: SLING-5550
> URL: https://issues.apache.org/jira/browse/SLING-5550
> Project: Sling
>  Issue Type: Improvement
>  Components: Distribution
>Reporter: Marius Petria
>
> Currently the SharedDistributionPackage.acquire is called for each queue and 
> a save into the repo is done each time. We can send an array of queues for 
> which the package should be acquired and do just one save for all queues.



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

[jira] [Created] (SLING-5550) Optimize acquire package operation to make fewer saves

[Marius Petria (JIRA)]

Marius Petria created SLING-5550:


 Summary: Optimize acquire package operation to make fewer saves
 Key: SLING-5550
 URL: https://issues.apache.org/jira/browse/SLING-5550
 Project: Sling
  Issue Type: Improvement
  Components: Distribution
Reporter: Marius Petria


Currently the SharedDistributionPackage.acquire is called for each queue and a 
save into the repo is done each time. We can send an array of queues for which 
the package should be acquired and do just one save for all queues.



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

[jira] [Resolved] (SLING-5536) Add integration test for binaryless distribution

[Marius Petria (JIRA)]

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

Marius Petria resolved SLING-5536.
--
Resolution: Fixed
  Assignee: Marius Petria

Thanks [~dulceanu], I commited a slightly modified fix in revision 1731606.


> Add integration test for binaryless distribution
> 
>
> Key: SLING-5536
> URL: https://issues.apache.org/jira/browse/SLING-5536
> Project: Sling
>  Issue Type: Improvement
>  Components: Distribution, Testing
>Reporter: Andrei Dulceanu
>Assignee: Marius Petria
> Attachments: binaryless-test.patch
>
>
> Add integration test for binaryless distribution



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

[jira] [Commented] (SLING-5512) Improve JobManager.findJobs querying by supporting skip items

[Marius Petria (JIRA)]

[ 
https://issues.apache.org/jira/browse/SLING-5512?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15144371#comment-15144371
 ] 

Marius Petria commented on SLING-5512:
--

The use case I am concerned with is Content Distribution queues, and the 
scalability of the UI when there are a lot of packages to distribute. But I 
think we can use limits in UI not to display more than 1000 jobs.

> Improve JobManager.findJobs querying by supporting skip items
> -
>
> Key: SLING-5512
> URL: https://issues.apache.org/jira/browse/SLING-5512
> Project: Sling
>  Issue Type: Improvement
>  Components: Extensions
>Reporter: Marius Petria
>
> Currently findJobs API only accepts a limit parameter to restrict the size of 
> the retrieved collection. In order to better support paged views of jobs we 
> should also support a skip parameter. 
> Also it would be very useful to have a countJobs API aswell.
> [1] 
> https://sling.apache.org/apidocs/sling8/org/apache/sling/event/jobs/JobManager.html



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

[jira] [Created] (SLING-5512) Improve JobManager.findJobs querying by supporting skip items

[Marius Petria (JIRA)]

Marius Petria created SLING-5512:


 Summary: Improve JobManager.findJobs querying by supporting skip 
items
 Key: SLING-5512
 URL: https://issues.apache.org/jira/browse/SLING-5512
 Project: Sling
  Issue Type: Improvement
  Components: Extensions
Reporter: Marius Petria


Currently findJobs API only accepts a limit parameter to restrict the size of 
the retrieved collection. In order to better support paged views of jobs we 
should also support a skip parameter. 

Also it would be very useful to have a countJobs API aswell.

[1] 
https://sling.apache.org/apidocs/sling8/org/apache/sling/event/jobs/JobManager.html



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

[jira] [Commented] (SLING-5512) Improve JobManager.findJobs querying by supporting skip items

[Marius Petria (JIRA)]

[ 
https://issues.apache.org/jira/browse/SLING-5512?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15144356#comment-15144356
 ] 

Marius Petria commented on SLING-5512:
--

The problem is that without these APIs visualization/counting of jobs becomes 
quite expensive in cases of tens of thousands of jobs. In order to still be 
efficient one needs to store a parallel collection of nodes that represent the 
jobs for visualization and keep it in sync with the job items. Is that the 
preferred alternative?

> Improve JobManager.findJobs querying by supporting skip items
> -
>
> Key: SLING-5512
> URL: https://issues.apache.org/jira/browse/SLING-5512
> Project: Sling
>  Issue Type: Improvement
>  Components: Extensions
>Reporter: Marius Petria
>
> Currently findJobs API only accepts a limit parameter to restrict the size of 
> the retrieved collection. In order to better support paged views of jobs we 
> should also support a skip parameter. 
> Also it would be very useful to have a countJobs API aswell.
> [1] 
> https://sling.apache.org/apidocs/sling8/org/apache/sling/event/jobs/JobManager.html



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

[jira] [Resolved] (SLING-5512) Improve JobManager.findJobs querying by supporting skip items

[Marius Petria (JIRA)]

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

Marius Petria resolved SLING-5512.
--
Resolution: Won't Fix

OK, I will close it as won't fix and display only some items from the queue.

> Improve JobManager.findJobs querying by supporting skip items
> -
>
> Key: SLING-5512
> URL: https://issues.apache.org/jira/browse/SLING-5512
> Project: Sling
>  Issue Type: Improvement
>  Components: Extensions
>Reporter: Marius Petria
>
> Currently findJobs API only accepts a limit parameter to restrict the size of 
> the retrieved collection. In order to better support paged views of jobs we 
> should also support a skip parameter. 
> Also it would be very useful to have a countJobs API aswell.
> [1] 
> https://sling.apache.org/apidocs/sling8/org/apache/sling/event/jobs/JobManager.html



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

[jira] [Resolved] (SLING-5396) Exported packages should be processed immediately

[Marius Petria (JIRA)]

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

Marius Petria resolved SLING-5396.
--
   Resolution: Fixed
 Assignee: Marius Petria
Fix Version/s: Content Distribution Core 0.1.14

> Exported packages should be processed immediately
> -
>
> Key: SLING-5396
> URL: https://issues.apache.org/jira/browse/SLING-5396
> Project: Sling
>  Issue Type: Bug
>  Components: Distribution
>Reporter: Marius Petria
>Assignee: Marius Petria
> Fix For: Content Distribution Core 0.1.14
>
>
> Exported packages should be processed immediately and added to the queue and 
> only afterwards deleted from the remote endpoint.



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

[jira] [Resolved] (SLING-5397) Use priorityQueues instead of selectiveQueues

[Marius Petria (JIRA)]

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

Marius Petria resolved SLING-5397.
--
   Resolution: Fixed
Fix Version/s: Content Distribution Core 0.1.14

> Use priorityQueues instead of selectiveQueues
> -
>
> Key: SLING-5397
> URL: https://issues.apache.org/jira/browse/SLING-5397
> Project: Sling
>  Issue Type: Improvement
>  Components: Distribution
>Affects Versions: Content Distribution Core 0.1.10
>Reporter: Marius Petria
>Assignee: Marius Petria
> Fix For: Content Distribution Core 0.1.14
>
>




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

[jira] [Resolved] (SLING-5399) Clear info logging for distribution

[Marius Petria (JIRA)]

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

Marius Petria resolved SLING-5399.
--
   Resolution: Fixed
 Assignee: Marius Petria
Fix Version/s: Content Distribution Core 0.1.14

> Clear info logging for distribution
> ---
>
> Key: SLING-5399
> URL: https://issues.apache.org/jira/browse/SLING-5399
> Project: Sling
>  Issue Type: Improvement
>  Components: Distribution
>Reporter: Marius Petria
>Assignee: Marius Petria
> Fix For: Content Distribution Core 0.1.14
>
>
> Improve info logging for distribution.
> Agent should log on info level:
> EXECUTE requestDetails noOfPackages exportTime noOfQueues enqueueTime
> DELIVER queueName packageDetails importTime
> Standalone exporter should log
> EXPORT requestDetails exportTime
> Standalone importer should log
> IMPORT packageDetail importTime



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

[jira] [Commented] (SLING-5466) Pending distribution changes are lost if the Apache Sling Distribution Agent - Sync Agents Factory configuration is changed.

[Marius Petria (JIRA)]

[ 
https://issues.apache.org/jira/browse/SLING-5466?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15130179#comment-15130179
 ] 

Marius Petria commented on SLING-5466:
--

[~jaybrown] that probably happens if the list of endpoints is changed. In order 
to have a stable name for your endpoint you should give it an explicit label 

{noformat}
packageImporter.endpoints = ["endpoint0=http://localhost:4503/;, 
"endpoint4=http://localhost:4504/;]
{noformat}

> Pending distribution changes are lost if the  Apache Sling Distribution Agent 
> - Sync Agents Factory configuration is changed.
> -
>
> Key: SLING-5466
> URL: https://issues.apache.org/jira/browse/SLING-5466
> Project: Sling
>  Issue Type: Bug
>  Components: Distribution
>Affects Versions: Content Distribution Core 0.1.4
> Environment: Windows 7 x64, AEM/CQ 6.1.0
>Reporter: Jay Brown
>  Labels: patch
>
> [Using Content Distribution Core 0.1.3.r1680309 -- wasn't available in the 
> list]
> When running Sling with pending distribution changes queued for a node that 
> is down, a change to the Sling Distribution Agent - Sync Agents Factory 
> configuration can cause the pending changes to be distributed to the wrong 
> Sling node.
> It appears that changes to be distributed to a node are assigned to a generic 
> "endpoint" name (not the host, itself).  During the creation of the change 
> nodes, the index (position) of the distribution target host in the 
> packageExporter.endpoints OSGi configuration field is used to assign the 
> pending changes to an endpoint named "endpoint[n])," where [n] is the 
> position of the server address packageExporter.endpoints field.  If 
> distribution changes are queued for a host that is down AND the order of the 
> packageExporter.endpoints is changed, which potentially causes endpoint[n] to 
> represent a different host, the changes are then shipped off to the wrong 
> host, and the original host never receives the queued changes.



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

[jira] [Updated] (SLING-5479) Run distribution integration tests with launchpad 8

[Marius Petria (JIRA)]

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

Marius Petria updated SLING-5479:
-
Attachment: SLING-5479.2.diff

I modified a little bit the patch to correct the service users creation.

> Run distribution integration tests with launchpad 8
> ---
>
> Key: SLING-5479
> URL: https://issues.apache.org/jira/browse/SLING-5479
> Project: Sling
>  Issue Type: Improvement
>  Components: Distribution, Testing
>Reporter: Andrei Dulceanu
>Priority: Minor
> Attachments: SLING-5479.2.diff, SLING-5479.patch
>
>
> At the moment the integration tests from distribution module are run with 
> launchpad 7. We should run them against the latest launchpad 8.



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

[jira] [Resolved] (SLING-5479) Run distribution integration tests with launchpad 8

[Marius Petria (JIRA)]

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

Marius Petria resolved SLING-5479.
--
   Resolution: Fixed
Fix Version/s: Content Distribution Core 0.1.14

Thanks [~dulceanu], I committed a slightly modified version in revision 1728301.


> Run distribution integration tests with launchpad 8
> ---
>
> Key: SLING-5479
> URL: https://issues.apache.org/jira/browse/SLING-5479
> Project: Sling
>  Issue Type: Improvement
>  Components: Distribution
>Reporter: Andrei Dulceanu
>Assignee: Marius Petria
>Priority: Minor
> Fix For: Content Distribution Core 0.1.14
>
> Attachments: SLING-5479.2.diff, SLING-5479.patch
>
>
> At the moment the integration tests from distribution module are run with 
> launchpad 7. We should run them against the latest launchpad 8.



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

[jira] [Updated] (SLING-5479) Run distribution integration tests with launchpad 8

[Marius Petria (JIRA)]

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

Marius Petria updated SLING-5479:
-
Component/s: (was: Testing)

> Run distribution integration tests with launchpad 8
> ---
>
> Key: SLING-5479
> URL: https://issues.apache.org/jira/browse/SLING-5479
> Project: Sling
>  Issue Type: Improvement
>  Components: Distribution
>Reporter: Andrei Dulceanu
>Assignee: Marius Petria
>Priority: Minor
> Attachments: SLING-5479.2.diff, SLING-5479.patch
>
>
> At the moment the integration tests from distribution module are run with 
> launchpad 7. We should run them against the latest launchpad 8.



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

[jira] [Assigned] (SLING-5479) Run distribution integration tests with launchpad 8

[Marius Petria (JIRA)]

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

Marius Petria reassigned SLING-5479:


Assignee: Marius Petria

> Run distribution integration tests with launchpad 8
> ---
>
> Key: SLING-5479
> URL: https://issues.apache.org/jira/browse/SLING-5479
> Project: Sling
>  Issue Type: Improvement
>  Components: Distribution, Testing
>Reporter: Andrei Dulceanu
>Assignee: Marius Petria
>Priority: Minor
> Attachments: SLING-5479.2.diff, SLING-5479.patch
>
>
> At the moment the integration tests from distribution module are run with 
> launchpad 7. We should run them against the latest launchpad 8.



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

[jira] [Created] (SLING-5472) Some distribution packages are leaked because delete is called on closed objects

[Marius Petria (JIRA)]

Marius Petria created SLING-5472:


 Summary: Some distribution packages are leaked because delete is 
called on closed objects
 Key: SLING-5472
 URL: https://issues.apache.org/jira/browse/SLING-5472
 Project: Sling
  Issue Type: Bug
  Components: Distribution
Reporter: Marius Petria
Assignee: Marius Petria
 Fix For: Content Distribution Core 0.1.14






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

[jira] [Resolved] (SLING-5472) Some distribution packages are leaked because delete is called on closed objects

[Marius Petria (JIRA)]

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

Marius Petria resolved SLING-5472.
--
Resolution: Fixed

Committed revision 1727938.


> Some distribution packages are leaked because delete is called on closed 
> objects
> 
>
> Key: SLING-5472
> URL: https://issues.apache.org/jira/browse/SLING-5472
> Project: Sling
>  Issue Type: Bug
>  Components: Distribution
>Reporter: Marius Petria
>Assignee: Marius Petria
> Fix For: Content Distribution Core 0.1.14
>
>




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

[jira] [Resolved] (SLING-5473) Improve parallelism of package acquire/release

[Marius Petria (JIRA)]

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

Marius Petria resolved SLING-5473.
--
Resolution: Fixed

Committed revision 1727953.


> Improve parallelism of package acquire/release
> --
>
> Key: SLING-5473
> URL: https://issues.apache.org/jira/browse/SLING-5473
> Project: Sling
>  Issue Type: Bug
>  Components: Distribution
>Reporter: Marius Petria
>Assignee: Marius Petria
> Fix For: Content Distribution Core 0.1.14
>
>
> We should not use locks when acquiring/releasing packages



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

[jira] [Created] (SLING-5473) Improve parallelism of package acquire/release

[Marius Petria (JIRA)]

Marius Petria created SLING-5473:


 Summary: Improve parallelism of package acquire/release
 Key: SLING-5473
 URL: https://issues.apache.org/jira/browse/SLING-5473
 Project: Sling
  Issue Type: Bug
  Components: Distribution
Reporter: Marius Petria
Assignee: Marius Petria
 Fix For: Content Distribution Core 0.1.14


We should not use locks when acquiring/releasing packages



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

[jira] [Created] (SLING-5465) Allow distribution of OSGI events via Distributor API

[Marius Petria (JIRA)]

Marius Petria created SLING-5465:


 Summary: Allow distribution of OSGI events via Distributor API
 Key: SLING-5465
 URL: https://issues.apache.org/jira/browse/SLING-5465
 Project: Sling
  Issue Type: Improvement
  Components: Distribution
Reporter: Marius Petria
Assignee: Marius Petria


We should expose a new Distributor API that allows to distribute events across 
connected instances:

{noformat}
Distributor.distribute(eventTopic, eventProperties)
{noformat}

This would trigger a synchronous event on all endpoints. 



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

[jira] [Resolved] (SLING-5432) Implement binaryless distribution

[Marius Petria (JIRA)]

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

Marius Petria resolved SLING-5432.
--
Resolution: Fixed
  Assignee: Marius Petria

Thanks [~dulceanu], I commited the patch in revision 1727381.


> Implement binaryless distribution
> -
>
> Key: SLING-5432
> URL: https://issues.apache.org/jira/browse/SLING-5432
> Project: Sling
>  Issue Type: Improvement
>  Components: Distribution
>Reporter: Marius Petria
>Assignee: Marius Petria
> Fix For: Content Distribution Core 0.1.14
>
> Attachments: 0001-GRANITE-3581-Binary-less-distribution.patch
>
>
> We should allow configuration of vault package builders not to include 
> binaries using JCRVLT-97



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

[jira] [Created] (SLING-5444) Display nameHints in webConsole for distribution factories

[Marius Petria (JIRA)]

Marius Petria created SLING-5444:


 Summary: Display nameHints in webConsole for distribution factories
 Key: SLING-5444
 URL: https://issues.apache.org/jira/browse/SLING-5444
 Project: Sling
  Issue Type: Improvement
Reporter: Marius Petria
Assignee: Marius Petria
 Fix For: Content Distribution Core 0.1.14






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

[jira] [Resolved] (SLING-5444) Display nameHints in webConsole for distribution factories

[Marius Petria (JIRA)]

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

Marius Petria resolved SLING-5444.
--
Resolution: Fixed

> Display nameHints in webConsole for distribution factories
> --
>
> Key: SLING-5444
> URL: https://issues.apache.org/jira/browse/SLING-5444
> Project: Sling
>  Issue Type: Improvement
>Reporter: Marius Petria
>Assignee: Marius Petria
> Fix For: Content Distribution Core 0.1.14
>
>




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

[jira] [Commented] (SLING-5444) Display nameHints in webConsole for distribution factories

[Marius Petria (JIRA)]

[ 
https://issues.apache.org/jira/browse/SLING-5444?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15110262#comment-15110262
 ] 

Marius Petria commented on SLING-5444:
--

Committed revision 1725880.


> Display nameHints in webConsole for distribution factories
> --
>
> Key: SLING-5444
> URL: https://issues.apache.org/jira/browse/SLING-5444
> Project: Sling
>  Issue Type: Improvement
>Reporter: Marius Petria
>Assignee: Marius Petria
> Fix For: Content Distribution Core 0.1.14
>
>




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

[jira] [Created] (SLING-5436) Do not move distribution packages to error queues after connection problems

[Marius Petria (JIRA)]

Marius Petria created SLING-5436:


 Summary: Do not move distribution packages to error queues after 
connection problems
 Key: SLING-5436
 URL: https://issues.apache.org/jira/browse/SLING-5436
 Project: Sling
  Issue Type: Bug
  Components: Distribution
Reporter: Marius Petria
Assignee: Marius Petria
 Fix For: Content Distribution Core 0.1.14






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

[jira] [Resolved] (SLING-5436) Do not move distribution packages to error queues after connection problems

[Marius Petria (JIRA)]

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

Marius Petria resolved SLING-5436.
--
Resolution: Fixed

> Do not move distribution packages to error queues after connection problems
> ---
>
> Key: SLING-5436
> URL: https://issues.apache.org/jira/browse/SLING-5436
> Project: Sling
>  Issue Type: Bug
>  Components: Distribution
>Reporter: Marius Petria
>Assignee: Marius Petria
> Fix For: Content Distribution Core 0.1.14
>
>




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

[jira] [Created] (SLING-5432) Implement binaryless distribution

[Marius Petria (JIRA)]

Marius Petria created SLING-5432:


 Summary: Implement binaryless distribution
 Key: SLING-5432
 URL: https://issues.apache.org/jira/browse/SLING-5432
 Project: Sling
  Issue Type: Improvement
  Components: Distribution
Reporter: Marius Petria
 Fix For: Content Distribution Core 0.1.14


We should allow configuration of vault package builders not to include binaries 
using JCRVLT-97



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

[jira] [Created] (SLING-5430) Allow item move between distribution queues

[Marius Petria (JIRA)]

Marius Petria created SLING-5430:


 Summary: Allow item move between distribution queues
 Key: SLING-5430
 URL: https://issues.apache.org/jira/browse/SLING-5430
 Project: Sling
  Issue Type: Bug
  Components: Distribution
Reporter: Marius Petria
Assignee: Marius Petria
 Fix For: Content Distribution Core 0.1.14


{noformat}
POST /libs/.../agents/agentName/queues/queueName
operation=move=sourceQueueName=idsToMove
{noformat} 



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

[jira] [Resolved] (SLING-5430) Allow item move between distribution queues

[Marius Petria (JIRA)]

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

Marius Petria resolved SLING-5430.
--
Resolution: Fixed

Committed revision 1724744.

Also added retryQueue parameter for error queues.

> Allow item move between distribution queues
> ---
>
> Key: SLING-5430
> URL: https://issues.apache.org/jira/browse/SLING-5430
> Project: Sling
>  Issue Type: Bug
>  Components: Distribution
>Reporter: Marius Petria
>Assignee: Marius Petria
> Fix For: Content Distribution Core 0.1.14
>
>
> {noformat}
> POST /libs/.../agents/agentName/queues/queueName
> operation=move=sourceQueueName=idsToMove
> {noformat} 



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

[jira] [Created] (SLING-5429) JcrPackageBuilder should not require access to root

[Marius Petria (JIRA)]

Marius Petria created SLING-5429:


 Summary: JcrPackageBuilder should not require access to root
 Key: SLING-5429
 URL: https://issues.apache.org/jira/browse/SLING-5429
 Project: Sling
  Issue Type: Improvement
  Components: Distribution
Reporter: Marius Petria
Assignee: Marius Petria
 Fix For: Content Distribution Core 0.1.14






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

[jira] [Resolved] (SLING-5429) JcrPackageBuilder should not require access to root

[Marius Petria (JIRA)]

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

Marius Petria resolved SLING-5429.
--
Resolution: Fixed

Committed revision 1724625.


> JcrPackageBuilder should not require access to root
> ---
>
> Key: SLING-5429
> URL: https://issues.apache.org/jira/browse/SLING-5429
> Project: Sling
>  Issue Type: Improvement
>  Components: Distribution
>Reporter: Marius Petria
>Assignee: Marius Petria
> Fix For: Content Distribution Core 0.1.14
>
>




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

[jira] [Created] (SLING-5426) Expose size to distribution packages

[Marius Petria (JIRA)]

Marius Petria created SLING-5426:


 Summary: Expose size to distribution packages
 Key: SLING-5426
 URL: https://issues.apache.org/jira/browse/SLING-5426
 Project: Sling
  Issue Type: Improvement
  Components: Distribution
Reporter: Marius Petria
Assignee: Marius Petria
 Fix For: Content Distribution Core 0.1.14






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