[jira] [Commented] (SLING-8793) Content Distribution Core doesn't build with java 11
[
https://issues.apache.org/jira/browse/SLING-8793?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16957666#comment-16957666
]
Tommaso Teofili commented on SLING-8793:
are there recommended guidelines for migrating annotations and related plugins
we should follow ?
> Content Distribution Core doesn't build with java 11
>
>
> Key: SLING-8793
> URL: https://issues.apache.org/jira/browse/SLING-8793
> Project: Sling
> Issue Type: Bug
> Components: Content Distribution
>Reporter: Tommaso Teofili
>Priority: Minor
>
> When running _mvn clean install_ on _org.apache.sling.distribution.core_ I
> get a build failure like the following:
> {noformat}
> [INFO] BUILD FAILURE
> [INFO]
>
> [INFO] Total time: 01:07 min
> [INFO] Finished at: 2019-10-21T13:28:53+02:00
> [INFO]
>
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-enforcer-plugin:1.4.1:enforce (enforce-java)
> on project org.apache.sling.distribution.core: Execution enforce-java of goal
> org.apache.maven.plugins:maven-enforcer-plugin:1.4.1:enforce failed: An API
> incompatibility was encountered while executing
> org.apache.maven.plugins:maven-enforcer-plugin:1.4.1:enforce:
> java.lang.ExceptionInInitializerError: null
> [ERROR] -
> [ERROR] realm =plugin>org.apache.maven.plugins:maven-enforcer-plugin:1.4.1
> [ERROR] strategy = org.codehaus.plexus.classworlds.strategy.SelfFirstStrategy
> [ERROR] urls[0] =
> file:/Users/teofili/.m2/repository/org/apache/maven/plugins/maven-enforcer-plugin/1.4.1/maven-enforcer-plugin-1.4.1.jar
> [ERROR] urls[1] =
> file:/Users/teofili/.m2/repository/backport-util-concurrent/backport-util-concurrent/3.1/backport-util-concurrent-3.1.jar
> [ERROR] urls[2] =
> file:/Users/teofili/.m2/repository/org/codehaus/plexus/plexus-interpolation/1.11/plexus-interpolation-1.11.jar
> [ERROR] urls[3] =
> file:/Users/teofili/.m2/repository/org/slf4j/slf4j-jdk14/1.5.6/slf4j-jdk14-1.5.6.jar
> [ERROR] urls[4] =
> file:/Users/teofili/.m2/repository/org/slf4j/jcl-over-slf4j/1.5.6/jcl-over-slf4j-1.5.6.jar
> [ERROR] urls[5] =
> file:/Users/teofili/.m2/repository/org/apache/maven/reporting/maven-reporting-api/2.2.1/maven-reporting-api-2.2.1.jar
> [ERROR] urls[6] =
> file:/Users/teofili/.m2/repository/org/apache/maven/doxia/doxia-sink-api/1.1/doxia-sink-api-1.1.jar
> [ERROR] urls[7] =
> file:/Users/teofili/.m2/repository/org/apache/maven/doxia/doxia-logging-api/1.1/doxia-logging-api-1.1.jar
> [ERROR] urls[8] =
> file:/Users/teofili/.m2/repository/commons-cli/commons-cli/1.2/commons-cli-1.2.jar
> [ERROR] urls[9] =
> file:/Users/teofili/.m2/repository/org/codehaus/plexus/plexus-interactivity-api/1.0-alpha-4/plexus-interactivity-api-1.0-alpha-4.jar
> [ERROR] urls[10] =
> file:/Users/teofili/.m2/repository/org/sonatype/plexus/plexus-sec-dispatcher/1.3/plexus-sec-dispatcher-1.3.jar
> [ERROR] urls[11] =
> file:/Users/teofili/.m2/repository/org/sonatype/plexus/plexus-cipher/1.4/plexus-cipher-1.4.jar
> [ERROR] urls[12] =
> file:/Users/teofili/.m2/repository/org/codehaus/plexus/plexus-utils/3.0.22/plexus-utils-3.0.22.jar
> [ERROR] urls[13] =
> file:/Users/teofili/.m2/repository/commons-lang/commons-lang/2.3/commons-lang-2.3.jar
> [ERROR] urls[14] =
> file:/Users/teofili/.m2/repository/org/apache/maven/enforcer/enforcer-api/1.4.1/enforcer-api-1.4.1.jar
> [ERROR] urls[15] =
> file:/Users/teofili/.m2/repository/org/apache/maven/enforcer/enforcer-rules/1.4.1/enforcer-rules-1.4.1.jar
> [ERROR] urls[16] =
> file:/Users/teofili/.m2/repository/org/apache/maven/shared/maven-common-artifact-filters/1.4/maven-common-artifact-filters-1.4.jar
> [ERROR] urls[17] =
> file:/Users/teofili/.m2/repository/org/beanshell/bsh/2.0b4/bsh-2.0b4.jar
> [ERROR] urls[18] =
> file:/Users/teofili/.m2/repository/org/apache/maven/shared/maven-dependency-tree/2.2/maven-dependency-tree-2.2.jar
> [ERROR] urls[19] =
> file:/Users/teofili/.m2/repository/org/codehaus/plexus/plexus-component-annotations/1.5.5/plexus-component-annotations-1.5.5.jar
> [ERROR] urls[20] =
> file:/Users/teofili/.m2/repository/org/eclipse/aether/aether-util/0.9.0.M2/aether-util-0.9.0.M2.jar
> [ERROR] urls[21] =
> file:/Users/teofili/.m2/repository/org/codehaus/plexus/plexus-i18n/1.0-beta-6/plexus-i18n-1.0-beta-6.jar
> [ERROR] urls[22] =
> file:/Users/teofili/.m2/repository/org/apache/maven/plugin-testing/maven-plugin-testing-harness/1.3/maven-plugin-testing-harness-1.3.jar
> [ERROR] urls[23] =
> file:/Users/teofili/.m2/repository/org/codehaus/plexus/plexus-archiver/2.2/plexus-archiver-2.2.jar
> [ERROR] urls[24] =
>
[jira] [Resolved] (SLING-8797) Static analysis improvements on Journal code
[ https://issues.apache.org/jira/browse/SLING-8797?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tommaso Teofili resolved SLING-8797. Assignee: Tommaso Teofili Resolution: Fixed > Static analysis improvements on Journal code > > > Key: SLING-8797 > URL: https://issues.apache.org/jira/browse/SLING-8797 > Project: Sling > Issue Type: Bug > Components: Content Distribution >Reporter: Tommaso Teofili >Assignee: Tommaso Teofili >Priority: Minor > Fix For: Content Distribution Journal Core 0.1.6 > > Time Spent: 20m > Remaining Estimate: 0h > > In order to get up to speed with SCD Journal I am going through the codebase. > While doing this I also run some static analysis and would like to include a > few minor improvements, mostly related to javadoc, log statements, etc. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (SLING-8797) Static analysis improvements on Journal code
Tommaso Teofili created SLING-8797: -- Summary: Static analysis improvements on Journal code Key: SLING-8797 URL: https://issues.apache.org/jira/browse/SLING-8797 Project: Sling Issue Type: Bug Components: Content Distribution Reporter: Tommaso Teofili Fix For: Content Distribution Journal Core 0.1.6 In order to get up to speed with SCD Journal I am going through the codebase. While doing this I also run some static analysis and would like to include a few minor improvements, mostly related to javadoc, log statements, etc. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (SLING-8793) Content Distribution Core doesn't build with java 11
[
https://issues.apache.org/jira/browse/SLING-8793?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16956026#comment-16956026
]
Tommaso Teofili commented on SLING-8793:
thanks Robert.
It seems that to fix this we need to upgrade to a more recent parent release
which, in turn, requires upgrading from Felix SCR to OSGi annotations.
> Content Distribution Core doesn't build with java 11
>
>
> Key: SLING-8793
> URL: https://issues.apache.org/jira/browse/SLING-8793
> Project: Sling
> Issue Type: Bug
> Components: Content Distribution
>Reporter: Tommaso Teofili
>Priority: Minor
>
> When running _mvn clean install_ on _org.apache.sling.distribution.core_ I
> get a build failure like the following:
> {noformat}
> [INFO] BUILD FAILURE
> [INFO]
>
> [INFO] Total time: 01:07 min
> [INFO] Finished at: 2019-10-21T13:28:53+02:00
> [INFO]
>
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-enforcer-plugin:1.4.1:enforce (enforce-java)
> on project org.apache.sling.distribution.core: Execution enforce-java of goal
> org.apache.maven.plugins:maven-enforcer-plugin:1.4.1:enforce failed: An API
> incompatibility was encountered while executing
> org.apache.maven.plugins:maven-enforcer-plugin:1.4.1:enforce:
> java.lang.ExceptionInInitializerError: null
> [ERROR] -
> [ERROR] realm =plugin>org.apache.maven.plugins:maven-enforcer-plugin:1.4.1
> [ERROR] strategy = org.codehaus.plexus.classworlds.strategy.SelfFirstStrategy
> [ERROR] urls[0] =
> file:/Users/teofili/.m2/repository/org/apache/maven/plugins/maven-enforcer-plugin/1.4.1/maven-enforcer-plugin-1.4.1.jar
> [ERROR] urls[1] =
> file:/Users/teofili/.m2/repository/backport-util-concurrent/backport-util-concurrent/3.1/backport-util-concurrent-3.1.jar
> [ERROR] urls[2] =
> file:/Users/teofili/.m2/repository/org/codehaus/plexus/plexus-interpolation/1.11/plexus-interpolation-1.11.jar
> [ERROR] urls[3] =
> file:/Users/teofili/.m2/repository/org/slf4j/slf4j-jdk14/1.5.6/slf4j-jdk14-1.5.6.jar
> [ERROR] urls[4] =
> file:/Users/teofili/.m2/repository/org/slf4j/jcl-over-slf4j/1.5.6/jcl-over-slf4j-1.5.6.jar
> [ERROR] urls[5] =
> file:/Users/teofili/.m2/repository/org/apache/maven/reporting/maven-reporting-api/2.2.1/maven-reporting-api-2.2.1.jar
> [ERROR] urls[6] =
> file:/Users/teofili/.m2/repository/org/apache/maven/doxia/doxia-sink-api/1.1/doxia-sink-api-1.1.jar
> [ERROR] urls[7] =
> file:/Users/teofili/.m2/repository/org/apache/maven/doxia/doxia-logging-api/1.1/doxia-logging-api-1.1.jar
> [ERROR] urls[8] =
> file:/Users/teofili/.m2/repository/commons-cli/commons-cli/1.2/commons-cli-1.2.jar
> [ERROR] urls[9] =
> file:/Users/teofili/.m2/repository/org/codehaus/plexus/plexus-interactivity-api/1.0-alpha-4/plexus-interactivity-api-1.0-alpha-4.jar
> [ERROR] urls[10] =
> file:/Users/teofili/.m2/repository/org/sonatype/plexus/plexus-sec-dispatcher/1.3/plexus-sec-dispatcher-1.3.jar
> [ERROR] urls[11] =
> file:/Users/teofili/.m2/repository/org/sonatype/plexus/plexus-cipher/1.4/plexus-cipher-1.4.jar
> [ERROR] urls[12] =
> file:/Users/teofili/.m2/repository/org/codehaus/plexus/plexus-utils/3.0.22/plexus-utils-3.0.22.jar
> [ERROR] urls[13] =
> file:/Users/teofili/.m2/repository/commons-lang/commons-lang/2.3/commons-lang-2.3.jar
> [ERROR] urls[14] =
> file:/Users/teofili/.m2/repository/org/apache/maven/enforcer/enforcer-api/1.4.1/enforcer-api-1.4.1.jar
> [ERROR] urls[15] =
> file:/Users/teofili/.m2/repository/org/apache/maven/enforcer/enforcer-rules/1.4.1/enforcer-rules-1.4.1.jar
> [ERROR] urls[16] =
> file:/Users/teofili/.m2/repository/org/apache/maven/shared/maven-common-artifact-filters/1.4/maven-common-artifact-filters-1.4.jar
> [ERROR] urls[17] =
> file:/Users/teofili/.m2/repository/org/beanshell/bsh/2.0b4/bsh-2.0b4.jar
> [ERROR] urls[18] =
> file:/Users/teofili/.m2/repository/org/apache/maven/shared/maven-dependency-tree/2.2/maven-dependency-tree-2.2.jar
> [ERROR] urls[19] =
> file:/Users/teofili/.m2/repository/org/codehaus/plexus/plexus-component-annotations/1.5.5/plexus-component-annotations-1.5.5.jar
> [ERROR] urls[20] =
> file:/Users/teofili/.m2/repository/org/eclipse/aether/aether-util/0.9.0.M2/aether-util-0.9.0.M2.jar
> [ERROR] urls[21] =
> file:/Users/teofili/.m2/repository/org/codehaus/plexus/plexus-i18n/1.0-beta-6/plexus-i18n-1.0-beta-6.jar
> [ERROR] urls[22] =
> file:/Users/teofili/.m2/repository/org/apache/maven/plugin-testing/maven-plugin-testing-harness/1.3/maven-plugin-testing-harness-1.3.jar
> [ERROR] urls[23] =
> file:/Users/teofili/.m2/repository/org/codehaus/plexus/plexus-archiver/2.2/plexus-archiver-2.2.jar
> [ERROR]
[jira] [Created] (SLING-8793) Content Distribution Core doesn't build with java 11
Tommaso Teofili created SLING-8793:
--
Summary: Content Distribution Core doesn't build with java 11
Key: SLING-8793
URL: https://issues.apache.org/jira/browse/SLING-8793
Project: Sling
Issue Type: Bug
Components: Content Distribution
Reporter: Tommaso Teofili
When running _mvn clean install_ on _org.apache.sling.distribution.core_ I get
a build failure like the following:
{noformat}
[INFO] BUILD FAILURE
[INFO]
[INFO] Total time: 01:07 min
[INFO] Finished at: 2019-10-21T13:28:53+02:00
[INFO]
[ERROR] Failed to execute goal
org.apache.maven.plugins:maven-enforcer-plugin:1.4.1:enforce (enforce-java) on
project org.apache.sling.distribution.core: Execution enforce-java of goal
org.apache.maven.plugins:maven-enforcer-plugin:1.4.1:enforce failed: An API
incompatibility was encountered while executing
org.apache.maven.plugins:maven-enforcer-plugin:1.4.1:enforce:
java.lang.ExceptionInInitializerError: null
[ERROR] -
[ERROR] realm =plugin>org.apache.maven.plugins:maven-enforcer-plugin:1.4.1
[ERROR] strategy = org.codehaus.plexus.classworlds.strategy.SelfFirstStrategy
[ERROR] urls[0] =
file:/Users/teofili/.m2/repository/org/apache/maven/plugins/maven-enforcer-plugin/1.4.1/maven-enforcer-plugin-1.4.1.jar
[ERROR] urls[1] =
file:/Users/teofili/.m2/repository/backport-util-concurrent/backport-util-concurrent/3.1/backport-util-concurrent-3.1.jar
[ERROR] urls[2] =
file:/Users/teofili/.m2/repository/org/codehaus/plexus/plexus-interpolation/1.11/plexus-interpolation-1.11.jar
[ERROR] urls[3] =
file:/Users/teofili/.m2/repository/org/slf4j/slf4j-jdk14/1.5.6/slf4j-jdk14-1.5.6.jar
[ERROR] urls[4] =
file:/Users/teofili/.m2/repository/org/slf4j/jcl-over-slf4j/1.5.6/jcl-over-slf4j-1.5.6.jar
[ERROR] urls[5] =
file:/Users/teofili/.m2/repository/org/apache/maven/reporting/maven-reporting-api/2.2.1/maven-reporting-api-2.2.1.jar
[ERROR] urls[6] =
file:/Users/teofili/.m2/repository/org/apache/maven/doxia/doxia-sink-api/1.1/doxia-sink-api-1.1.jar
[ERROR] urls[7] =
file:/Users/teofili/.m2/repository/org/apache/maven/doxia/doxia-logging-api/1.1/doxia-logging-api-1.1.jar
[ERROR] urls[8] =
file:/Users/teofili/.m2/repository/commons-cli/commons-cli/1.2/commons-cli-1.2.jar
[ERROR] urls[9] =
file:/Users/teofili/.m2/repository/org/codehaus/plexus/plexus-interactivity-api/1.0-alpha-4/plexus-interactivity-api-1.0-alpha-4.jar
[ERROR] urls[10] =
file:/Users/teofili/.m2/repository/org/sonatype/plexus/plexus-sec-dispatcher/1.3/plexus-sec-dispatcher-1.3.jar
[ERROR] urls[11] =
file:/Users/teofili/.m2/repository/org/sonatype/plexus/plexus-cipher/1.4/plexus-cipher-1.4.jar
[ERROR] urls[12] =
file:/Users/teofili/.m2/repository/org/codehaus/plexus/plexus-utils/3.0.22/plexus-utils-3.0.22.jar
[ERROR] urls[13] =
file:/Users/teofili/.m2/repository/commons-lang/commons-lang/2.3/commons-lang-2.3.jar
[ERROR] urls[14] =
file:/Users/teofili/.m2/repository/org/apache/maven/enforcer/enforcer-api/1.4.1/enforcer-api-1.4.1.jar
[ERROR] urls[15] =
file:/Users/teofili/.m2/repository/org/apache/maven/enforcer/enforcer-rules/1.4.1/enforcer-rules-1.4.1.jar
[ERROR] urls[16] =
file:/Users/teofili/.m2/repository/org/apache/maven/shared/maven-common-artifact-filters/1.4/maven-common-artifact-filters-1.4.jar
[ERROR] urls[17] =
file:/Users/teofili/.m2/repository/org/beanshell/bsh/2.0b4/bsh-2.0b4.jar
[ERROR] urls[18] =
file:/Users/teofili/.m2/repository/org/apache/maven/shared/maven-dependency-tree/2.2/maven-dependency-tree-2.2.jar
[ERROR] urls[19] =
file:/Users/teofili/.m2/repository/org/codehaus/plexus/plexus-component-annotations/1.5.5/plexus-component-annotations-1.5.5.jar
[ERROR] urls[20] =
file:/Users/teofili/.m2/repository/org/eclipse/aether/aether-util/0.9.0.M2/aether-util-0.9.0.M2.jar
[ERROR] urls[21] =
file:/Users/teofili/.m2/repository/org/codehaus/plexus/plexus-i18n/1.0-beta-6/plexus-i18n-1.0-beta-6.jar
[ERROR] urls[22] =
file:/Users/teofili/.m2/repository/org/apache/maven/plugin-testing/maven-plugin-testing-harness/1.3/maven-plugin-testing-harness-1.3.jar
[ERROR] urls[23] =
file:/Users/teofili/.m2/repository/org/codehaus/plexus/plexus-archiver/2.2/plexus-archiver-2.2.jar
[ERROR] urls[24] =
file:/Users/teofili/.m2/repository/org/codehaus/plexus/plexus-io/2.0.4/plexus-io-2.0.4.jar
[ERROR] urls[25] =
file:/Users/teofili/.m2/repository/junit/junit/4.11/junit-4.11.jar
[ERROR] urls[26] =
file:/Users/teofili/.m2/repository/org/hamcrest/hamcrest-core/1.3/hamcrest-core-1.3.jar
[ERROR] Number of foreign imports: 1
[ERROR] import: Entry[import from realm
ClassRealm[project>org.apache.sling:org.apache.sling.distribution.core:0.4.1-SNAPSHOT,
parent: ClassRealm[maven.api, parent: null]]]
[ERROR]
[ERROR]
[jira] [Commented] (SLING-8408) DistributionQueueHealthCheck should deal with failing queries
[
https://issues.apache.org/jira/browse/SLING-8408?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16837018#comment-16837018
]
Tommaso Teofili commented on SLING-8408:
I think the suggested patch looks good, assuming an
{{IllegalArgumentException}} can only be thrown when an index is not available.
> DistributionQueueHealthCheck should deal with failing queries
> -
>
> Key: SLING-8408
> URL: https://issues.apache.org/jira/browse/SLING-8408
> Project: Sling
> Issue Type: Improvement
> Components: Content Distribution
>Reporter: Thomas Mueller
>Priority: Major
>
> The following health check indirectly runs a queries which might fail:
> *
> [DistributionQueueHealthCheck|https://github.com/apache/sling-org-apache-sling-distribution-core/blob/master/src/main/java/org/apache/sling/distribution/monitor/DistributionQueueHealthCheck.java]:
>
> sling-org-apache-sling-distribution-core/src/main/java/org/apache/sling/distribution/monitor
> The call
> [JobManagerImpl.findJobs|https://github.com/apache/sling-org-apache-sling-event/blob/master/src/main/java/org/apache/sling/event/impl/jobs/JobManagerImpl.java#L373],
> which can throw an exception with SLING-8407, if the index is not yet
> available. The health checks should catch this exception and return
> HEALTH_CHECK_ERROR for this case.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Comment Edited] (SLING-8345) IP clearance of Journal based Sling Content Distribution donation
[ https://issues.apache.org/jira/browse/SLING-8345?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16810886#comment-16810886 ] Tommaso Teofili edited comment on SLING-8345 at 4/5/19 2:27 PM: for SCD, formerly Sling Replication, IIRC a CCLA for my employer was already in place and I already had a ICLA as well, in addition to that my employer issued a SGA [1]. Hope it helps [~rombert]. [1] : http://www.apache.org/licenses/software-grant.txt was (Author: teofili): for SCD formerly Sling Replication IIRC a CCLA for my employer was already in place and I already had a ICLA as well, in addition to that my employer issued a SGA [1]. Hope it helps [~rombert]. [1] : http://www.apache.org/licenses/software-grant.txt > IP clearance of Journal based Sling Content Distribution donation > - > > Key: SLING-8345 > URL: https://issues.apache.org/jira/browse/SLING-8345 > Project: Sling > Issue Type: Sub-task >Reporter: Robert Munteanu >Assignee: Robert Munteanu >Priority: Major > > See http://incubator.apache.org/ip-clearance/ > Working page at > http://incubator.apache.org/ip-clearance/sling-distribution-journal.html -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (SLING-8345) IP clearance of Journal based Sling Content Distribution donation
[ https://issues.apache.org/jira/browse/SLING-8345?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16810886#comment-16810886 ] Tommaso Teofili commented on SLING-8345: for SCD formerly Sling Replication IIRC a CCLA for my employer was already in place and I already had a ICLA as well, in addition to that my employer issued a SGA [1]. Hope it helps [~rombert]. [1] : http://www.apache.org/licenses/software-grant.txt > IP clearance of Journal based Sling Content Distribution donation > - > > Key: SLING-8345 > URL: https://issues.apache.org/jira/browse/SLING-8345 > Project: Sling > Issue Type: Sub-task >Reporter: Robert Munteanu >Assignee: Robert Munteanu >Priority: Major > > See http://incubator.apache.org/ip-clearance/ > Working page at > http://incubator.apache.org/ip-clearance/sling-distribution-journal.html -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (SLING-6088) Distribution ITs fail on Jenkins
[
https://issues.apache.org/jira/browse/SLING-6088?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tommaso Teofili reassigned SLING-6088:
--
Assignee: (was: Tommaso Teofili)
> Distribution ITs fail on Jenkins
>
>
> Key: SLING-6088
> URL: https://issues.apache.org/jira/browse/SLING-6088
> Project: Sling
> Issue Type: Bug
> Components: Extensions
> Environment: Jenkins
>Reporter: Robert Munteanu
>Priority: Major
>
> The tests give up after 60 seconds:
> {noformat}
> 60433 [main] INFO org.apache.sling.testing.tools.sling.SlingTestBase - Server
> not ready after 60 seconds, giving up
> Tests run: 1, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 60.479 sec
> <<< FAILURE! - in
> org.apache.sling.distribution.it.DistributionPackageExporterImporterTemporaryFoldersTest
> testAddExportImportTemp(org.apache.sling.distribution.it.DistributionPackageExporterImporterTemporaryFoldersTest)
> Time elapsed: 0.006 sec <<< FAILURE!
> java.lang.AssertionError: Server not ready after 60 seconds, giving up
> at org.junit.Assert.fail(Assert.java:88)
> at
> org.apache.sling.testing.tools.sling.SlingTestBase.waitForServerReady(SlingTestBase.java:326)
> at
> org.apache.sling.testing.tools.sling.SlingTestBase.startServerIfNeeded(SlingTestBase.java:169)
> at
> org.apache.sling.testing.tools.sling.SlingTestBase.getServerBaseUrl(SlingTestBase.java:231)
> at
> org.apache.sling.distribution.it.DistributionIntegrationTestBase.init(DistributionIntegrationTestBase.java:87)
> at
> org.apache.sling.distribution.it.DistributionIntegrationTestBase.(DistributionIntegrationTestBase.java:63)
> at
> org.apache.sling.distribution.it.DistributionIntegrationTestBase.(DistributionIntegrationTestBase.java:59)
> at
> org.apache.sling.distribution.it.DistributionPackageExporterImporterTemporaryFoldersTest.(DistributionPackageExporterImporterTemporaryFoldersTest.java:36){noformat}
> The only relevant snippet that I can find in the logs is related to the
> health check bundles:
> {noformat}01.10.2016 18:09:51.724 *ERROR* [FelixDispatchQueue]
> org.apache.sling.hc.webconsole FrameworkEvent ERROR
> (org.osgi.framework.BundleException: Unable to resolve
> org.apache.sling.hc.webconsole [114](R 114.0): missing requirement
> [org.apache.sling.hc.webconsole [114](R 114.0)] osgi.wiring.package;
> (&(osgi.wiring.package=org.apache.sling.hc.api.execution)(version>=1.1.0)(!(version>=2.0.0)))
> Unresolved requirements: [[org.apache.sling.hc.webconsole [114](R 114.0)]
> osgi.wiring.package;
> (&(osgi.wiring.package=org.apache.sling.hc.api.execution)(version>=1.1.0)(!(version>=2.0.0)))])
> org.osgi.framework.BundleException: Unable to resolve
> org.apache.sling.hc.webconsole [114](R 114.0): missing requirement
> [org.apache.sling.hc.webconsole [114](R 114.0)] osgi.wiring.package;
> (&(osgi.wiring.package=org.apache.sling.hc.api.execution)(version>=1.1.0)(!(version>=2.0.0)))
> Unresolved requirements: [[org.apache.sling.hc.webconsole [114](R 114.0)]
> osgi.wiring.package;
> (&(osgi.wiring.package=org.apache.sling.hc.api.execution)(version>=1.1.0)(!(version>=2.0.0)))]
> at
> org.apache.felix.framework.Felix.resolveBundleRevision(Felix.java:4111)
> at org.apache.felix.framework.Felix.startBundle(Felix.java:2117)
> at
> org.apache.felix.framework.Felix$RefreshHelper.restart(Felix.java:5063)
> at org.apache.felix.framework.Felix.refreshPackages(Felix.java:4253)
> at
> org.apache.felix.framework.FrameworkWiringImpl.run(FrameworkWiringImpl.java:188)
> at java.lang.Thread.run(Thread.java:745){noformat}
> but I'm not sure that this leads to the test failures.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Assigned] (SLING-4075) Improve test coverage of SCD
[ https://issues.apache.org/jira/browse/SLING-4075?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tommaso Teofili reassigned SLING-4075: -- Assignee: (was: Tommaso Teofili) > Improve test coverage of SCD > > > Key: SLING-4075 > URL: https://issues.apache.org/jira/browse/SLING-4075 > Project: Sling > Issue Type: Improvement > Components: Content Distribution >Reporter: Tommaso Teofili >Priority: Major > > Currently we moved lots of testing to the IT module but it'd be good to have > a better test coverage via unit testing in core module, at least to test > basic use cases and maybe some edge cases. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (SLING-6617) Improve dev-level documentation for SCD
[ https://issues.apache.org/jira/browse/SLING-6617?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tommaso Teofili reassigned SLING-6617: -- Assignee: (was: Tommaso Teofili) > Improve dev-level documentation for SCD > --- > > Key: SLING-6617 > URL: https://issues.apache.org/jira/browse/SLING-6617 > Project: Sling > Issue Type: Task > Components: Content Distribution >Reporter: Tommaso Teofili >Priority: Major > > It'd be nice to have a good technical documentation about SCD. > While on one hand [1] should cover user level documentation, it would be > useful for developers to have a more technical one, that should be placed > near to the code [2] and expanded to reflect recent changes. > [1] : http://sling.apache.org/documentation/bundles/content-distribution.html > [2] : > https://github.com/apache/sling/blob/trunk/contrib/extensions/distribution/README.md -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (SLING-4776) Document how to create system user for loginService
[ https://issues.apache.org/jira/browse/SLING-4776?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tommaso Teofili reassigned SLING-4776: -- Assignee: (was: Tommaso Teofili) > Document how to create system user for loginService > --- > > Key: SLING-4776 > URL: https://issues.apache.org/jira/browse/SLING-4776 > Project: Sling > Issue Type: Bug > Components: Documentation >Reporter: Alex COLLIGNON >Priority: Major > > The Service Authentication documentation [0] describes the API. > We now need to describe how to create and ship the service user along with > the services. > [0] > https://sling.apache.org/documentation/the-sling-engine/service-authentication.html -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (SLING-4148) Put JCR dependent components into a distribution.jcr bundle
[ https://issues.apache.org/jira/browse/SLING-4148?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tommaso Teofili reassigned SLING-4148: -- Assignee: (was: Tommaso Teofili) > Put JCR dependent components into a distribution.jcr bundle > --- > > Key: SLING-4148 > URL: https://issues.apache.org/jira/browse/SLING-4148 > Project: Sling > Issue Type: Task > Components: Content Distribution >Reporter: Tommaso Teofili >Priority: Major > > Some components (triggers, serialization, etc.) in > _org.apache.sling.distribution.core_ are JCR dependent, meaning that they > will only work if Sling is backed by JCR, so they should be put in a separate > _org.apache.sling.distribution.jcr_ bundle. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (SLING-6211) Clarify AbstractJcrEventTrigger request addition strategy
[ https://issues.apache.org/jira/browse/SLING-6211?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tommaso Teofili reassigned SLING-6211: -- Assignee: (was: Tommaso Teofili) > Clarify AbstractJcrEventTrigger request addition strategy > - > > Key: SLING-6211 > URL: https://issues.apache.org/jira/browse/SLING-6211 > Project: Sling > Issue Type: Task > Components: Content Distribution >Reporter: Tommaso Teofili >Priority: Major > > We should clarify the logic behind > [AbstractJcrEventListener#addToList|https://github.com/apache/sling/blob/trunk/contrib/extensions/distribution/core/src/main/java/org/apache/sling/distribution/trigger/impl/AbstractJcrEventTrigger.java#L150] > as that the addition mechanism seems to rely on the last request added, > which seems wrong as events may come in in an unsorted manner (not consistent > with the order the changes they refer to were done). -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (SLING-5916) Remove all usages of jobManager.findJobs in SCD
[
https://issues.apache.org/jira/browse/SLING-5916?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tommaso Teofili reassigned SLING-5916:
--
Assignee: (was: Tommaso Teofili)
> Remove all usages of jobManager.findJobs in SCD
> ---
>
> Key: SLING-5916
> URL: https://issues.apache.org/jira/browse/SLING-5916
> Project: Sling
> Issue Type: Bug
> Components: Content Distribution
>Reporter: Tommaso Teofili
>Priority: Major
>
> Given the latest discussions on the Sling dev@ list it'd be good to stop
> using {{JobManager#findJobs}} API at all in the SCD code (for the jobs based
> queues).
> This would require either accepting queues cannot be inspected in detail
> (which / how many items there are in each queue) or rely on different
> constructs.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (SLING-7468) Allow to configure the Distribution Resource Provider
[ https://issues.apache.org/jira/browse/SLING-7468?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16351293#comment-16351293 ] Tommaso Teofili commented on SLING-7468: big +1 on my side as well, and btw I would opt for configuration-less (figure out mappings at runtime). > 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 > > 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-7168) Allow to implement custom distribution agents/queues
[
https://issues.apache.org/jira/browse/SLING-7168?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16350573#comment-16350573
]
Tommaso Teofili commented on SLING-7168:
+1 sounds good to me.
> Allow to implement custom distribution agents/queues
>
>
> Key: SLING-7168
> URL: https://issues.apache.org/jira/browse/SLING-7168
> Project: Sling
> Issue Type: Improvement
> Components: Content Distribution
>Affects Versions: Content Distribution Core 0.2.8
>Reporter: Timothee Maret
>Assignee: Timothee Maret
>Priority: Major
> Fix For: Content Distribution Core 0.2.12, Content Distribution
> API 0.4.0
>
>
> Currently, it is not possible to implements distribution agents and queues,
> implemented in another bundle than the {{org.apache.sling.distribution.core}}
> bundle.
> Implementing a custom distribution agent outside of the
> {{org.apache.sling.distribution.core}} bundle is useful when leveraging an
> ad-hoc communication layer.
> This issue is about allowing to plug an external distribution agent/queue
> provided via a separate bundle.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Resolved] (SLING-7360) Support creation of DistributionPackages for delete by DistributionContentSerializer
[
https://issues.apache.org/jira/browse/SLING-7360?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tommaso Teofili resolved SLING-7360.
Resolution: Fixed
Assignee: Dirk Rudolph
> 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.2.12
>
>
> 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
(v6.4.14#64029)
[jira] [Updated] (SLING-7360) Support creation of DistributionPackages for delete by DistributionContentSerializer
[
https://issues.apache.org/jira/browse/SLING-7360?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tommaso Teofili updated SLING-7360:
---
Fix Version/s: Content Distribution Core 0.2.12
> 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
>Priority: Minor
> Fix For: Content Distribution Core 0.2.12
>
>
> 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
(v6.4.14#64029)
[jira] [Resolved] (SLING-7359) DistributionEventDistributeDistributionTrigger causes distribution loop
[ https://issues.apache.org/jira/browse/SLING-7359?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tommaso Teofili resolved SLING-7359. Resolution: Fixed Assignee: Dirk Rudolph > DistributionEventDistributeDistributionTrigger causes distribution loop > --- > > Key: SLING-7359 > URL: https://issues.apache.org/jira/browse/SLING-7359 > Project: Sling > Issue Type: Bug > Components: Content Distribution >Affects Versions: Content Distribution Core 0.2.10 >Reporter: Dirk Rudolph >Assignee: Dirk Rudolph > Fix For: Content Distribution Core 0.2.12 > > > The DistributionEventDistributeDistributionTrigger [is listening for > org/apache/sling/distribution/agent/package/distributed > events|https://github.com/apache/sling-org-apache-sling-distribution-core/blob/master/src/main/java/org/apache/sling/distribution/trigger/impl/DistributionEventDistributeDistributionTrigger.java#L67]. > > Assuming we have > - an agent configured for the allowed root path /foo with > DistributionEventDistributeDistributionTrigger "trigger-on-foo-distrib" and > - a DistributionEventDistributeDistributionTrigger "trigger-on-foo-distrib" > for /foo as well, > the agent's successful delivery will trigger another distribution on the same > agent. > To circumvent that the DistributionEventDistributeDistributionTrigger should > check the DistributionRequestHandler against the component that fired the > event it handles and should stop propagation when the event's origin is the > same request handler. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (SLING-7358) FileDistributionPackageBuilder fails with no temp directory configured
[
https://issues.apache.org/jira/browse/SLING-7358?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tommaso Teofili updated SLING-7358:
---
Fix Version/s: Content Distribution Core 0.2.12
> FileDistributionPackageBuilder fails with no temp directory configured
> --
>
> Key: SLING-7358
> URL: https://issues.apache.org/jira/browse/SLING-7358
> Project: Sling
> Issue Type: Bug
> Components: Content Distribution
>Affects Versions: Content Distribution Core 0.2.10
>Reporter: Dirk Rudolph
>Assignee: Dirk Rudolph
>Priority: Minor
> Fix For: Content Distribution Core 0.2.12
>
>
> When no temp directory is configured the
> [FileDistributionPackageBuilder|https://github.com/apache/sling-org-apache-sling-distribution-core/blob/master/src/main/java/org/apache/sling/distribution/packaging/impl/FileDistributionPackageBuilder.java#L86]
> uses null to create a new temp file which, according to the java docs will
> use the default temp directory.
> On the other hand [reading the file
> internally|https://github.com/apache/sling-org-apache-sling-distribution-core/blob/master/src/main/java/org/apache/sling/distribution/packaging/impl/FileDistributionPackageBuilder.java#L160]
> uses the {{File}} constructor passing {{null}} as directory to it. This
> causes a non-existing file to be returned.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Resolved] (SLING-7357) Send Content-Type header along with the DistributionPackage's content in forward distribution
[ https://issues.apache.org/jira/browse/SLING-7357?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tommaso Teofili resolved SLING-7357. Resolution: Fixed > 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.2.12 > > > 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 (v6.4.14#64029)
[jira] [Assigned] (SLING-7357) Send Content-Type header along with the DistributionPackage's content in forward distribution
[ https://issues.apache.org/jira/browse/SLING-7357?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tommaso Teofili reassigned SLING-7357: -- Assignee: Dirk Rudolph > 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.2.12 > > > 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 (v6.4.14#64029)
[jira] [Assigned] (SLING-7358) FileDistributionPackageBuilder fails with no temp directory configured
[
https://issues.apache.org/jira/browse/SLING-7358?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tommaso Teofili reassigned SLING-7358:
--
Assignee: Dirk Rudolph
> FileDistributionPackageBuilder fails with no temp directory configured
> --
>
> Key: SLING-7358
> URL: https://issues.apache.org/jira/browse/SLING-7358
> Project: Sling
> Issue Type: Bug
> Components: Content Distribution
>Affects Versions: Content Distribution Core 0.2.10
>Reporter: Dirk Rudolph
>Assignee: Dirk Rudolph
>Priority: Minor
> Fix For: Content Distribution Core 0.2.12
>
>
> When no temp directory is configured the
> [FileDistributionPackageBuilder|https://github.com/apache/sling-org-apache-sling-distribution-core/blob/master/src/main/java/org/apache/sling/distribution/packaging/impl/FileDistributionPackageBuilder.java#L86]
> uses null to create a new temp file which, according to the java docs will
> use the default temp directory.
> On the other hand [reading the file
> internally|https://github.com/apache/sling-org-apache-sling-distribution-core/blob/master/src/main/java/org/apache/sling/distribution/packaging/impl/FileDistributionPackageBuilder.java#L160]
> uses the {{File}} constructor passing {{null}} as directory to it. This
> causes a non-existing file to be returned.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Resolved] (SLING-7358) FileDistributionPackageBuilder fails with no temp directory configured
[
https://issues.apache.org/jira/browse/SLING-7358?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tommaso Teofili resolved SLING-7358.
Resolution: Fixed
> FileDistributionPackageBuilder fails with no temp directory configured
> --
>
> Key: SLING-7358
> URL: https://issues.apache.org/jira/browse/SLING-7358
> Project: Sling
> Issue Type: Bug
> Components: Content Distribution
>Affects Versions: Content Distribution Core 0.2.10
>Reporter: Dirk Rudolph
>Assignee: Dirk Rudolph
>Priority: Minor
> Fix For: Content Distribution Core 0.2.12
>
>
> When no temp directory is configured the
> [FileDistributionPackageBuilder|https://github.com/apache/sling-org-apache-sling-distribution-core/blob/master/src/main/java/org/apache/sling/distribution/packaging/impl/FileDistributionPackageBuilder.java#L86]
> uses null to create a new temp file which, according to the java docs will
> use the default temp directory.
> On the other hand [reading the file
> internally|https://github.com/apache/sling-org-apache-sling-distribution-core/blob/master/src/main/java/org/apache/sling/distribution/packaging/impl/FileDistributionPackageBuilder.java#L160]
> uses the {{File}} constructor passing {{null}} as directory to it. This
> causes a non-existing file to be returned.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (SLING-7359) DistributionEventDistributeDistributionTrigger causes distribution loop
[ https://issues.apache.org/jira/browse/SLING-7359?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tommaso Teofili updated SLING-7359: --- Fix Version/s: Content Distribution Core 0.2.12 > DistributionEventDistributeDistributionTrigger causes distribution loop > --- > > Key: SLING-7359 > URL: https://issues.apache.org/jira/browse/SLING-7359 > Project: Sling > Issue Type: Bug > Components: Content Distribution >Affects Versions: Content Distribution Core 0.2.10 >Reporter: Dirk Rudolph > Fix For: Content Distribution Core 0.2.12 > > > The DistributionEventDistributeDistributionTrigger [is listening for > org/apache/sling/distribution/agent/package/distributed > events|https://github.com/apache/sling-org-apache-sling-distribution-core/blob/master/src/main/java/org/apache/sling/distribution/trigger/impl/DistributionEventDistributeDistributionTrigger.java#L67]. > > Assuming we have > - an agent configured for the allowed root path /foo with > DistributionEventDistributeDistributionTrigger "trigger-on-foo-distrib" and > - a DistributionEventDistributeDistributionTrigger "trigger-on-foo-distrib" > for /foo as well, > the agent's successful delivery will trigger another distribution on the same > agent. > To circumvent that the DistributionEventDistributeDistributionTrigger should > check the DistributionRequestHandler against the component that fired the > event it handles and should stop propagation when the event's origin is the > same request handler. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (SLING-7357) Send Content-Type header along with the DistributionPackage's content in forward distribution
[ https://issues.apache.org/jira/browse/SLING-7357?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tommaso Teofili updated SLING-7357: --- Fix Version/s: Content Distribution Core 0.2.12 > 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 >Priority: Minor > Fix For: Content Distribution Core 0.2.12 > > > 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 (v6.4.14#64029)
[jira] [Commented] (SLING-7142) Allow to pull a set of packages per request
[ https://issues.apache.org/jira/browse/SLING-7142?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16187840#comment-16187840 ] Tommaso Teofili commented on SLING-7142: thanks [~marett], it sounds like a possibly nice improvement, but I agree on the code complexity. Maybe we should look at streaming packages in a single requests or directly create "multi packages" (bigger payload). > Allow to pull a set of packages per request > --- > > Key: SLING-7142 > URL: https://issues.apache.org/jira/browse/SLING-7142 > Project: Sling > Issue Type: Bug > Components: Content Distribution >Affects Versions: Content Distribution Core 0.2.8 >Reporter: Timothee Maret > > Currently, the sync/reverse agent pull one package per request. > This protocol is really simple and it is already possible to decrease the > polling interval (via the trigger) to increase the sync throughput. > However, establishing a request has a cost which is applied to every packages. > In order to improve the throughput when processing the queue, we could avoid > establishing most of the request, by allowing to pull more than one package > per request. > In order to allow for some flow control, we could let the receiving side > define how many packages could be fetched (similarly to how TCP works). > Allowing to pull more than more package per request adds more complexity to > the code, so we may first build a PoC to demonstrate if the improved > throughput is worth the added complexity. > cc [~teofili], [~simone.tripodi] -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (SLING-7017) Make it possible to mount packages at different paths
[ https://issues.apache.org/jira/browse/SLING-7017?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16096163#comment-16096163 ] Tommaso Teofili commented on SLING-7017: thanks [~simone.tripodi] the patch looks good to me! thanks :) > Make it possible to mount packages at different paths > - > > Key: SLING-7017 > URL: https://issues.apache.org/jira/browse/SLING-7017 > Project: Sling > Issue Type: Improvement > Components: Content Distribution >Reporter: Tommaso Teofili >Assignee: Simone Tripodi > Fix For: Content Distribution Core 0.2.10 > > Attachments: SLING-7017.1.patch, SLING-7017.2.patch, > SLING-7017.3.patch > > > In some scenarios (e.g. multi tenant instances) it may be useful to be able > to mount packages at configurable paths. > For example mounting a package for _/foo/bar/_ at _/tenant1/foo/bar_; we can > leverage FileVault [configuration > options|https://github.com/apache/jackrabbit-filevault/blob/trunk/vault-core/src/main/java/org/apache/jackrabbit/vault/packaging/ExportOptions.java#L126] > to support that. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (SLING-7017) Make it possible to mount packages at different paths
Tommaso Teofili created SLING-7017: -- Summary: Make it possible to mount packages at different paths Key: SLING-7017 URL: https://issues.apache.org/jira/browse/SLING-7017 Project: Sling Issue Type: Improvement Components: Content Distribution Reporter: Tommaso Teofili Fix For: Content Distribution Core 0.2.10 In some scenarios (e.g. multi tenant instances) it may be useful to be able to mount packages at configurable paths. For example mounting a package for _/foo/bar/_ at _/tenant1/foo/bar_; we can leverage FileVault [configuration options|https://github.com/apache/jackrabbit-filevault/blob/trunk/vault-core/src/main/java/org/apache/jackrabbit/vault/packaging/ExportOptions.java#L126] to support that. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Resolved] (SLING-6654) Test distribution has a wrong header
[
https://issues.apache.org/jira/browse/SLING-6654?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tommaso Teofili resolved SLING-6654.
Resolution: Fixed
> Test distribution has a wrong header
>
>
> Key: SLING-6654
> URL: https://issues.apache.org/jira/browse/SLING-6654
> Project: Sling
> Issue Type: Bug
> Components: Content Distribution
>Affects Versions: Content Distribution Core 0.2.6
>Reporter: Tommaso Teofili
>Assignee: Tommaso Teofili
> Fix For: Content Distribution Core 0.2.10
>
>
> {{SimpleDistributionPackage}} doesn't set the paths if they are empty and,
> most importantly, its delimiter, therefore {{ResourcePackageBuilder}} may
> fail at persisting it because of the resulting wrong header in the package.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Resolved] (SLING-6977) Improve SCD compilation by suppressing warnings
[ https://issues.apache.org/jira/browse/SLING-6977?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tommaso Teofili resolved SLING-6977. Resolution: Fixed Fix Version/s: Content Distribution Core 0.2.10 > Improve SCD compilation by suppressing warnings > --- > > Key: SLING-6977 > URL: https://issues.apache.org/jira/browse/SLING-6977 > Project: Sling > Issue Type: Improvement > Components: Content Distribution >Reporter: Simone Tripodi >Assignee: Tommaso Teofili > Fix For: Content Distribution Core 0.2.10 > > Attachments: SLING-6977.patch > > > After some cleanups, there are still compilation issues due to the fact we > want to be compliant to OSGi APIs that don't support generics, the incoming > patch will supply them in order to drastically reduce warnings in the IDEs > and on the compiler output. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (SLING-6977) Improve SCD compilation by suppressing warnings
[ https://issues.apache.org/jira/browse/SLING-6977?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16070011#comment-16070011 ] Tommaso Teofili commented on SLING-6977: thanks Simo for your patch, I've applied it in r1800389. > Improve SCD compilation by suppressing warnings > --- > > Key: SLING-6977 > URL: https://issues.apache.org/jira/browse/SLING-6977 > Project: Sling > Issue Type: Improvement > Components: Content Distribution >Reporter: Simone Tripodi >Assignee: Tommaso Teofili > Fix For: Content Distribution Core 0.2.10 > > Attachments: SLING-6977.patch > > > After some cleanups, there are still compilation issues due to the fact we > want to be compliant to OSGi APIs that don't support generics, the incoming > patch will supply them in order to drastically reduce warnings in the IDEs > and on the compiler output. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Resolved] (SLING-6988) Async delivery should create an unordererd delivery queue
[
https://issues.apache.org/jira/browse/SLING-6988?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tommaso Teofili resolved SLING-6988.
Resolution: Fixed
fixed in r1800364.
> Async delivery should create an unordererd delivery queue
> -
>
> Key: SLING-6988
> URL: https://issues.apache.org/jira/browse/SLING-6988
> Project: Sling
> Issue Type: Bug
> Components: Content Distribution
>Reporter: Tommaso Teofili
>Assignee: Tommaso Teofili
> Fix For: Content Distribution Core 0.2.10
>
>
> Currently {{AsyncDeliveryDispatchingStrategy}} does not create a parallel
> queue for delivery if it doesn't exist, therefore the deriving improvements
> in throughput are less impacting than expected.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Created] (SLING-6988) Async delivery should create an unordererd delivery queue
Tommaso Teofili created SLING-6988:
--
Summary: Async delivery should create an unordererd delivery queue
Key: SLING-6988
URL: https://issues.apache.org/jira/browse/SLING-6988
Project: Sling
Issue Type: Bug
Components: Content Distribution
Reporter: Tommaso Teofili
Assignee: Tommaso Teofili
Fix For: Content Distribution Core 0.2.10
Currently {{AsyncDeliveryDispatchingStrategy}} does not create a parallel queue
for delivery if it doesn't exist, therefore the deriving improvements in
throughput are less impacting than expected.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (SLING-6977) Improve SCD compilation by suppressing warnings
[ https://issues.apache.org/jira/browse/SLING-6977?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16059303#comment-16059303 ] Tommaso Teofili commented on SLING-6977: thanks a lot Simo for your restless work on making our code cleaner and nicer! > Improve SCD compilation by suppressing warnings > --- > > Key: SLING-6977 > URL: https://issues.apache.org/jira/browse/SLING-6977 > Project: Sling > Issue Type: Improvement > Components: Content Distribution >Reporter: Simone Tripodi >Assignee: Tommaso Teofili > Attachments: SLING-6977.patch > > > After some cleanups, there are still compilation issues due to the fact we > want to be compliant to OSGi APIs that don't support generics, the incoming > patch will supply them in order to drastically reduce warnings in the IDEs > and on the compiler output. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (SLING-6942) DistributionUtils#getResourceResolver should use the user session
[ https://issues.apache.org/jira/browse/SLING-6942?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16042394#comment-16042394 ] Tommaso Teofili commented on SLING-6942: +1 thanks Tim! > DistributionUtils#getResourceResolver should use the user session > - > > Key: SLING-6942 > URL: https://issues.apache.org/jira/browse/SLING-6942 > Project: Sling > Issue Type: Bug > Components: Content Distribution >Affects Versions: Content Distribution Core 0.1.12 >Reporter: Timothee Maret > Attachments: SLING-6942.patch > > > According to SLING-5281, the resource resolver should use the user session > when no subservice user is configured. Currently, this is not the case. See > also SLING-6939. > cc [~teofili] -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Resolved] (SLING-6848) Package level monitoring should be only enabled consciously
[
https://issues.apache.org/jira/browse/SLING-6848?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tommaso Teofili resolved SLING-6848.
Resolution: Fixed
Assignee: Tommaso Teofili
fixed in r1794817.
> Package level monitoring should be only enabled consciously
> ---
>
> Key: SLING-6848
> URL: https://issues.apache.org/jira/browse/SLING-6848
> Project: Sling
> Issue Type: Improvement
> Components: Content Distribution
>Reporter: Tommaso Teofili
>Assignee: Tommaso Teofili
> Fix For: Content Distribution Core 0.2.8
>
> Attachments: SLING-6848.0.patch
>
>
> I have noticed that by default all {{DistributionPackages}} get an MBean
> registered by {{MonitoringDistributionPackageBuilder}}.
> While that's fine for monitoring purposes, I think that slows down a
> distribution request a bit, therefore I was wondering if it wouldn't be
> better to set the default _monitored package size_ to 0 (currently it's 100)
> and do MBean registration only if that value is higher than 0.
> [~simone.tripodi] what do you think ?
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Updated] (SLING-6848) Package level monitoring should be only enabled consciously
[
https://issues.apache.org/jira/browse/SLING-6848?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tommaso Teofili updated SLING-6848:
---
Attachment: SLING-6848.0.patch
attaching draft patch.
> Package level monitoring should be only enabled consciously
> ---
>
> Key: SLING-6848
> URL: https://issues.apache.org/jira/browse/SLING-6848
> Project: Sling
> Issue Type: Improvement
> Components: Content Distribution
>Reporter: Tommaso Teofili
> Fix For: Content Distribution Core 0.2.8
>
> Attachments: SLING-6848.0.patch
>
>
> I have noticed that by default all {{DistributionPackages}} get an MBean
> registered by {{MonitoringDistributionPackageBuilder}}.
> While that's fine for monitoring purposes, I think that slows down a
> distribution request a bit, therefore I was wondering if it wouldn't be
> better to set the default _monitored package size_ to 0 (currently it's 100)
> and do MBean registration only if that value is higher than 0.
> [~simone.tripodi] what do you think ?
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Created] (SLING-6848) Package level monitoring should be only enabled consciously
Tommaso Teofili created SLING-6848:
--
Summary: Package level monitoring should be only enabled
consciously
Key: SLING-6848
URL: https://issues.apache.org/jira/browse/SLING-6848
Project: Sling
Issue Type: Improvement
Components: Content Distribution
Reporter: Tommaso Teofili
Fix For: Content Distribution Core 0.2.8
I have noticed that by default all {{DistributionPackages}} get an MBean
registered by {{MonitoringDistributionPackageBuilder}}.
While that's fine for monitoring purposes, I think that slows down a
distribution request a bit, therefore I was wondering if it wouldn't be better
to set the default _monitored package size_ to 0 (currently it's 100) and do
MBean registration only if that value is higher than 0.
[~simone.tripodi] what do you think ?
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Resolved] (SLING-6838) Do not use persistence connections in SCD HTTP
[ https://issues.apache.org/jira/browse/SLING-6838?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tommaso Teofili resolved SLING-6838. Resolution: Fixed fixed in r1794300 > Do not use persistence connections in SCD HTTP > -- > > Key: SLING-6838 > URL: https://issues.apache.org/jira/browse/SLING-6838 > Project: Sling > Issue Type: Improvement > Components: Content Distribution >Reporter: Tommaso Teofili >Assignee: Tommaso Teofili > Fix For: Content Distribution Core 0.2.8 > > > In order to avoid connections to stale it'd be better to let explicitly avoid > persistent connections (aka keep-alive) in HTTP requests. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Created] (SLING-6838) Do not use persistence connections in SCD HTTP
Tommaso Teofili created SLING-6838: -- Summary: Do not use persistence connections in SCD HTTP Key: SLING-6838 URL: https://issues.apache.org/jira/browse/SLING-6838 Project: Sling Issue Type: Improvement Components: Content Distribution Reporter: Tommaso Teofili Assignee: Tommaso Teofili Fix For: Content Distribution Core 0.2.8 In order to avoid connections to stale it'd be better to let explicitly avoid persistent connections (aka keep-alive) in HTTP requests. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Resolved] (SLING-5952) Add support for configurable SO and connection timeouts
[ https://issues.apache.org/jira/browse/SLING-5952?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tommaso Teofili resolved SLING-5952. Resolution: Fixed > Add support for configurable SO and connection timeouts > --- > > Key: SLING-5952 > URL: https://issues.apache.org/jira/browse/SLING-5952 > Project: Sling > Issue Type: Improvement > Components: Content Distribution >Affects Versions: Content Distribution Core 0.1.18 >Reporter: Timothee Maret >Assignee: Tommaso Teofili > Fix For: Content Distribution Core 0.2.8 > > Attachments: SLING-SLING-5952.0.patch > > > Currently the SDC transport is using the default HTTP client timeouts > 1. Connection Timeout (by default it is infinite) > 2. SO Socket Timeout (by default it is infinite) > Allowing to configure a bounded timeouts is needed in most deployments in > order to avoid leaving a resource stuck. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (SLING-5952) Add support for configurable SO and connection timeouts
[ https://issues.apache.org/jira/browse/SLING-5952?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15996764#comment-15996764 ] Tommaso Teofili commented on SLING-5952: I've fixed this in r1793803. > Add support for configurable SO and connection timeouts > --- > > Key: SLING-5952 > URL: https://issues.apache.org/jira/browse/SLING-5952 > Project: Sling > Issue Type: Improvement > Components: Content Distribution >Affects Versions: Content Distribution Core 0.1.18 >Reporter: Timothee Maret >Assignee: Tommaso Teofili > Fix For: Content Distribution Core 0.2.8 > > Attachments: SLING-SLING-5952.0.patch > > > Currently the SDC transport is using the default HTTP client timeouts > 1. Connection Timeout (by default it is infinite) > 2. SO Socket Timeout (by default it is infinite) > Allowing to configure a bounded timeouts is needed in most deployments in > order to avoid leaving a resource stuck. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (SLING-5952) Add support for configurable SO and connection timeouts
[ https://issues.apache.org/jira/browse/SLING-5952?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tommaso Teofili updated SLING-5952: --- Attachment: SLING-SLING-5952.0.patch attaching trivial patch with fixed socket / connect timeout of 10s. > Add support for configurable SO and connection timeouts > --- > > Key: SLING-5952 > URL: https://issues.apache.org/jira/browse/SLING-5952 > Project: Sling > Issue Type: Improvement > Components: Content Distribution >Affects Versions: Content Distribution Core 0.1.18 >Reporter: Timothee Maret >Assignee: Timothee Maret > Fix For: Content Distribution Core 0.2.8 > > Attachments: SLING-SLING-5952.0.patch > > > Currently the SDC transport is using the default HTTP client timeouts > 1. Connection Timeout (by default it is infinite) > 2. SO Socket Timeout (by default it is infinite) > Allowing to configure a bounded timeouts is needed in most deployments in > order to avoid leaving a resource stuck. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Created] (SLING-6654) Test distribution has a wrong header
Tommaso Teofili created SLING-6654:
--
Summary: Test distribution has a wrong header
Key: SLING-6654
URL: https://issues.apache.org/jira/browse/SLING-6654
Project: Sling
Issue Type: Bug
Components: Content Distribution
Affects Versions: Content Distribution Core 0.2.6
Reporter: Tommaso Teofili
Assignee: Tommaso Teofili
Fix For: Content Distribution Core 0.2.8
{{SimpleDistributionPackage}} doesn't set the paths if they are empty and, most
importantly, its delimiter, therefore {{ResourcePackageBuilder}} may fail at
persisting it because of the resulting wrong header in the package.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Created] (SLING-6617) Improve dev-level documentation for SCD
Tommaso Teofili created SLING-6617: -- Summary: Improve dev-level documentation for SCD Key: SLING-6617 URL: https://issues.apache.org/jira/browse/SLING-6617 Project: Sling Issue Type: Task Components: Content Distribution Reporter: Tommaso Teofili Assignee: Tommaso Teofili It'd be nice to have a good technical documentation about SCD. While on one hand [1] should cover user level documentation, it would be useful for developers to have a more technical one, that should be placed near to the code [2] and expanded to reflect recent changes. [1] : http://sling.apache.org/documentation/bundles/content-distribution.html [2] : https://github.com/apache/sling/blob/trunk/contrib/extensions/distribution/README.md -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Resolved] (SLING-4540) Update sling distribution documentation to reflect latest changes
[ https://issues.apache.org/jira/browse/SLING-4540?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tommaso Teofili resolved SLING-4540. Resolution: Fixed > Update sling distribution documentation to reflect latest changes > - > > Key: SLING-4540 > URL: https://issues.apache.org/jira/browse/SLING-4540 > Project: Sling > Issue Type: Bug > Components: Content Distribution >Reporter: Marius Petria >Priority: Minor > -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Resolved] (SLING-6325) Split Avro and Kryo serializers into their own bundles
[
https://issues.apache.org/jira/browse/SLING-6325?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tommaso Teofili resolved SLING-6325.
Resolution: Fixed
Fix Version/s: Content Distribution Extensions 0.1.0
> Split Avro and Kryo serializers into their own bundles
> --
>
> Key: SLING-6325
> URL: https://issues.apache.org/jira/browse/SLING-6325
> Project: Sling
> Issue Type: Task
> Components: Content Distribution
>Reporter: Tommaso Teofili
>Assignee: Tommaso Teofili
> Fix For: Content Distribution Extensions 0.1.0
>
>
> A while ago we created the _sling.distribution.extensions_ bundle to host
> some PoCs for SCD extension points.
> Now that the {{DistributionContentSerializer}} API is exposed it'd be
> probably better to create two separate bundles for Kryo and Avro serializers
> as it's more likely that people will only use one of those serializers only,
> also for decoupling and separation of dependencies concerns.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Created] (SLING-6611) Improve FileVaultContentSerializer performance
Tommaso Teofili created SLING-6611: -- Summary: Improve FileVaultContentSerializer performance Key: SLING-6611 URL: https://issues.apache.org/jira/browse/SLING-6611 Project: Sling Issue Type: Improvement Components: Content Distribution Reporter: Tommaso Teofili Fix For: Content Distribution Core 0.2.8 It would be good if we could improve FileVault serializer performance by avoiding writing several (temp) files on FS and avoid compressing binaries that are already compressed (e.g. images like jpg, png, etc.). -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (SLING-6566) ResourceDistributionPackageBuilder package files are never collected
[ https://issues.apache.org/jira/browse/SLING-6566?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15882959#comment-15882959 ] Tommaso Teofili commented on SLING-6566: they should be definitely removed, if that's not the case it's a bug. > ResourceDistributionPackageBuilder package files are never collected > > > Key: SLING-6566 > URL: https://issues.apache.org/jira/browse/SLING-6566 > Project: Sling > Issue Type: Bug > Components: Content Distribution >Affects Versions: Content Distribution Core 0.2.4 >Reporter: Timothee Maret >Assignee: Timothee Maret > Fix For: Content Distribution Core 0.2.6 > > > While testing SCD with Sling running the tempdir on a ramdisk, I noticed the > temporary files created to contain the content package at > https://github.com/apache/sling/blob/trunk/contrib/extensions/distribution/core/src/main/java/org/apache/sling/distribution/packaging/impl/FileDistributionPackageBuilder.java#L86 > are never removed, even when the distribution succeeds. > [~teofili] is this a known issue or expected behaviour ? I would expect those > files should be removed when no longer used. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Resolved] (SLING-6564) Failures in queue processing do not appear in the SLF4J logging
[
https://issues.apache.org/jira/browse/SLING-6564?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tommaso Teofili resolved SLING-6564.
Resolution: Fixed
fixed in r1784266.
> Failures in queue processing do not appear in the SLF4J logging
> ---
>
> Key: SLING-6564
> URL: https://issues.apache.org/jira/browse/SLING-6564
> Project: Sling
> Issue Type: Bug
> Components: Content Distribution
>Affects Versions: Content Distribution Core 0.2.4
>Reporter: Tommaso Teofili
>Assignee: Tommaso Teofili
> Fix For: Content Distribution Core 0.2.6
>
>
> {{SimpleDistributionAgentQueueProcessor}} only logs on {{DistributionLog}}
> whereas it should also log on a plain {{Logger}} because admins often look at
> the latter first.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Created] (SLING-6564) Failures in queue processing do not appear in the SLF4J logging
Tommaso Teofili created SLING-6564:
--
Summary: Failures in queue processing do not appear in the SLF4J
logging
Key: SLING-6564
URL: https://issues.apache.org/jira/browse/SLING-6564
Project: Sling
Issue Type: Bug
Components: Content Distribution
Affects Versions: Content Distribution Core 0.2.4
Reporter: Tommaso Teofili
Assignee: Tommaso Teofili
Fix For: Content Distribution Core 0.2.6
{{SimpleDistributionAgentQueueProcessor}} only logs on {{DistributionLog}}
whereas it should also log on a plain {{Logger}} because admins often look at
the latter first.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (SLING-6325) Split Avro and Kryo serializers into their own bundles
[
https://issues.apache.org/jira/browse/SLING-6325?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15880648#comment-15880648
]
Tommaso Teofili commented on SLING-6325:
split done in r1784154.
> Split Avro and Kryo serializers into their own bundles
> --
>
> Key: SLING-6325
> URL: https://issues.apache.org/jira/browse/SLING-6325
> Project: Sling
> Issue Type: Task
> Components: Content Distribution
>Reporter: Tommaso Teofili
>Assignee: Tommaso Teofili
>
> A while ago we created the _sling.distribution.extensions_ bundle to host
> some PoCs for SCD extension points.
> Now that the {{DistributionContentSerializer}} API is exposed it'd be
> probably better to create two separate bundles for Kryo and Avro serializers
> as it's more likely that people will only use one of those serializers only,
> also for decoupling and separation of dependencies concerns.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Resolved] (SLING-6554) Cache resource package size
[
https://issues.apache.org/jira/browse/SLING-6554?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tommaso Teofili resolved SLING-6554.
Resolution: Fixed
fixed in r1784108.
> Cache resource package size
> ---
>
> Key: SLING-6554
> URL: https://issues.apache.org/jira/browse/SLING-6554
> Project: Sling
> Issue Type: Improvement
> Components: Content Distribution
>Reporter: Tommaso Teofili
>Assignee: Tommaso Teofili
>Priority: Minor
> Fix For: Content Distribution Core 0.2.6
>
>
> {{ResourceDistributionPackage}} size should be calculated exactly once at
> instance creation time, that would reduce the amount of reads on the
> repository.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Created] (SLING-6554) Cache resource package size
Tommaso Teofili created SLING-6554:
--
Summary: Cache resource package size
Key: SLING-6554
URL: https://issues.apache.org/jira/browse/SLING-6554
Project: Sling
Issue Type: Improvement
Components: Content Distribution
Reporter: Tommaso Teofili
Assignee: Tommaso Teofili
Priority: Minor
Fix For: Content Distribution Core 0.2.6
{{ResourceDistributionPackage}} size should be calculated exactly once at
instance creation time, that would reduce the amount of reads on the repository.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Resolved] (SLING-6523) Priority queues are wrongly set as passive
[ https://issues.apache.org/jira/browse/SLING-6523?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tommaso Teofili resolved SLING-6523. Resolution: Fixed fixed in r1783186. > Priority queues are wrongly set as passive > -- > > Key: SLING-6523 > URL: https://issues.apache.org/jira/browse/SLING-6523 > Project: Sling > Issue Type: Bug > Components: Content Distribution >Affects Versions: Content Distribution Core 0.2.0 >Reporter: Tommaso Teofili >Assignee: Tommaso Teofili > Fix For: Content Distribution Core 0.2.2 > > > When configuring priority queues, they are wrongly set as _passive_ therefore > items in there are not processed. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (SLING-6523) Priority queues are wrongly set as passive
[ https://issues.apache.org/jira/browse/SLING-6523?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tommaso Teofili updated SLING-6523: --- Description: When configuring priority queues, they are wrongly set as _passive_ therefore items in there are not processed. (was: When configuring priority queues, they are wrongly set as _passive_.) > Priority queues are wrongly set as passive > -- > > Key: SLING-6523 > URL: https://issues.apache.org/jira/browse/SLING-6523 > Project: Sling > Issue Type: Bug > Components: Content Distribution >Affects Versions: Content Distribution Core 0.2.0 >Reporter: Tommaso Teofili >Assignee: Tommaso Teofili > Fix For: Content Distribution Core 0.2.2 > > > When configuring priority queues, they are wrongly set as _passive_ therefore > items in there are not processed. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Created] (SLING-6523) Priority queues are wrongly set as passive
Tommaso Teofili created SLING-6523: -- Summary: Priority queues are wrongly set as passive Key: SLING-6523 URL: https://issues.apache.org/jira/browse/SLING-6523 Project: Sling Issue Type: Bug Components: Content Distribution Affects Versions: Content Distribution Core 0.2.0 Reporter: Tommaso Teofili Assignee: Tommaso Teofili Fix For: Content Distribution Core 0.2.2 When configuring priority queues, they are wrongly set as _passive_. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (SLING-6512) Distribution ITs fail as they expect packages to be deleted synchronously
[ https://issues.apache.org/jira/browse/SLING-6512?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tommaso Teofili updated SLING-6512: --- Attachment: SLING-6512.0.patch attaching a patch which I think it could fix the issue by setting a shorter cleanup delay within the VaultFactories, however the IT failures stay. > Distribution ITs fail as they expect packages to be deleted synchronously > - > > Key: SLING-6512 > URL: https://issues.apache.org/jira/browse/SLING-6512 > Project: Sling > Issue Type: Bug > Components: Content Distribution >Reporter: Tommaso Teofili >Assignee: Tommaso Teofili > Attachments: SLING-6512.0.patch > > > After the fix for SLING-6503, packages are not deleted upon release > synchronously, they are removed asynchronously in a separate thread. > We should adjust the test not to expect such packages to be removed > immediately after their processing, /cc [~marett] -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Resolved] (SLING-6514) Test distributions should not go through the queues
[ https://issues.apache.org/jira/browse/SLING-6514?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tommaso Teofili resolved SLING-6514. Resolution: Fixed fixed in r1782306. > Test distributions should not go through the queues > --- > > Key: SLING-6514 > URL: https://issues.apache.org/jira/browse/SLING-6514 > Project: Sling > Issue Type: Bug > Components: Content Distribution >Affects Versions: Content Distribution Core 0.1.18 >Reporter: Tommaso Teofili >Assignee: Tommaso Teofili > Fix For: Content Distribution Core 0.2.2 > > > When performing distributions of type TEST the test package goes through the > packages like any other package, this should not be the case as TEST > distributions are usually meant to check that the agent can deliver > (permissions and network / disk IO are fine) and therefore they should be > delivered without going through the queues. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Created] (SLING-6514) Test distributions should not go through the queues
Tommaso Teofili created SLING-6514: -- Summary: Test distributions should not go through the queues Key: SLING-6514 URL: https://issues.apache.org/jira/browse/SLING-6514 Project: Sling Issue Type: Bug Components: Content Distribution Affects Versions: Content Distribution Core 0.1.18 Reporter: Tommaso Teofili Assignee: Tommaso Teofili Fix For: Content Distribution Core 0.2.2 When performing distributions of type TEST the test package goes through the packages like any other package, this should not be the case as TEST distributions are usually meant to check that the agent can deliver (permissions and network / disk IO are fine) and therefore they should be delivered without going through the queues. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Created] (SLING-6512) Distribution ITs fail as they expect packages to be deleted synchronously
Tommaso Teofili created SLING-6512: -- Summary: Distribution ITs fail as they expect packages to be deleted synchronously Key: SLING-6512 URL: https://issues.apache.org/jira/browse/SLING-6512 Project: Sling Issue Type: Bug Components: Content Distribution Reporter: Tommaso Teofili After the fix for SLING-6503, packages are not deleted upon release synchronously, they are removed asynchronously in a separate thread. We should adjust the test not to expect such packages to be removed immediately after their processing, /cc [~marett] -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (SLING-6503) Concurrency issue can prevent repository packages to be cleaned up
[ https://issues.apache.org/jira/browse/SLING-6503?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15851579#comment-15851579 ] Tommaso Teofili commented on SLING-6503: +1 LGTM > Concurrency issue can prevent repository packages to be cleaned up > - > > Key: SLING-6503 > URL: https://issues.apache.org/jira/browse/SLING-6503 > Project: Sling > Issue Type: Bug > Components: Content Distribution >Affects Versions: Content Distribution Core 0.1.18 >Reporter: Timothee Maret >Assignee: Timothee Maret > Fix For: Content Distribution Core 0.1.20 > > Attachments: SLING-6503.patch > > > In SCD setups with more than one export queue and storing packages in the > repository, packages may not be collected after being distributed to all > queues. > This is typically the case on the author instance of a Sync setup. > The current implementation [0] stores a resource in the repository in order > to keep track of each consumer of the package. When each consumer is done > distributing to its queue, it checks if there is no more registered resources > and remove the package if it is the case. > The problem is that consumers run concurrently and without synchronisation, > thus leading to situation where all consumers concurrently observe remaining > consumers and the cleanup is never executed. > [0] > https://github.com/apache/sling/blob/trunk/contrib/extensions/distribution/core/src/main/java/org/apache/sling/distribution/packaging/impl/ResourceDistributionPackage.java -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Deleted] (SLING-6456) Local importer should not fail if package stream is unnecessarily reset
[
https://issues.apache.org/jira/browse/SLING-6456?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tommaso Teofili deleted SLING-6456:
---
> Local importer should not fail if package stream is unnecessarily reset
> ---
>
> Key: SLING-6456
> URL: https://issues.apache.org/jira/browse/SLING-6456
> Project: Sling
> Issue Type: Bug
>Reporter: Tommaso Teofili
>Assignee: Tommaso Teofili
>
> {{LocalDistributionPackageImporter}} has a {{InputStream#reset}} call at the
> beginning of the block for handling non reference package as to support also
> those package sent by the {{AsyncDeliveryDispatchingStrategy}}.
> Currently it fails if reset is called unnecessarily, while it shouldn't be
> the case.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (SLING-5759) Distribution agents cannot be created via API
[
https://issues.apache.org/jira/browse/SLING-5759?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tommaso Teofili resolved SLING-5759.
Resolution: Fixed
Fix Version/s: Content Distribution 0.2.0
> 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: Content Distribution
>Reporter: Marius Petria
> Fix For: Content Distribution 0.2.0
>
>
> The IT tes
> {{DistributionAgentResourcesIntegrationTest.testAgentConfigurationResourceCreate}}
> fails and should be fixed.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (SLING-3311) Add facilities to monitor replication status
[ https://issues.apache.org/jira/browse/SLING-3311?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tommaso Teofili resolved SLING-3311. Resolution: Fixed Fix Version/s: Content Distribution 0.2.0 > Add facilities to monitor replication status > > > Key: SLING-3311 > URL: https://issues.apache.org/jira/browse/SLING-3311 > Project: Sling > Issue Type: Improvement > Components: Content Distribution >Reporter: Tommaso Teofili > Fix For: Content Distribution 0.2.0 > > > It'd be good to have one or more ways of monitoring the status of replication > agents / queues / etc. > Possible (not mutually exclusive) ways of doing that include: JMX, Sling > HealthChecks, HTTP Monitoring API. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (SLING-4575) Failure registering MBean HealthCheckMBean [healthCheck=org.apache.sling.distribution.monitor.DistributionQueueHealthCheck@...]
[
https://issues.apache.org/jira/browse/SLING-4575?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15830035#comment-15830035
]
Tommaso Teofili commented on SLING-4575:
I think this has been resolved already, [~olli] WDYT?
> Failure registering MBean HealthCheckMBean
> [healthCheck=org.apache.sling.distribution.monitor.DistributionQueueHealthCheck@...]
> ---
>
> Key: SLING-4575
> URL: https://issues.apache.org/jira/browse/SLING-4575
> Project: Sling
> Issue Type: Bug
> Components: Content Distribution
>Affects Versions: Content Distribution 0.1.0
> Environment: Apache Karaf 3.0.3
>Reporter: Oliver Lietz
>Assignee: Oliver Lietz
>
> {noformat}
> 2015-04-03 10:04:36,282 | INFO | FelixStartLevel |
> DistributionQueueHealthCheck | 169 - org.apache.sling.distribution.core -
> 0.1.0 | Activated, numberOfRetriesAllowed=3
> 2015-04-03 10:04:36,285 | ERROR | FelixStartLevel | MBeanHolder
> | 85 - org.apache.aries.jmx.whiteboard - 1.0.0 | register: Failure
> registering MBean HealthCheckMBean
> [healthCheck=org.apache.sling.distribution.monitor.DistributionQueueHealthCheck@36a6f19c]
> javax.management.InstanceAlreadyExistsException:
> org.apache.sling.healthcheck:type=HealthCheck,name=slingDistributionQueue
> at
> com.sun.jmx.mbeanserver.Repository.addMBean(Repository.java:437)[:1.8.0_40]
> at
> com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.registerWithRepository(DefaultMBeanServerInterceptor.java:1898)[:1.8.0_40]
> at
> com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.registerDynamicMBean(DefaultMBeanServerInterceptor.java:966)[:1.8.0_40]
> at
> com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.registerObject(DefaultMBeanServerInterceptor.java:900)[:1.8.0_40]
> at
> com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.registerMBean(DefaultMBeanServerInterceptor.java:324)[:1.8.0_40]
> at
> com.sun.jmx.mbeanserver.JmxMBeanServer.registerMBean(JmxMBeanServer.java:522)[:1.8.0_40]
> at Proxya4a7f910_bd0e_4598_92cf_9a73d8dff844.registerMBean(Unknown
> Source)
> at
> org.apache.aries.jmx.whiteboard.MBeanHolder.register(MBeanHolder.java:114)
> at
> org.apache.aries.jmx.whiteboard.JmxWhiteboardSupport.registerMBean(JmxWhiteboardSupport.java:86)
> at
> org.apache.aries.jmx.whiteboard.Activator$MBeanTracker.addingService(Activator.java:102)
> at
> org.osgi.util.tracker.ServiceTracker$Tracked.customizerAdding(ServiceTracker.java:932)[karaf-org.osgi.core.jar:]
> at
> org.osgi.util.tracker.ServiceTracker$Tracked.customizerAdding(ServiceTracker.java:864)[karaf-org.osgi.core.jar:]
> at
> org.osgi.util.tracker.AbstractTracked.trackAdding(AbstractTracked.java:256)[karaf-org.osgi.core.jar:]
> at
> org.osgi.util.tracker.AbstractTracked.track(AbstractTracked.java:229)[karaf-org.osgi.core.jar:]
> at
> org.osgi.util.tracker.ServiceTracker$Tracked.serviceChanged(ServiceTracker.java:894)[karaf-org.osgi.core.jar:]
> at
> org.apache.felix.framework.util.EventDispatcher.invokeServiceListenerCallback(EventDispatcher.java:932)[org.apache.felix.framework-4.2.1.jar:]
> at
> org.apache.felix.framework.util.EventDispatcher.fireEventImmediately(EventDispatcher.java:793)[org.apache.felix.framework-4.2.1.jar:]
> at
> org.apache.felix.framework.util.EventDispatcher.fireServiceEvent(EventDispatcher.java:543)[org.apache.felix.framework-4.2.1.jar:]
> at
> org.apache.felix.framework.Felix.fireServiceEvent(Felix.java:4419)[org.apache.felix.framework-4.2.1.jar:]
> at
> org.apache.felix.framework.Felix.registerService(Felix.java:3423)[org.apache.felix.framework-4.2.1.jar:]
> at
> org.apache.felix.framework.BundleContextImpl.registerService(BundleContextImpl.java:346)
> at
> org.apache.felix.framework.BundleContextImpl.registerService(BundleContextImpl.java:320)
> at
> org.apache.sling.hc.jmx.impl.HealthCheckMBeanCreator$Registration.register(HealthCheckMBeanCreator.java:177)
> at
> org.apache.sling.hc.jmx.impl.HealthCheckMBeanCreator.registerHCMBean(HealthCheckMBeanCreator.java:121)
> at
> org.apache.sling.hc.jmx.impl.HealthCheckMBeanCreator.access$000(HealthCheckMBeanCreator.java:46)
> at
> org.apache.sling.hc.jmx.impl.HealthCheckMBeanCreator$1.addingService(HealthCheckMBeanCreator.java:62)
> at
> org.osgi.util.tracker.ServiceTracker$Tracked.customizerAdding(ServiceTracker.java:932)[karaf-org.osgi.core.jar:]
> at
> org.osgi.util.tracker.ServiceTracker$Tracked.customizerAdding(ServiceTracker.java:864)[karaf-org.osgi.core.jar:]
> at
>
[jira] [Resolved] (SLING-5915) Fix IT failures in Content Distribution
[
https://issues.apache.org/jira/browse/SLING-5915?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tommaso Teofili resolved SLING-5915.
Resolution: Duplicate
> Fix IT failures in Content Distribution
> ---
>
> Key: SLING-5915
> URL: https://issues.apache.org/jira/browse/SLING-5915
> Project: Sling
> Issue Type: Bug
> Components: Content Distribution
>Reporter: Tommaso Teofili
> Fix For: Content Distribution 0.2.0
>
>
> Currently there're the following IT failures that we should fix before
> releasing SDC core 0.2.0.
> {noformat}
> Tests run: 13, Failures: 1, Errors: 0, Skipped: 1, Time elapsed: 215.478 sec
> <<< FAILURE! - in
> org.apache.sling.distribution.it.DistributionAgentResourcesIntegrationTest
> testAgentConfigurationResourceExtended(org.apache.sling.distribution.it.DistributionAgentResourcesIntegrationTest)
> Time elapsed: 100.974 sec <<< FAILURE!
> java.lang.AssertionError: path
> /etc/distribution/sample-create-config067f89fb-b059-4fde-84c8-411130681261
> doesn't exist
> at org.junit.Assert.fail(Assert.java:88)
> at org.junit.Assert.assertTrue(Assert.java:41)
> at
> org.apache.sling.distribution.it.DistributionUtils.assertExists(DistributionUtils.java:198)
> at
> org.apache.sling.distribution.it.DistributionAgentResourcesIntegrationTest.testAgentConfigurationResourceExtended(DistributionAgentResourcesIntegrationTest.java:174)
> Tests run: 4, Failures: 3, Errors: 1, Skipped: 0, Time elapsed: 46.174 sec
> <<< FAILURE! - in
> org.apache.sling.distribution.it.MultipleForwardDistributionTest
> testDeleteContent(org.apache.sling.distribution.it.MultipleForwardDistributionTest)
> Time elapsed: 9.193 sec <<< FAILURE!
> java.lang.AssertionError: POST request to
> http://localhost:59247/libs/sling/distribution/services/agents/publish-multiple/queues/passivequeue1:
> expecting status 200 expected:<200> but was:<500>
> at org.junit.Assert.fail(Assert.java:88)
> at org.junit.Assert.failNotEquals(Assert.java:743)
> at org.junit.Assert.assertEquals(Assert.java:118)
> at org.junit.Assert.assertEquals(Assert.java:555)
> at
> org.apache.sling.testing.tools.http.RequestExecutor.assertStatus(RequestExecutor.java:155)
> at
> org.apache.sling.distribution.it.DistributionUtils.assertPostResourceWithParameters(DistributionUtils.java:96)
> at
> org.apache.sling.distribution.it.MultipleForwardDistributionTest.clean(MultipleForwardDistributionTest.java:103)
> testAddContentCheckPassiveQueue(org.apache.sling.distribution.it.MultipleForwardDistributionTest)
> Time elapsed: 9.197 sec <<< ERROR!
> org.apache.sling.commons.json.JSONException: JSONObject["items"] not found.
> at org.apache.sling.commons.json.JSONObject.get(JSONObject.java:372)
> at
> org.apache.sling.commons.json.JSONObject.getJSONArray(JSONObject.java:448)
> at
> org.apache.sling.distribution.it.MultipleForwardDistributionTest.testAddContentCheckPassiveQueue(MultipleForwardDistributionTest.java:75)
> testAddContentCheckPassiveQueue(org.apache.sling.distribution.it.MultipleForwardDistributionTest)
> Time elapsed: 9.197 sec <<< FAILURE!
> java.lang.AssertionError: POST request to
> http://localhost:59247/libs/sling/distribution/services/agents/publish-multiple/queues/passivequeue1:
> expecting status 200 expected:<200> but was:<500>
> at org.junit.Assert.fail(Assert.java:88)
> at org.junit.Assert.failNotEquals(Assert.java:743)
> at org.junit.Assert.assertEquals(Assert.java:118)
> at org.junit.Assert.assertEquals(Assert.java:555)
> at
> org.apache.sling.testing.tools.http.RequestExecutor.assertStatus(RequestExecutor.java:155)
> at
> org.apache.sling.distribution.it.DistributionUtils.assertPostResourceWithParameters(DistributionUtils.java:96)
> at
> org.apache.sling.distribution.it.MultipleForwardDistributionTest.clean(MultipleForwardDistributionTest.java:103)
> testAddContent(org.apache.sling.distribution.it.MultipleForwardDistributionTest)
> Time elapsed: 9.197 sec <<< FAILURE!
> java.lang.AssertionError: POST request to
> http://localhost:59247/libs/sling/distribution/services/agents/publish-multiple/queues/passivequeue1:
> expecting status 200 expected:<200> but was:<500>
> at org.junit.Assert.fail(Assert.java:88)
> at org.junit.Assert.failNotEquals(Assert.java:743)
> at org.junit.Assert.assertEquals(Assert.java:118)
> at org.junit.Assert.assertEquals(Assert.java:555)
> at
> org.apache.sling.testing.tools.http.RequestExecutor.assertStatus(RequestExecutor.java:155)
> at
> org.apache.sling.distribution.it.DistributionUtils.assertPostResourceWithParameters(DistributionUtils.java:96)
> at
>
[jira] [Resolved] (SLING-6391) DefaultDistributionConfigurationManager overrides existing persisted properties
[
https://issues.apache.org/jira/browse/SLING-6391?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tommaso Teofili resolved SLING-6391.
Resolution: Fixed
> DefaultDistributionConfigurationManager overrides existing persisted
> properties
> ---
>
> Key: SLING-6391
> URL: https://issues.apache.org/jira/browse/SLING-6391
> Project: Sling
> Issue Type: Bug
> Components: Content Distribution
>Reporter: Tommaso Teofili
>Assignee: Tommaso Teofili
> Fix For: Content Distribution 0.2.0
>
>
> {{DefaultDistributionConfigurationManager}} doesn't take care of existing
> properties in the resource tree, so that persisted configs are not merged.
> Also defaults sometimes override actual parameters.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (SLING-6251) SCD integration tests fail due to blocked loginAdministrative
[
https://issues.apache.org/jira/browse/SLING-6251?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15830025#comment-15830025
]
Tommaso Teofili commented on SLING-6251:
we have removed _loginAdmin_ and they now pass thanks to [~marett]'s work on
SLING-6475.
> SCD integration tests fail due to blocked loginAdministrative
> -
>
> Key: SLING-6251
> URL: https://issues.apache.org/jira/browse/SLING-6251
> Project: Sling
> Issue Type: Task
> Components: Content Distribution
>Reporter: Julian Sedding
>Assignee: Julian Sedding
> Fix For: Content Distribution 0.2.0
>
>
> The Sling Content Distribution integration tests currently fail due to
> {{loginAdministrative}} being blocked.
> The log files of the tested instances show messages like these:
> {noformat}
> 02.11.2016 11:15:35.056 *ERROR* [qtp875477671-46]
> org.apache.sling.event.impl.jobs Unable to create new resource resolver:
> Bundle is not whitelisted for loginAdministrative:org.apache.sling.event
> org.apache.sling.api.resource.LoginException: Bundle is not whitelisted for
> loginAdministrative:org.apache.sling.event
> at
> org.apache.sling.jcr.resource.internal.helper.jcr.JcrProviderStateFactory.checkLoginAdminWhitelist(JcrProviderStateFactory.java:93)
> at
> org.apache.sling.jcr.resource.internal.helper.jcr.JcrProviderStateFactory.createProviderState(JcrProviderStateFactory.java:111)
> {noformat}
> At least the Event bundle needs to be updated and the "Sling Distribution
> Sample" needs to be adjusted to refrain from using {{loginAdministrative}}.
> cc [~teofili], [~simone.tripodi]
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (SLING-6251) SCD integration tests fail due to blocked loginAdministrative
[
https://issues.apache.org/jira/browse/SLING-6251?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tommaso Teofili resolved SLING-6251.
Resolution: Fixed
Fix Version/s: Content Distribution 0.2.0
> SCD integration tests fail due to blocked loginAdministrative
> -
>
> Key: SLING-6251
> URL: https://issues.apache.org/jira/browse/SLING-6251
> Project: Sling
> Issue Type: Task
> Components: Content Distribution
>Reporter: Julian Sedding
>Assignee: Julian Sedding
> Fix For: Content Distribution 0.2.0
>
>
> The Sling Content Distribution integration tests currently fail due to
> {{loginAdministrative}} being blocked.
> The log files of the tested instances show messages like these:
> {noformat}
> 02.11.2016 11:15:35.056 *ERROR* [qtp875477671-46]
> org.apache.sling.event.impl.jobs Unable to create new resource resolver:
> Bundle is not whitelisted for loginAdministrative:org.apache.sling.event
> org.apache.sling.api.resource.LoginException: Bundle is not whitelisted for
> loginAdministrative:org.apache.sling.event
> at
> org.apache.sling.jcr.resource.internal.helper.jcr.JcrProviderStateFactory.checkLoginAdminWhitelist(JcrProviderStateFactory.java:93)
> at
> org.apache.sling.jcr.resource.internal.helper.jcr.JcrProviderStateFactory.createProviderState(JcrProviderStateFactory.java:111)
> {noformat}
> At least the Event bundle needs to be updated and the "Sling Distribution
> Sample" needs to be adjusted to refrain from using {{loginAdministrative}}.
> cc [~teofili], [~simone.tripodi]
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (SLING-6477) Distributing with sling.jcr.api 2.2.0 should not throw NSME
[
https://issues.apache.org/jira/browse/SLING-6477?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tommaso Teofili resolved SLING-6477.
Resolution: Fixed
fixed in r1779444.
> Distributing with sling.jcr.api 2.2.0 should not throw NSME
> ---
>
> Key: SLING-6477
> URL: https://issues.apache.org/jira/browse/SLING-6477
> Project: Sling
> Issue Type: Bug
> Components: Content Distribution
>Affects Versions: Content Distribution Core 0.1.10
>Reporter: Tommaso Teofili
>Assignee: Tommaso Teofili
> Fix For: Content Distribution 0.2.0
>
>
> In SLING-5281 we introduced capability of distributing with user session,
> however that requires _sling.jcr.api-2.3.0_ because of
> {{SlingRepository#impersonateFromService}}. In SLING-5633 the dependency to
> _sling.jcr.api_ was moved from version _2.3.0_ to _2.2.0_ as to allow
> installation on older repositories.
> On such old repos if an agent uses the calling user session the following
> Error appears:
> {noformat}
> Error executing handler
> SimpleDistributionRequest{requestType=PULL, paths=[null]}
> java.lang.NoSuchMethodError:
> org.apache.sling.jcr.api.SlingRepository.impersonateFromService(Ljava/lang/
> String;Ljavax/jcr/Credentials;Ljava/lang/String;)Ljavax/jcr/Session;
> at
> org.apache.sling.distribution.util.impl.DistributionUtils.getResourceResolv
> er(DistributionUtils.java:89)
> {noformat}
> We should fallback to using the service user to login in such cases as to
> avoid such errors.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (SLING-6477) Distributing with sling.jcr.api 2.2.0 should not throw NSME
Tommaso Teofili created SLING-6477:
--
Summary: Distributing with sling.jcr.api 2.2.0 should not throw
NSME
Key: SLING-6477
URL: https://issues.apache.org/jira/browse/SLING-6477
Project: Sling
Issue Type: Bug
Components: Content Distribution
Affects Versions: Content Distribution Core 0.1.10
Reporter: Tommaso Teofili
Assignee: Tommaso Teofili
Fix For: Content Distribution 0.2.0
In SLING-5281 we introduced capability of distributing with user session,
however that requires _sling.jcr.api-2.3.0_ because of
{{SlingRepository#impersonateFromService}}. In SLING-5633 the dependency to
_sling.jcr.api_ was moved from version _2.3.0_ to _2.2.0_ as to allow
installation on older repositories.
On such old repos if an agent uses the calling user session the following Error
appears:
{noformat}
Error executing handler
SimpleDistributionRequest{requestType=PULL, paths=[null]}
java.lang.NoSuchMethodError:
org.apache.sling.jcr.api.SlingRepository.impersonateFromService(Ljava/lang/
String;Ljavax/jcr/Credentials;Ljava/lang/String;)Ljavax/jcr/Session;
at
org.apache.sling.distribution.util.impl.DistributionUtils.getResourceResolv
er(DistributionUtils.java:89)
{noformat}
We should fallback to using the service user to login in such cases as to avoid
such errors.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Deleted] (SLING-6455) Local importer should not fail if package stream is unnecessarily reset
[
https://issues.apache.org/jira/browse/SLING-6455?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tommaso Teofili deleted SLING-6455:
---
> Local importer should not fail if package stream is unnecessarily reset
> ---
>
> Key: SLING-6455
> URL: https://issues.apache.org/jira/browse/SLING-6455
> Project: Sling
> Issue Type: Bug
>Reporter: Tommaso Teofili
>Assignee: Tommaso Teofili
>
> {{LocalDistributionPackageImporter}} has a {{InputStream#reset}} call at the
> beginning of the block for handling non reference package as to support also
> those package sent by the {{AsyncDeliveryDispatchingStrategy}}.
> Currently it fails if reset is called unnecessarily, while it shouldn't be
> the case.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Deleted] (SLING-6454) Local importer should not fail if package stream is unnecessarily reset
[
https://issues.apache.org/jira/browse/SLING-6454?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tommaso Teofili deleted SLING-6454:
---
> Local importer should not fail if package stream is unnecessarily reset
> ---
>
> Key: SLING-6454
> URL: https://issues.apache.org/jira/browse/SLING-6454
> Project: Sling
> Issue Type: Bug
>Reporter: Tommaso Teofili
>Assignee: Tommaso Teofili
>
> {{LocalDistributionPackageImporter}} has a {{InputStream#reset}} call at the
> beginning of the block for handling non reference package as to support also
> those package sent by the {{AsyncDeliveryDispatchingStrategy}}.
> Currently it fails if reset is called unnecessarily, while it shouldn't be
> the case.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (SLING-6250) Importing packages with large headers fails
[
https://issues.apache.org/jira/browse/SLING-6250?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15825874#comment-15825874
]
Tommaso Teofili edited comment on SLING-6250 at 1/17/17 11:19 AM:
--
the _stream.reset()_ call was set there to make
{{LocalDistributionPackageImporter}} work together with
{{AsyncDeliveryDispatchingStrategy}}, because there the same importer is used
for both storing a reference package and the referenced (actual) package which
come with different headers.
I have put a _TODO_ as I think that reset should be avoided at all if possible,
but that's not needed in most of the cases (async dispatching is not used by
default) anyway.
So I was thinking to fix the issue here (throwing a RE is probably too much
anyway) and open a new one for improving the way headers are read in sync and
async cases.
was (Author: teofili):
the _stream.reset()_ call was set there to make
{{LocalDistributionPackageImporter}} work together with
{{AsyncDeliveryDispatchingStrategy}}, because there the same importer is used
for both storing a reference package and the referenced (actual) package.
I have put a _TODO_ as I think that reset should be avoided at all if possible,
but that's not needed in most of the cases (async dispatching is not used by
default) anyway.
So I was thinking to fix the issue here (throwing a RE is probably too much
anyway) and open a new one for improving the way headers are read in sync and
async cases.
> Importing packages with large headers fails
> ---
>
> Key: SLING-6250
> URL: https://issues.apache.org/jira/browse/SLING-6250
> Project: Sling
> Issue Type: Bug
> Components: Distribution
>Affects Versions: Content Distribution Core 0.1.18
>Reporter: Julian Sedding
>Assignee: Tommaso Teofili
> Attachments: SLING-6250-testcase.patch
>
>
> When importing packages with large headers, e.g. packages containing many
> paths, the following exception is thrown:
> {noformat}
> java.lang.RuntimeException: java.io.IOException: Resetting to invalid mark
> at java.io.BufferedInputStream.reset(BufferedInputStream.java:448)
> at
> org.apache.sling.distribution.packaging.impl.importer.LocalDistributionPackageImporter.importStream(LocalDistributionPackageImporter.java:122)
> at
> org.apache.sling.distribution.packaging.impl.importer.LocalDistributionPackageImporterTest.importPackageWithLargeHeader(LocalDistributionPackageImporterTest.java:100)
> {noformat}
> This happens when the header is larger than the default buffer size of the
> {{BufferedInputStream}} and thus its {{#mark()}} is lost and {{#reset()}}
> cannot happen anymore.
> I will investigate, whether we can stop relying on marked input streams. This
> would be desirable, because we cannot know in advance how long the header is.
> cc [~teofili]
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (SLING-6250) Importing packages with large headers fails
[
https://issues.apache.org/jira/browse/SLING-6250?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15825874#comment-15825874
]
Tommaso Teofili commented on SLING-6250:
the _stream.reset()_ call was set there to make
{{LocalDistributionPackageImporter}} work together with
{{AsyncDeliveryDispatchingStrategy}}, because there the same importer is used
for both storing a reference package and the referenced (actual) package.
I have put a _TODO_ as I think that reset should be avoided at all if possible,
but that's not needed in most of the cases (async dispatching is not used by
default) anyway.
So I was thinking to fix the issue here (throwing a RE is probably too much
anyway) and open a new one for improving the way headers are read in sync and
async cases.
> Importing packages with large headers fails
> ---
>
> Key: SLING-6250
> URL: https://issues.apache.org/jira/browse/SLING-6250
> Project: Sling
> Issue Type: Bug
> Components: Distribution
>Affects Versions: Content Distribution Core 0.1.18
>Reporter: Julian Sedding
>Assignee: Tommaso Teofili
> Attachments: SLING-6250-testcase.patch
>
>
> When importing packages with large headers, e.g. packages containing many
> paths, the following exception is thrown:
> {noformat}
> java.lang.RuntimeException: java.io.IOException: Resetting to invalid mark
> at java.io.BufferedInputStream.reset(BufferedInputStream.java:448)
> at
> org.apache.sling.distribution.packaging.impl.importer.LocalDistributionPackageImporter.importStream(LocalDistributionPackageImporter.java:122)
> at
> org.apache.sling.distribution.packaging.impl.importer.LocalDistributionPackageImporterTest.importPackageWithLargeHeader(LocalDistributionPackageImporterTest.java:100)
> {noformat}
> This happens when the header is larger than the default buffer size of the
> {{BufferedInputStream}} and thus its {{#mark()}} is lost and {{#reset()}}
> cannot happen anymore.
> I will investigate, whether we can stop relying on marked input streams. This
> would be desirable, because we cannot know in advance how long the header is.
> cc [~teofili]
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (SLING-6250) Importing packages with large headers fails
[
https://issues.apache.org/jira/browse/SLING-6250?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tommaso Teofili resolved SLING-6250.
Resolution: Fixed
test added in r1779164, fix was introduced in r1778443.
> Importing packages with large headers fails
> ---
>
> Key: SLING-6250
> URL: https://issues.apache.org/jira/browse/SLING-6250
> Project: Sling
> Issue Type: Bug
> Components: Distribution
>Affects Versions: Content Distribution Core 0.1.18
>Reporter: Julian Sedding
>Assignee: Tommaso Teofili
> Attachments: SLING-6250-testcase.patch
>
>
> When importing packages with large headers, e.g. packages containing many
> paths, the following exception is thrown:
> {noformat}
> java.lang.RuntimeException: java.io.IOException: Resetting to invalid mark
> at java.io.BufferedInputStream.reset(BufferedInputStream.java:448)
> at
> org.apache.sling.distribution.packaging.impl.importer.LocalDistributionPackageImporter.importStream(LocalDistributionPackageImporter.java:122)
> at
> org.apache.sling.distribution.packaging.impl.importer.LocalDistributionPackageImporterTest.importPackageWithLargeHeader(LocalDistributionPackageImporterTest.java:100)
> {noformat}
> This happens when the header is larger than the default buffer size of the
> {{BufferedInputStream}} and thus its {{#mark()}} is lost and {{#reset()}}
> cannot happen anymore.
> I will investigate, whether we can stop relying on marked input streams. This
> would be desirable, because we cannot know in advance how long the header is.
> cc [~teofili]
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Assigned] (SLING-6250) Importing packages with large headers fails
[
https://issues.apache.org/jira/browse/SLING-6250?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tommaso Teofili reassigned SLING-6250:
--
Assignee: Tommaso Teofili (was: Julian Sedding)
> Importing packages with large headers fails
> ---
>
> Key: SLING-6250
> URL: https://issues.apache.org/jira/browse/SLING-6250
> Project: Sling
> Issue Type: Bug
> Components: Distribution
>Affects Versions: Content Distribution Core 0.1.18
>Reporter: Julian Sedding
>Assignee: Tommaso Teofili
> Attachments: SLING-6250-testcase.patch
>
>
> When importing packages with large headers, e.g. packages containing many
> paths, the following exception is thrown:
> {noformat}
> java.lang.RuntimeException: java.io.IOException: Resetting to invalid mark
> at java.io.BufferedInputStream.reset(BufferedInputStream.java:448)
> at
> org.apache.sling.distribution.packaging.impl.importer.LocalDistributionPackageImporter.importStream(LocalDistributionPackageImporter.java:122)
> at
> org.apache.sling.distribution.packaging.impl.importer.LocalDistributionPackageImporterTest.importPackageWithLargeHeader(LocalDistributionPackageImporterTest.java:100)
> {noformat}
> This happens when the header is larger than the default buffer size of the
> {{BufferedInputStream}} and thus its {{#mark()}} is lost and {{#reset()}}
> cannot happen anymore.
> I will investigate, whether we can stop relying on marked input streams. This
> would be desirable, because we cannot know in advance how long the header is.
> cc [~teofili]
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (SLING-5991) [SCD] Evaluate avoiding to buffer the whole packages before streaming
[
https://issues.apache.org/jira/browse/SLING-5991?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15753912#comment-15753912
]
Tommaso Teofili commented on SLING-5991:
functionally speaking I've tested your patch on a performance benchmark and
everything works.
One thing I've noticed is the default package size (set to 1MB) in
{{ResourcePackageBuilder}}, usually at first we don't know the package size
before the serializer is called (hence it's initially set to -1 IIRC).
> [SCD] Evaluate avoiding to buffer the whole packages before streaming
> -
>
> Key: SLING-5991
> URL: https://issues.apache.org/jira/browse/SLING-5991
> Project: Sling
> Issue Type: Improvement
> Components: Distribution
>Affects Versions: Content Distribution 0.2.0
>Reporter: Timothee Maret
>Assignee: Timothee Maret
> Fix For: Content Distribution 0.2.0
>
> Attachments: SLING-5991.patch
>
>
> As described in SLING-5990, It seems streaming only starts when the whole
> binary is completely buffered (in memory and/or file). The buffering time
> implies a latency which which could be avoided by streaming directly.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (SLING-6391) DefaultDistributionConfigurationManager overrides existing persisted properties
[
https://issues.apache.org/jira/browse/SLING-6391?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15744630#comment-15744630
]
Tommaso Teofili commented on SLING-6391:
made some adjustments in r1773933.
> DefaultDistributionConfigurationManager overrides existing persisted
> properties
> ---
>
> Key: SLING-6391
> URL: https://issues.apache.org/jira/browse/SLING-6391
> Project: Sling
> Issue Type: Bug
> Components: Distribution
>Reporter: Tommaso Teofili
>Assignee: Tommaso Teofili
> Fix For: Content Distribution 0.2.0
>
>
> {{DefaultDistributionConfigurationManager}} doesn't take care of existing
> properties in the resource tree, so that persisted configs are not merged.
> Also defaults sometimes override actual parameters.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (SLING-6391) DefaultDistributionConfigurationManager overrides existing persisted properties
Tommaso Teofili created SLING-6391:
--
Summary: DefaultDistributionConfigurationManager overrides
existing persisted properties
Key: SLING-6391
URL: https://issues.apache.org/jira/browse/SLING-6391
Project: Sling
Issue Type: Bug
Components: Distribution
Reporter: Tommaso Teofili
Assignee: Tommaso Teofili
Fix For: Content Distribution 0.2.0
{{DefaultDistributionConfigurationManager}} doesn't take care of existing
properties in the resource tree, so that persisted configs are not merged.
Also defaults sometimes override actual parameters.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (SLING-5976) [SCD] Configurable "repackage and retry" transport mechanism
[
https://issues.apache.org/jira/browse/SLING-5976?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tommaso Teofili resolved SLING-5976.
Resolution: Won't Fix
Fix Version/s: (was: Content Distribution 0.2.0)
resolving as won't fix.
The failures in the mentioned scenario are usually due to either bad
configuration or latency issues in persisting the actual binaries in the
underlying {{ResourceProvider}}. Such issues should be solved at their root
rather than requiring repackaging stuff on the application layer.
> [SCD] Configurable "repackage and retry" transport mechanism
>
>
> Key: SLING-5976
> URL: https://issues.apache.org/jira/browse/SLING-5976
> Project: Sling
> Issue Type: Improvement
> Components: Distribution
>Reporter: Tommaso Teofili
>Assignee: Tommaso Teofili
>
> In some scenarios (e.g. distribution of resources whose binary properties are
> referenced) it may be required to have "recreate package and send again"
> mechanism.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (SLING-5991) [SCD] Evaluate avoiding to buffer the whole packages before streaming
[ https://issues.apache.org/jira/browse/SLING-5991?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tommaso Teofili updated SLING-5991: --- Assignee: Timothee Maret (was: Tommaso Teofili) > [SCD] Evaluate avoiding to buffer the whole packages before streaming > - > > Key: SLING-5991 > URL: https://issues.apache.org/jira/browse/SLING-5991 > Project: Sling > Issue Type: Improvement > Components: Distribution >Affects Versions: Content Distribution 0.2.0 >Reporter: Timothee Maret >Assignee: Timothee Maret > Fix For: Content Distribution 0.2.0 > > > As described in SLING-5990, It seems streaming only starts when the whole > binary is completely buffered (in memory and/or file). The buffering time > implies a latency which which could be avoided by streaming directly. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (SLING-5991) [SCD] Evaluate avoiding to buffer the whole packages before streaming
[
https://issues.apache.org/jira/browse/SLING-5991?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15728852#comment-15728852
]
Tommaso Teofili commented on SLING-5991:
[~marett], I had an offline discussion with [~simone.tripodi] and these are our
conclusions so far:
1. we need the package persisted afterwards (during queue processing)
2. we directly stream the outputstream to file in
{{FileDistributionPackageBuilder}} therefore that should be fine IIUTC
3. the {{ResourceDistributionPackageBuilder}} writes the outputstream to
{{FileBackedMemoryOutputStream}} (memory and / or file) because there's no
proper Sling / JCR API that wraps an {{OutputStream}} and we can make us of, at
least AFAIK (I had found JCR-2235 but that has never been implemented)
Did I / we get this right ?
Would you have any suggestions ?
> [SCD] Evaluate avoiding to buffer the whole packages before streaming
> -
>
> Key: SLING-5991
> URL: https://issues.apache.org/jira/browse/SLING-5991
> Project: Sling
> Issue Type: Improvement
> Components: Distribution
>Affects Versions: Content Distribution 0.2.0
>Reporter: Timothee Maret
>Assignee: Tommaso Teofili
> Fix For: Content Distribution 0.2.0
>
>
> As described in SLING-5990, It seems streaming only starts when the whole
> binary is completely buffered (in memory and/or file). The buffering time
> implies a latency which which could be avoided by streaming directly.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (SLING-6324) MonitoringDistributionPackageBuilder registering of same beans cause exception
[
https://issues.apache.org/jira/browse/SLING-6324?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tommaso Teofili resolved SLING-6324.
Resolution: Fixed
> MonitoringDistributionPackageBuilder registering of same beans cause exception
> --
>
> Key: SLING-6324
> URL: https://issues.apache.org/jira/browse/SLING-6324
> Project: Sling
> Issue Type: Bug
> Components: Distribution
>Reporter: Tommaso Teofili
>Assignee: Tommaso Teofili
> Fix For: Content Distribution 0.2.0
>
> Attachments: SLING-6324.patch
>
>
> While distributing some content massively I have encountered lots of
> stacktraces like below (on sending instance):
> {noformat}
> 24.11.2016 13:09:37.424 *INFO* [127.0.0.1 [1479989377273] POST
> /bin/replicate.json HTTP/1.1]
> org.apache.sling.distribution.agent.impl.SimpleDistributionAgent
> [agent][publish] REQUEST-START DSTRQ2791: ADD
> paths=[/content/test10K/node27/subnode90], user=replication-service
> 24.11.2016 13:09:37.425 *ERROR*
> [sling-threadpool-7c966356-fcc8-467b-9d58-eab12551b43c-(apache-sling-job-thread-pool)-2-org_apache_sling_distribution_queue_publish_default(org/apache/sling/distribution/queue/publish/default)]
> org.apache.aries.jmx.whiteboard.MBeanHolder register: Failure registering
> MBean
> org.apache.aries.jmx.util.shared.RegistrableStandardEmitterMBean@42b86d48
> javax.management.InstanceAlreadyExistsException:
> org.apache.sling.distribution:type=distributionpackage,id="/var/sling/distribution/packages/kryo-cs/data/dstrpck-1479989376714-b79fc9b9-a3e2-4a03-a33c-e87ccd17b8dc"
> at com.sun.jmx.mbeanserver.Repository.addMBean(Repository.java:437)
> at
> com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.registerWithRepository(DefaultMBeanServerInterceptor.java:1898)
> at
> com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.registerDynamicMBean(DefaultMBeanServerInterceptor.java:966)
> at
> com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.registerObject(DefaultMBeanServerInterceptor.java:900)
> at
> com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.registerMBean(DefaultMBeanServerInterceptor.java:324)
> at
> com.sun.jmx.mbeanserver.JmxMBeanServer.registerMBean(JmxMBeanServer.java:522)
> at
> org.apache.aries.jmx.whiteboard.MBeanHolder.register(MBeanHolder.java:114)
> at
> org.apache.aries.jmx.whiteboard.JmxWhiteboardSupport.registerMBean(JmxWhiteboardSupport.java:86)
> at
> org.apache.aries.jmx.whiteboard.Activator$MBeanTracker.addingService(Activator.java:102)
> at
> org.osgi.util.tracker.ServiceTracker$Tracked.customizerAdding(ServiceTracker.java:941)
> at
> org.osgi.util.tracker.ServiceTracker$Tracked.customizerAdding(ServiceTracker.java:870)
> at
> org.osgi.util.tracker.AbstractTracked.trackAdding(AbstractTracked.java:256)
> at org.osgi.util.tracker.AbstractTracked.track(AbstractTracked.java:229)
> at
> org.osgi.util.tracker.ServiceTracker$Tracked.serviceChanged(ServiceTracker.java:901)
> at
> org.apache.felix.framework.util.EventDispatcher.invokeServiceListenerCallback(EventDispatcher.java:991)
> at
> org.apache.felix.framework.util.EventDispatcher.fireEventImmediately(EventDispatcher.java:839)
> at
> org.apache.felix.framework.util.EventDispatcher.fireServiceEvent(EventDispatcher.java:546)
> at org.apache.felix.framework.Felix.fireServiceEvent(Felix.java:4558)
> at org.apache.felix.framework.Felix.registerService(Felix.java:3550)
> at
> org.apache.felix.framework.BundleContextImpl.registerService(BundleContextImpl.java:348)
> at
> org.apache.felix.framework.BundleContextImpl.registerService(BundleContextImpl.java:322)
> at
> org.apache.sling.distribution.monitor.impl.MonitoringDistributionPackageBuilder.registerDistributionPackageMBean(MonitoringDistributionPackageBuilder.java:109)
> at
> org.apache.sling.distribution.monitor.impl.MonitoringDistributionPackageBuilder.getPackage(MonitoringDistributionPackageBuilder.java:81)
> at
> org.apache.sling.distribution.serialization.impl.DistributionPackageBuilderFactory.getPackage(DistributionPackageBuilderFactory.java:222)
> at
> org.apache.sling.distribution.packaging.impl.exporter.LocalDistributionPackageExporter.getPackage(LocalDistributionPackageExporter.java:55)
> at
> org.apache.sling.distribution.agent.impl.SimpleDistributionAgentQueueProcessor.processQueueItem(SimpleDistributionAgentQueueProcessor.java:116)
> at
> org.apache.sling.distribution.agent.impl.SimpleDistributionAgentQueueProcessor.process(SimpleDistributionAgentQueueProcessor.java:84)
> at
>
[jira] [Resolved] (SLING-6339) Clean-up from compiler Warning messages the Distribution Core and ITs source code
[ https://issues.apache.org/jira/browse/SLING-6339?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tommaso Teofili resolved SLING-6339. Resolution: Fixed thanks Simone, I've applied your patch in r1771915. > Clean-up from compiler Warning messages the Distribution Core and ITs source > code > -- > > Key: SLING-6339 > URL: https://issues.apache.org/jira/browse/SLING-6339 > Project: Sling > Issue Type: Improvement > Components: Distribution >Reporter: Simone Tripodi >Assignee: Tommaso Teofili >Priority: Minor > Attachments: SLING-6339.patch > > > As per subject, there are compiler Warning messages that are not so easy to > read in both the Distribution Core and ITs source code. > Patch is coming -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Reopened] (SLING-6324) MonitoringDistributionPackageBuilder registering of same beans cause exception
[
https://issues.apache.org/jira/browse/SLING-6324?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tommaso Teofili reopened SLING-6324:
reopening as it seems the {{MonitoringDistributionPackageBuilder}} is actually
registering mbeans twice on sender (create() and get()) and on receiver (read()
and install()).
> MonitoringDistributionPackageBuilder registering of same beans cause exception
> --
>
> Key: SLING-6324
> URL: https://issues.apache.org/jira/browse/SLING-6324
> Project: Sling
> Issue Type: Bug
> Components: Distribution
>Reporter: Tommaso Teofili
>Assignee: Tommaso Teofili
> Fix For: Content Distribution 0.2.0
>
> Attachments: SLING-6324.patch
>
>
> While distributing some content massively I have encountered lots of
> stacktraces like below (on sending instance):
> {noformat}
> 24.11.2016 13:09:37.424 *INFO* [127.0.0.1 [1479989377273] POST
> /bin/replicate.json HTTP/1.1]
> org.apache.sling.distribution.agent.impl.SimpleDistributionAgent
> [agent][publish] REQUEST-START DSTRQ2791: ADD
> paths=[/content/test10K/node27/subnode90], user=replication-service
> 24.11.2016 13:09:37.425 *ERROR*
> [sling-threadpool-7c966356-fcc8-467b-9d58-eab12551b43c-(apache-sling-job-thread-pool)-2-org_apache_sling_distribution_queue_publish_default(org/apache/sling/distribution/queue/publish/default)]
> org.apache.aries.jmx.whiteboard.MBeanHolder register: Failure registering
> MBean
> org.apache.aries.jmx.util.shared.RegistrableStandardEmitterMBean@42b86d48
> javax.management.InstanceAlreadyExistsException:
> org.apache.sling.distribution:type=distributionpackage,id="/var/sling/distribution/packages/kryo-cs/data/dstrpck-1479989376714-b79fc9b9-a3e2-4a03-a33c-e87ccd17b8dc"
> at com.sun.jmx.mbeanserver.Repository.addMBean(Repository.java:437)
> at
> com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.registerWithRepository(DefaultMBeanServerInterceptor.java:1898)
> at
> com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.registerDynamicMBean(DefaultMBeanServerInterceptor.java:966)
> at
> com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.registerObject(DefaultMBeanServerInterceptor.java:900)
> at
> com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.registerMBean(DefaultMBeanServerInterceptor.java:324)
> at
> com.sun.jmx.mbeanserver.JmxMBeanServer.registerMBean(JmxMBeanServer.java:522)
> at
> org.apache.aries.jmx.whiteboard.MBeanHolder.register(MBeanHolder.java:114)
> at
> org.apache.aries.jmx.whiteboard.JmxWhiteboardSupport.registerMBean(JmxWhiteboardSupport.java:86)
> at
> org.apache.aries.jmx.whiteboard.Activator$MBeanTracker.addingService(Activator.java:102)
> at
> org.osgi.util.tracker.ServiceTracker$Tracked.customizerAdding(ServiceTracker.java:941)
> at
> org.osgi.util.tracker.ServiceTracker$Tracked.customizerAdding(ServiceTracker.java:870)
> at
> org.osgi.util.tracker.AbstractTracked.trackAdding(AbstractTracked.java:256)
> at org.osgi.util.tracker.AbstractTracked.track(AbstractTracked.java:229)
> at
> org.osgi.util.tracker.ServiceTracker$Tracked.serviceChanged(ServiceTracker.java:901)
> at
> org.apache.felix.framework.util.EventDispatcher.invokeServiceListenerCallback(EventDispatcher.java:991)
> at
> org.apache.felix.framework.util.EventDispatcher.fireEventImmediately(EventDispatcher.java:839)
> at
> org.apache.felix.framework.util.EventDispatcher.fireServiceEvent(EventDispatcher.java:546)
> at org.apache.felix.framework.Felix.fireServiceEvent(Felix.java:4558)
> at org.apache.felix.framework.Felix.registerService(Felix.java:3550)
> at
> org.apache.felix.framework.BundleContextImpl.registerService(BundleContextImpl.java:348)
> at
> org.apache.felix.framework.BundleContextImpl.registerService(BundleContextImpl.java:322)
> at
> org.apache.sling.distribution.monitor.impl.MonitoringDistributionPackageBuilder.registerDistributionPackageMBean(MonitoringDistributionPackageBuilder.java:109)
> at
> org.apache.sling.distribution.monitor.impl.MonitoringDistributionPackageBuilder.getPackage(MonitoringDistributionPackageBuilder.java:81)
> at
> org.apache.sling.distribution.serialization.impl.DistributionPackageBuilderFactory.getPackage(DistributionPackageBuilderFactory.java:222)
> at
> org.apache.sling.distribution.packaging.impl.exporter.LocalDistributionPackageExporter.getPackage(LocalDistributionPackageExporter.java:55)
> at
> org.apache.sling.distribution.agent.impl.SimpleDistributionAgentQueueProcessor.processQueueItem(SimpleDistributionAgentQueueProcessor.java:116)
> at
>
[jira] [Resolved] (SLING-6324) MonitoringDistributionPackageBuilder registering of same beans cause exception
[
https://issues.apache.org/jira/browse/SLING-6324?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tommaso Teofili resolved SLING-6324.
Resolution: Fixed
Fix Version/s: (was: Content Distribution Core 0.1.20)
Content Distribution 0.2.0
thanks a lot Simo, I've applied your patch!
> MonitoringDistributionPackageBuilder registering of same beans cause exception
> --
>
> Key: SLING-6324
> URL: https://issues.apache.org/jira/browse/SLING-6324
> Project: Sling
> Issue Type: Bug
> Components: Distribution
>Reporter: Tommaso Teofili
>Assignee: Tommaso Teofili
> Fix For: Content Distribution 0.2.0
>
> Attachments: SLING-6324.patch
>
>
> While distributing some content massively I have encountered lots of
> stacktraces like below (on sending instance):
> {noformat}
> 24.11.2016 13:09:37.424 *INFO* [127.0.0.1 [1479989377273] POST
> /bin/replicate.json HTTP/1.1]
> org.apache.sling.distribution.agent.impl.SimpleDistributionAgent
> [agent][publish] REQUEST-START DSTRQ2791: ADD
> paths=[/content/test10K/node27/subnode90], user=replication-service
> 24.11.2016 13:09:37.425 *ERROR*
> [sling-threadpool-7c966356-fcc8-467b-9d58-eab12551b43c-(apache-sling-job-thread-pool)-2-org_apache_sling_distribution_queue_publish_default(org/apache/sling/distribution/queue/publish/default)]
> org.apache.aries.jmx.whiteboard.MBeanHolder register: Failure registering
> MBean
> org.apache.aries.jmx.util.shared.RegistrableStandardEmitterMBean@42b86d48
> javax.management.InstanceAlreadyExistsException:
> org.apache.sling.distribution:type=distributionpackage,id="/var/sling/distribution/packages/kryo-cs/data/dstrpck-1479989376714-b79fc9b9-a3e2-4a03-a33c-e87ccd17b8dc"
> at com.sun.jmx.mbeanserver.Repository.addMBean(Repository.java:437)
> at
> com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.registerWithRepository(DefaultMBeanServerInterceptor.java:1898)
> at
> com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.registerDynamicMBean(DefaultMBeanServerInterceptor.java:966)
> at
> com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.registerObject(DefaultMBeanServerInterceptor.java:900)
> at
> com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.registerMBean(DefaultMBeanServerInterceptor.java:324)
> at
> com.sun.jmx.mbeanserver.JmxMBeanServer.registerMBean(JmxMBeanServer.java:522)
> at
> org.apache.aries.jmx.whiteboard.MBeanHolder.register(MBeanHolder.java:114)
> at
> org.apache.aries.jmx.whiteboard.JmxWhiteboardSupport.registerMBean(JmxWhiteboardSupport.java:86)
> at
> org.apache.aries.jmx.whiteboard.Activator$MBeanTracker.addingService(Activator.java:102)
> at
> org.osgi.util.tracker.ServiceTracker$Tracked.customizerAdding(ServiceTracker.java:941)
> at
> org.osgi.util.tracker.ServiceTracker$Tracked.customizerAdding(ServiceTracker.java:870)
> at
> org.osgi.util.tracker.AbstractTracked.trackAdding(AbstractTracked.java:256)
> at org.osgi.util.tracker.AbstractTracked.track(AbstractTracked.java:229)
> at
> org.osgi.util.tracker.ServiceTracker$Tracked.serviceChanged(ServiceTracker.java:901)
> at
> org.apache.felix.framework.util.EventDispatcher.invokeServiceListenerCallback(EventDispatcher.java:991)
> at
> org.apache.felix.framework.util.EventDispatcher.fireEventImmediately(EventDispatcher.java:839)
> at
> org.apache.felix.framework.util.EventDispatcher.fireServiceEvent(EventDispatcher.java:546)
> at org.apache.felix.framework.Felix.fireServiceEvent(Felix.java:4558)
> at org.apache.felix.framework.Felix.registerService(Felix.java:3550)
> at
> org.apache.felix.framework.BundleContextImpl.registerService(BundleContextImpl.java:348)
> at
> org.apache.felix.framework.BundleContextImpl.registerService(BundleContextImpl.java:322)
> at
> org.apache.sling.distribution.monitor.impl.MonitoringDistributionPackageBuilder.registerDistributionPackageMBean(MonitoringDistributionPackageBuilder.java:109)
> at
> org.apache.sling.distribution.monitor.impl.MonitoringDistributionPackageBuilder.getPackage(MonitoringDistributionPackageBuilder.java:81)
> at
> org.apache.sling.distribution.serialization.impl.DistributionPackageBuilderFactory.getPackage(DistributionPackageBuilderFactory.java:222)
> at
> org.apache.sling.distribution.packaging.impl.exporter.LocalDistributionPackageExporter.getPackage(LocalDistributionPackageExporter.java:55)
> at
> org.apache.sling.distribution.agent.impl.SimpleDistributionAgentQueueProcessor.processQueueItem(SimpleDistributionAgentQueueProcessor.java:116)
> at
>
[jira] [Created] (SLING-6325) Split Avro and Kryo serializers into their own bundles
Tommaso Teofili created SLING-6325:
--
Summary: Split Avro and Kryo serializers into their own bundles
Key: SLING-6325
URL: https://issues.apache.org/jira/browse/SLING-6325
Project: Sling
Issue Type: Task
Components: Distribution
Reporter: Tommaso Teofili
Assignee: Tommaso Teofili
A while ago we created the _sling.distribution.extensions_ bundle to host some
PoCs for SCD extension points.
Now that the {{DistributionContentSerializer}} API is exposed it'd be probably
better to create two separate bundles for Kryo and Avro serializers as it's
more likely that people will only use one of those serializers only, also for
decoupling and separation of dependencies concerns.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (SLING-5815) Expose DistributionContentSerializer
[
https://issues.apache.org/jira/browse/SLING-5815?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tommaso Teofili resolved SLING-5815.
Resolution: Fixed
> 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, SLING-5815.1.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] [Assigned] (SLING-6324) MonitoringDistributionPackageBuilder registering of same beans cause exception
[
https://issues.apache.org/jira/browse/SLING-6324?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tommaso Teofili reassigned SLING-6324:
--
Assignee: Tommaso Teofili
> MonitoringDistributionPackageBuilder registering of same beans cause exception
> --
>
> Key: SLING-6324
> URL: https://issues.apache.org/jira/browse/SLING-6324
> Project: Sling
> Issue Type: Bug
> Components: Distribution
>Reporter: Tommaso Teofili
>Assignee: Tommaso Teofili
> Fix For: Content Distribution Core 0.1.20
>
>
> While distributing some content massively I have encountered lots of
> stacktraces like below (on sending instance):
> {noformat}
> 24.11.2016 13:09:37.424 *INFO* [127.0.0.1 [1479989377273] POST
> /bin/replicate.json HTTP/1.1]
> org.apache.sling.distribution.agent.impl.SimpleDistributionAgent
> [agent][publish] REQUEST-START DSTRQ2791: ADD
> paths=[/content/test10K/node27/subnode90], user=replication-service
> 24.11.2016 13:09:37.425 *ERROR*
> [sling-threadpool-7c966356-fcc8-467b-9d58-eab12551b43c-(apache-sling-job-thread-pool)-2-org_apache_sling_distribution_queue_publish_default(org/apache/sling/distribution/queue/publish/default)]
> org.apache.aries.jmx.whiteboard.MBeanHolder register: Failure registering
> MBean
> org.apache.aries.jmx.util.shared.RegistrableStandardEmitterMBean@42b86d48
> javax.management.InstanceAlreadyExistsException:
> org.apache.sling.distribution:type=distributionpackage,id="/var/sling/distribution/packages/kryo-cs/data/dstrpck-1479989376714-b79fc9b9-a3e2-4a03-a33c-e87ccd17b8dc"
> at com.sun.jmx.mbeanserver.Repository.addMBean(Repository.java:437)
> at
> com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.registerWithRepository(DefaultMBeanServerInterceptor.java:1898)
> at
> com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.registerDynamicMBean(DefaultMBeanServerInterceptor.java:966)
> at
> com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.registerObject(DefaultMBeanServerInterceptor.java:900)
> at
> com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.registerMBean(DefaultMBeanServerInterceptor.java:324)
> at
> com.sun.jmx.mbeanserver.JmxMBeanServer.registerMBean(JmxMBeanServer.java:522)
> at
> org.apache.aries.jmx.whiteboard.MBeanHolder.register(MBeanHolder.java:114)
> at
> org.apache.aries.jmx.whiteboard.JmxWhiteboardSupport.registerMBean(JmxWhiteboardSupport.java:86)
> at
> org.apache.aries.jmx.whiteboard.Activator$MBeanTracker.addingService(Activator.java:102)
> at
> org.osgi.util.tracker.ServiceTracker$Tracked.customizerAdding(ServiceTracker.java:941)
> at
> org.osgi.util.tracker.ServiceTracker$Tracked.customizerAdding(ServiceTracker.java:870)
> at
> org.osgi.util.tracker.AbstractTracked.trackAdding(AbstractTracked.java:256)
> at org.osgi.util.tracker.AbstractTracked.track(AbstractTracked.java:229)
> at
> org.osgi.util.tracker.ServiceTracker$Tracked.serviceChanged(ServiceTracker.java:901)
> at
> org.apache.felix.framework.util.EventDispatcher.invokeServiceListenerCallback(EventDispatcher.java:991)
> at
> org.apache.felix.framework.util.EventDispatcher.fireEventImmediately(EventDispatcher.java:839)
> at
> org.apache.felix.framework.util.EventDispatcher.fireServiceEvent(EventDispatcher.java:546)
> at org.apache.felix.framework.Felix.fireServiceEvent(Felix.java:4558)
> at org.apache.felix.framework.Felix.registerService(Felix.java:3550)
> at
> org.apache.felix.framework.BundleContextImpl.registerService(BundleContextImpl.java:348)
> at
> org.apache.felix.framework.BundleContextImpl.registerService(BundleContextImpl.java:322)
> at
> org.apache.sling.distribution.monitor.impl.MonitoringDistributionPackageBuilder.registerDistributionPackageMBean(MonitoringDistributionPackageBuilder.java:109)
> at
> org.apache.sling.distribution.monitor.impl.MonitoringDistributionPackageBuilder.getPackage(MonitoringDistributionPackageBuilder.java:81)
> at
> org.apache.sling.distribution.serialization.impl.DistributionPackageBuilderFactory.getPackage(DistributionPackageBuilderFactory.java:222)
> at
> org.apache.sling.distribution.packaging.impl.exporter.LocalDistributionPackageExporter.getPackage(LocalDistributionPackageExporter.java:55)
> at
> org.apache.sling.distribution.agent.impl.SimpleDistributionAgentQueueProcessor.processQueueItem(SimpleDistributionAgentQueueProcessor.java:116)
> at
> org.apache.sling.distribution.agent.impl.SimpleDistributionAgentQueueProcessor.process(SimpleDistributionAgentQueueProcessor.java:84)
> at
> org.apache.sling.distribution.queue.impl.jobhandling.DistributionAgentJobConsumer.process(DistributionAgentJobConsumer.java:48)
>
[jira] [Created] (SLING-6324) MonitoringDistributionPackageBuilder registering of same beans cause exception
Tommaso Teofili created SLING-6324:
--
Summary: MonitoringDistributionPackageBuilder registering of same
beans cause exception
Key: SLING-6324
URL: https://issues.apache.org/jira/browse/SLING-6324
Project: Sling
Issue Type: Bug
Components: Distribution
Reporter: Tommaso Teofili
Fix For: Content Distribution Core 0.1.20
While distributing some content massively I have encountered lots of
stacktraces like below (on sending instance):
{noformat}
24.11.2016 13:09:37.424 *INFO* [127.0.0.1 [1479989377273] POST
/bin/replicate.json HTTP/1.1]
org.apache.sling.distribution.agent.impl.SimpleDistributionAgent
[agent][publish] REQUEST-START DSTRQ2791: ADD
paths=[/content/test10K/node27/subnode90], user=replication-service
24.11.2016 13:09:37.425 *ERROR*
[sling-threadpool-7c966356-fcc8-467b-9d58-eab12551b43c-(apache-sling-job-thread-pool)-2-org_apache_sling_distribution_queue_publish_default(org/apache/sling/distribution/queue/publish/default)]
org.apache.aries.jmx.whiteboard.MBeanHolder register: Failure registering
MBean org.apache.aries.jmx.util.shared.RegistrableStandardEmitterMBean@42b86d48
javax.management.InstanceAlreadyExistsException:
org.apache.sling.distribution:type=distributionpackage,id="/var/sling/distribution/packages/kryo-cs/data/dstrpck-1479989376714-b79fc9b9-a3e2-4a03-a33c-e87ccd17b8dc"
at com.sun.jmx.mbeanserver.Repository.addMBean(Repository.java:437)
at
com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.registerWithRepository(DefaultMBeanServerInterceptor.java:1898)
at
com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.registerDynamicMBean(DefaultMBeanServerInterceptor.java:966)
at
com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.registerObject(DefaultMBeanServerInterceptor.java:900)
at
com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.registerMBean(DefaultMBeanServerInterceptor.java:324)
at
com.sun.jmx.mbeanserver.JmxMBeanServer.registerMBean(JmxMBeanServer.java:522)
at
org.apache.aries.jmx.whiteboard.MBeanHolder.register(MBeanHolder.java:114)
at
org.apache.aries.jmx.whiteboard.JmxWhiteboardSupport.registerMBean(JmxWhiteboardSupport.java:86)
at
org.apache.aries.jmx.whiteboard.Activator$MBeanTracker.addingService(Activator.java:102)
at
org.osgi.util.tracker.ServiceTracker$Tracked.customizerAdding(ServiceTracker.java:941)
at
org.osgi.util.tracker.ServiceTracker$Tracked.customizerAdding(ServiceTracker.java:870)
at
org.osgi.util.tracker.AbstractTracked.trackAdding(AbstractTracked.java:256)
at org.osgi.util.tracker.AbstractTracked.track(AbstractTracked.java:229)
at
org.osgi.util.tracker.ServiceTracker$Tracked.serviceChanged(ServiceTracker.java:901)
at
org.apache.felix.framework.util.EventDispatcher.invokeServiceListenerCallback(EventDispatcher.java:991)
at
org.apache.felix.framework.util.EventDispatcher.fireEventImmediately(EventDispatcher.java:839)
at
org.apache.felix.framework.util.EventDispatcher.fireServiceEvent(EventDispatcher.java:546)
at org.apache.felix.framework.Felix.fireServiceEvent(Felix.java:4558)
at org.apache.felix.framework.Felix.registerService(Felix.java:3550)
at
org.apache.felix.framework.BundleContextImpl.registerService(BundleContextImpl.java:348)
at
org.apache.felix.framework.BundleContextImpl.registerService(BundleContextImpl.java:322)
at
org.apache.sling.distribution.monitor.impl.MonitoringDistributionPackageBuilder.registerDistributionPackageMBean(MonitoringDistributionPackageBuilder.java:109)
at
org.apache.sling.distribution.monitor.impl.MonitoringDistributionPackageBuilder.getPackage(MonitoringDistributionPackageBuilder.java:81)
at
org.apache.sling.distribution.serialization.impl.DistributionPackageBuilderFactory.getPackage(DistributionPackageBuilderFactory.java:222)
at
org.apache.sling.distribution.packaging.impl.exporter.LocalDistributionPackageExporter.getPackage(LocalDistributionPackageExporter.java:55)
at
org.apache.sling.distribution.agent.impl.SimpleDistributionAgentQueueProcessor.processQueueItem(SimpleDistributionAgentQueueProcessor.java:116)
at
org.apache.sling.distribution.agent.impl.SimpleDistributionAgentQueueProcessor.process(SimpleDistributionAgentQueueProcessor.java:84)
at
org.apache.sling.distribution.queue.impl.jobhandling.DistributionAgentJobConsumer.process(DistributionAgentJobConsumer.java:48)
at
org.apache.sling.event.impl.jobs.JobConsumerManager$JobConsumerWrapper.process(JobConsumerManager.java:500)
at
org.apache.sling.event.impl.jobs.queues.JobQueueImpl.startJob(JobQueueImpl.java:291)
at
org.apache.sling.event.impl.jobs.queues.JobQueueImpl.access$100(JobQueueImpl.java:58)
at
[jira] [Resolved] (SLING-6323) Kryo serializer persists resources at the wrong path with depth one resources
[ https://issues.apache.org/jira/browse/SLING-6323?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tommaso Teofili resolved SLING-6323. Resolution: Fixed fixed in r1771120. > Kryo serializer persists resources at the wrong path with depth one resources > - > > Key: SLING-6323 > URL: https://issues.apache.org/jira/browse/SLING-6323 > Project: Sling > Issue Type: Bug > Components: Distribution >Reporter: Tommaso Teofili >Assignee: Tommaso Teofili > Fix For: Content Distribution Extensions 0.1.0 > > > Kryo serializer appends resources wrongly upon deserialization when their > depth (or depth of their parent) is one. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (SLING-6323) Kryo serializer persists resources at the wrong path with depth one resources
Tommaso Teofili created SLING-6323: -- Summary: Kryo serializer persists resources at the wrong path with depth one resources Key: SLING-6323 URL: https://issues.apache.org/jira/browse/SLING-6323 Project: Sling Issue Type: Bug Components: Distribution Reporter: Tommaso Teofili Assignee: Tommaso Teofili Fix For: Content Distribution Extensions 0.1.0 Kryo serializer appends resources wrongly upon deserialization when their depth (or depth of their parent) is one. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (SLING-6322) AvroContentSerializer cannot deserialize packages with multiple resources
[ https://issues.apache.org/jira/browse/SLING-6322?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tommaso Teofili resolved SLING-6322. Resolution: Fixed fixed in r1771119. > AvroContentSerializer cannot deserialize packages with multiple resources > - > > Key: SLING-6322 > URL: https://issues.apache.org/jira/browse/SLING-6322 > Project: Sling > Issue Type: Bug > Components: Distribution >Reporter: Tommaso Teofili >Assignee: Tommaso Teofili > Fix For: Content Distribution Extensions 0.1.0 > > > Avro serializer fails at deserializing / persisting a package which contains > two or more different resources, resulting in persisting only one of them > (the last one). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (SLING-6322) AvroContentSerializer cannot deserialize packages with multiple resources
Tommaso Teofili created SLING-6322: -- Summary: AvroContentSerializer cannot deserialize packages with multiple resources Key: SLING-6322 URL: https://issues.apache.org/jira/browse/SLING-6322 Project: Sling Issue Type: Bug Components: Distribution Reporter: Tommaso Teofili Assignee: Tommaso Teofili Fix For: Content Distribution Extensions 0.1.0 Avro serializer fails at deserializing / persisting a package which contains two or more different resources, resulting in persisting only one of them (the last one). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (SLING-5815) Expose DistributionContentSerializer
[
https://issues.apache.org/jira/browse/SLING-5815?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15689678#comment-15689678
]
Tommaso Teofili commented on SLING-5815:
committed a first version of the exposed API in r1770942.
For now no resource mapping, as it sounds overkill.
> 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, SLING-5815.1.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-6300) Implement monitoring MBeans unit tests
[ https://issues.apache.org/jira/browse/SLING-6300?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tommaso Teofili resolved SLING-6300. Resolution: Fixed Fix Version/s: Content Distribution 0.2.0 thanks Simo, resolving as I've committed your patch. > Implement monitoring MBeans unit tests > -- > > Key: SLING-6300 > URL: https://issues.apache.org/jira/browse/SLING-6300 > Project: Sling > Issue Type: Test > Components: Distribution >Reporter: Simone Tripodi >Assignee: Tommaso Teofili > Fix For: Content Distribution 0.2.0 > > Attachments: SLING-6300.patch > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
