[jira] [Commented] (SLING-12132) Add package message metadata provider SPI
[ https://issues.apache.org/jira/browse/SLING-12132?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17785872#comment-17785872 ] Timothee Maret commented on SLING-12132: The proposed change is not part of any release. > Add package message metadata provider SPI > - > > Key: SLING-12132 > URL: https://issues.apache.org/jira/browse/SLING-12132 > Project: Sling > Issue Type: Task > Components: Content Distribution >Reporter: José Correia >Assignee: Timothee Maret >Priority: Major > Fix For: Content Distribution Journal Messages 0.5.8 > > > We want to add additional metadata to the PackageMessage objects created > during content distribution and that are sent through the Message Provider. > > In order to do this, the distribution journal codebase should provide a > Service Provider Interface that allows for implementing logic that adds > specific metadata for different use-cases. > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (SLING-12132) Add package message metadata provider SPI
[ https://issues.apache.org/jira/browse/SLING-12132?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Timothee Maret resolved SLING-12132. Resolution: Abandoned Abandoned for a SPI at the messaging level. > Add package message metadata provider SPI > - > > Key: SLING-12132 > URL: https://issues.apache.org/jira/browse/SLING-12132 > Project: Sling > Issue Type: Task > Components: Content Distribution >Reporter: José Correia >Assignee: Timothee Maret >Priority: Major > > We want to add additional metadata to the PackageMessage objects created > during content distribution and that are sent through the Message Provider. > > In order to do this, the distribution journal codebase should provide a > Service Provider Interface that allows for implementing logic that adds > specific metadata for different use-cases. > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Reopened] (SLING-12132) Add package message metadata provider SPI
[ https://issues.apache.org/jira/browse/SLING-12132?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Timothee Maret reopened SLING-12132: Reopening following the vote veto in 0.5.8 > Add package message metadata provider SPI > - > > Key: SLING-12132 > URL: https://issues.apache.org/jira/browse/SLING-12132 > Project: Sling > Issue Type: Task > Components: Content Distribution >Reporter: José Correia >Assignee: José Correia >Priority: Major > Fix For: Content Distribution Journal Messages 0.5.8 > > > We want to add additional metadata to the PackageMessage objects created > during content distribution and that are sent through the Message Provider. > > In order to do this, the distribution journal codebase should provide a > Service Provider Interface that allows for implementing logic that adds > specific metadata for different use-cases. > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (SLING-12132) Add package message metadata provider SPI
[ https://issues.apache.org/jira/browse/SLING-12132?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Timothee Maret reassigned SLING-12132: -- Assignee: Timothee Maret (was: José Correia) > Add package message metadata provider SPI > - > > Key: SLING-12132 > URL: https://issues.apache.org/jira/browse/SLING-12132 > Project: Sling > Issue Type: Task > Components: Content Distribution >Reporter: José Correia >Assignee: Timothee Maret >Priority: Major > Fix For: Content Distribution Journal Messages 0.5.8 > > > We want to add additional metadata to the PackageMessage objects created > during content distribution and that are sent through the Message Provider. > > In order to do this, the distribution journal codebase should provide a > Service Provider Interface that allows for implementing logic that adds > specific metadata for different use-cases. > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (SLING-12132) Add SPI for providing PackageMessage metadata
[ https://issues.apache.org/jira/browse/SLING-12132?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Timothee Maret updated SLING-12132: --- Fix Version/s: Content Distribution Journal Messages 0.5.8 > Add SPI for providing PackageMessage metadata > - > > Key: SLING-12132 > URL: https://issues.apache.org/jira/browse/SLING-12132 > Project: Sling > Issue Type: Task > Components: Content Distribution >Reporter: José Correia >Assignee: José Correia >Priority: Major > Fix For: Content Distribution Journal Messages 0.5.8 > > > We want to add additional metadata to the PackageMessage objects created > during content distribution and that are sent through the Message Provider. > > In order to do this, the distribution journal codebase should provide a > Service Provider Interface that allows for implementing logic that adds > specific metadata for different use-cases. > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (SLING-12132) Add SPI for providing PackageMessage metadata
[ https://issues.apache.org/jira/browse/SLING-12132?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Timothee Maret reassigned SLING-12132: -- Assignee: José Correia > Add SPI for providing PackageMessage metadata > - > > Key: SLING-12132 > URL: https://issues.apache.org/jira/browse/SLING-12132 > Project: Sling > Issue Type: Task > Components: Content Distribution >Reporter: José Correia >Assignee: José Correia >Priority: Major > > We want to add additional metadata to the PackageMessage objects created > during content distribution and that are sent through the Message Provider. > > In order to do this, the distribution journal codebase should provide a > Service Provider Interface that allows for implementing logic that adds > specific metadata for different use-cases. > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (SLING-12087) Create SPI for adding metadata to PackageMessages
[ https://issues.apache.org/jira/browse/SLING-12087?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Timothee Maret resolved SLING-12087. Resolution: Fixed > Create SPI for adding metadata to PackageMessages > - > > Key: SLING-12087 > URL: https://issues.apache.org/jira/browse/SLING-12087 > Project: Sling > Issue Type: Task > Components: Content Distribution >Reporter: José Correia >Assignee: José Correia >Priority: Major > Fix For: Content Distribution Journal Messages 0.5.6 > > > We want to add additional metadata to the PackageMessage objects created > during content distribution and that are sent through the Message Provider. > In order to do this, the distribution journal codebase should provide a > Service Provider Interface that allows for implementing logic that adds > specific metadata for different use-cases. > > We will add an additional metadata field to the PackageMessage object. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (SLING-12087) Create SPI for adding metadata to PackageMessages
[ https://issues.apache.org/jira/browse/SLING-12087?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Timothee Maret updated SLING-12087: --- Fix Version/s: Content Distribution Journal Messages 0.5.6 (was: Content Distribution Journal Messages 0.5.4) > Create SPI for adding metadata to PackageMessages > - > > Key: SLING-12087 > URL: https://issues.apache.org/jira/browse/SLING-12087 > Project: Sling > Issue Type: Task > Components: Content Distribution >Reporter: José Correia >Assignee: José Correia >Priority: Major > Fix For: Content Distribution Journal Messages 0.5.6 > > > We want to add additional metadata to the PackageMessage objects created > during content distribution and that are sent through the Message Provider. > In order to do this, the distribution journal codebase should provide a > Service Provider Interface that allows for implementing logic that adds > specific metadata for different use-cases. > > We will add an additional metadata field to the PackageMessage object. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (SLING-12087) Create SPI for adding metadata to PackageMessages
[ https://issues.apache.org/jira/browse/SLING-12087?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Timothee Maret updated SLING-12087: --- Fix Version/s: Content Distribution Journal Messages 0.5.4 > Create SPI for adding metadata to PackageMessages > - > > Key: SLING-12087 > URL: https://issues.apache.org/jira/browse/SLING-12087 > Project: Sling > Issue Type: Task > Components: Content Distribution >Reporter: José Correia >Assignee: José Correia >Priority: Major > Fix For: Content Distribution Journal Messages 0.5.4 > > > We want to add additional metadata to the PackageMessage objects created > during content distribution and that are sent through the Message Provider. > In order to do this, the distribution journal codebase should provide a > Service Provider Interface that allows for implementing logic that adds > specific metadata for different use-cases. > > We will add an additional metadata field to the PackageMessage object. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (SLING-12087) Create SPI for adding metadata to PackageMessages
[ https://issues.apache.org/jira/browse/SLING-12087?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17783532#comment-17783532 ] Timothee Maret commented on SLING-12087: Merged, thank you [~jose-correia] ! > Create SPI for adding metadata to PackageMessages > - > > Key: SLING-12087 > URL: https://issues.apache.org/jira/browse/SLING-12087 > Project: Sling > Issue Type: Task > Components: Content Distribution >Reporter: José Correia >Assignee: José Correia >Priority: Major > > We want to add additional metadata to the PackageMessage objects created > during content distribution and that are sent through the Message Provider. > In order to do this, the distribution journal codebase should provide a > Service Provider Interface that allows for implementing logic that adds > specific metadata for different use-cases. > > We will add an additional metadata field to the PackageMessage object. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (SLING-12087) Create SPI for adding metadata to PackageMessages
[
https://issues.apache.org/jira/browse/SLING-12087?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17773538#comment-17773538
]
Timothee Maret commented on SLING-12087:
[~jose-correia] looking at the PR, I noticed we already have an API to provide
metadata to every messages via the `properties` parameter of the method
{quote}org.apache.sling.distribution.journal.MessageSender#send(T,
java.util.Map)
{quote}
Injecting extra headers can be done in the MessageSender implementation.
> Create SPI for adding metadata to PackageMessages
> -
>
> Key: SLING-12087
> URL: https://issues.apache.org/jira/browse/SLING-12087
> Project: Sling
> Issue Type: Task
> Components: Content Distribution
>Reporter: José Correia
>Assignee: José Correia
>Priority: Major
>
> We want to add additional metadata to the PackageMessage objects created
> during content distribution and that are sent through the Message Provider.
> In order to do this, the distribution journal codebase should provide a
> Service Provider Interface that allows for implementing logic that adds
> specific metadata for different use-cases.
>
> We will add an additional metadata field to the PackageMessage object.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (SLING-12087) Create SPI for adding metadata to PackageMessages
[ https://issues.apache.org/jira/browse/SLING-12087?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17773364#comment-17773364 ] Timothee Maret commented on SLING-12087: It'd make sense to add this SPI in the [https://github.com/apache/sling-org-apache-sling-distribution-journal-messages] bundle. > Create SPI for adding metadata to PackageMessages > - > > Key: SLING-12087 > URL: https://issues.apache.org/jira/browse/SLING-12087 > Project: Sling > Issue Type: Task > Components: Content Distribution >Reporter: José Correia >Assignee: José Correia >Priority: Major > > We want to add additional metadata to the PackageMessage objects created > during content distribution and that are sent through the Message Provider. > In order to do this, the distribution journal codebase should provide a > Service Provider Interface that allows for implementing logic that adds > specific metadata for different use-cases. > > We will add an additional metadata field to the PackageMessage object. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (SLING-12087) Create SPI for adding metadata to PackageMessages
[ https://issues.apache.org/jira/browse/SLING-12087?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Timothee Maret reassigned SLING-12087: -- Assignee: José Correia > Create SPI for adding metadata to PackageMessages > - > > Key: SLING-12087 > URL: https://issues.apache.org/jira/browse/SLING-12087 > Project: Sling > Issue Type: Task > Components: Content Distribution >Reporter: José Correia >Assignee: José Correia >Priority: Major > > We want to add additional metadata to the PackageMessage objects created > during content distribution and that are sent through the Message Provider. > In order to do this, the distribution journal codebase should provide a > Service Provider Interface that allows for implementing logic that adds > specific metadata for different use-cases. > > We will add an additional metadata field to the PackageMessage object. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (SLING-11809) Disable "overwritePrimaryTypesOfFolders" in the distribution journal
[
https://issues.apache.org/jira/browse/SLING-11809?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Timothee Maret resolved SLING-11809.
Fix Version/s: Content Distribution Journal Core 0.1.28
Resolution: Fixed
> Disable "overwritePrimaryTypesOfFolders" in the distribution journal
>
>
> Key: SLING-11809
> URL: https://issues.apache.org/jira/browse/SLING-11809
> Project: Sling
> Issue Type: Bug
> Components: Content Distribution
>Reporter: Roxana-Elena Balasoiu
>Assignee: Timothee Maret
>Priority: Blocker
> Fix For: Content Distribution Journal Core 0.1.28
>
>
> By default, *overwritePrimaryTypesOfFolders* in AEM is set to {*}false{*},
> which conflicts with the value set to *true* in the distribution journal.
> This mismatch can lead to inconsistencies, as observed with some customers.
> To prevent inconsistencies, ensure that the *overwritePrimaryTypesOfFolders*
> value in the distribution journal aligns with the default value of *false* in
> AEM.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (SLING-11809) Disable "overwritePrimaryTypesOfFolders" in the distribution journal
[
https://issues.apache.org/jira/browse/SLING-11809?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17705851#comment-17705851
]
Timothee Maret commented on SLING-11809:
Thank you [~dbanjac] ! Reviewed and merged by [~cschneid]
> Disable "overwritePrimaryTypesOfFolders" in the distribution journal
>
>
> Key: SLING-11809
> URL: https://issues.apache.org/jira/browse/SLING-11809
> Project: Sling
> Issue Type: Bug
> Components: Content Distribution
>Reporter: Roxana-Elena Balasoiu
>Assignee: Timothee Maret
>Priority: Blocker
>
> By default, *overwritePrimaryTypesOfFolders* in AEM is set to {*}false{*},
> which conflicts with the value set to *true* in the distribution journal.
> This mismatch can lead to inconsistencies, as observed with some customers.
> To prevent inconsistencies, ensure that the *overwritePrimaryTypesOfFolders*
> value in the distribution journal aligns with the default value of *false* in
> AEM.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (SLING-11809) Disable "overwritePrimaryTypesOfFolders" in the distribution journal
[
https://issues.apache.org/jira/browse/SLING-11809?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17704535#comment-17704535
]
Timothee Maret commented on SLING-11809:
So, to satisfy everyone we could add a configuration that enables the new FV
behaviour (overwritePrimaryTypesOfFolders = true) by default in Sling.
I suggest to add the property
"contentPackageExtractor.overwritePrimaryTypesOfFolders=true" in
o.a.s.d.j.i.s.DistributionSubscriber. AEM would set that property to false to
enable the old FV behaviour.
[~dbanjac] would you be able to open a new PR with that configuration ?
> Disable "overwritePrimaryTypesOfFolders" in the distribution journal
>
>
> Key: SLING-11809
> URL: https://issues.apache.org/jira/browse/SLING-11809
> Project: Sling
> Issue Type: Bug
> Components: Content Distribution
>Reporter: Roxana-Elena Balasoiu
>Assignee: Timothee Maret
>Priority: Blocker
>
> By default, *overwritePrimaryTypesOfFolders* in AEM is set to {*}false{*},
> which conflicts with the value set to *true* in the distribution journal.
> This mismatch can lead to inconsistencies, as observed with some customers.
> To prevent inconsistencies, ensure that the *overwritePrimaryTypesOfFolders*
> value in the distribution journal aligns with the default value of *false* in
> AEM.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (SLING-11809) Disable "overwritePrimaryTypesOfFolders" in the distribution journal
[
https://issues.apache.org/jira/browse/SLING-11809?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17704216#comment-17704216
]
Timothee Maret commented on SLING-11809:
[~joerghoh] agreed in general, but IINM in this case the proposed changes sets
the behaviour as it was with FV 3.4.0. Arguably Sling users want behavioural
backward compatibility the same way AEM users do.
> Disable "overwritePrimaryTypesOfFolders" in the distribution journal
>
>
> Key: SLING-11809
> URL: https://issues.apache.org/jira/browse/SLING-11809
> Project: Sling
> Issue Type: Bug
> Components: Content Distribution
>Reporter: Roxana-Elena Balasoiu
>Assignee: Timothee Maret
>Priority: Blocker
>
> By default, *overwritePrimaryTypesOfFolders* in AEM is set to {*}false{*},
> which conflicts with the value set to *true* in the distribution journal.
> This mismatch can lead to inconsistencies, as observed with some customers.
> To prevent inconsistencies, ensure that the *overwritePrimaryTypesOfFolders*
> value in the distribution journal aligns with the default value of *false* in
> AEM.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Assigned] (SLING-11809) Disable "overwritePrimaryTypesOfFolders" in the distribution journal
[
https://issues.apache.org/jira/browse/SLING-11809?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Timothee Maret reassigned SLING-11809:
--
Assignee: Timothee Maret
> Disable "overwritePrimaryTypesOfFolders" in the distribution journal
>
>
> Key: SLING-11809
> URL: https://issues.apache.org/jira/browse/SLING-11809
> Project: Sling
> Issue Type: Bug
> Components: Content Distribution
>Reporter: Roxana-Elena Balasoiu
>Assignee: Timothee Maret
>Priority: Blocker
>
> By default, *overwritePrimaryTypesOfFolders* in AEM is set to {*}false{*},
> which conflicts with the value set to *true* in the distribution journal.
> This mismatch can lead to inconsistencies, as observed with some customers.
> To prevent inconsistencies, ensure that the *overwritePrimaryTypesOfFolders*
> value in the distribution journal aligns with the default value of *false* in
> AEM.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (SLING-10107) Refactoring of creation of ResourceResolvers
[
https://issues.apache.org/jira/browse/SLING-10107?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17700150#comment-17700150
]
Timothee Maret commented on SLING-10107:
{quote}Merging these into a single commit wouldn't be a problem, and maybe they
even belong together into a single "transaction".
{quote}
Looking at the LocalStore source code, it seems that resolvers are created in
three methods: store, load, and createParent. The three methods are invoked
from different threads, we can't merge them into a single transaction.
> Refactoring of creation of ResourceResolvers
>
>
> Key: SLING-10107
> URL: https://issues.apache.org/jira/browse/SLING-10107
> Project: Sling
> Issue Type: Improvement
> Components: Content Distribution
>Affects Versions: Content Distribution Journal Core 0.1.16
>Reporter: Joerg Hoh
>Priority: Major
>
> In the 2 classes {{Bookkepper}} and the {{Localstore}} the creation of
> ResourceResolvers is spread over multiple places, and also the number of
> methods, where ResourceResolvers are opened for obviously tiny operations is
> quite high.
> Therefor I refactored the creation of ResourceResolvers for the subservice
> bookkeeper (which is the majority of cases) and centralized the creation of
> it into a central supplier within the {{Bookkeeper}}. I also added a new
> Gauge metric to observe how often a new ResourceResolver is actually created.
> My gut feeling is, that the number of creations is (too) high; but before I
> start combining operations and reduce the number of ResourceResolver
> creations, I would like to understand if it's a problem at all.
> See
> https://github.com/apache/sling-org-apache-sling-distribution-journal/pull/63
> for the PR
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (SLING-11607) Emit metric on the time that a package spends in the journal
[
https://issues.apache.org/jira/browse/SLING-11607?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17612416#comment-17612416
]
Timothee Maret commented on SLING-11607:
Merged
[https://github.com/apache/sling-org-apache-sling-distribution-journal/pull/112,]
thank you!
> Emit metric on the time that a package spends in the journal
>
>
> Key: SLING-11607
> URL: https://issues.apache.org/jira/browse/SLING-11607
> Project: Sling
> Issue Type: Improvement
> Components: Content Distribution
>Reporter: José Correia
>Assignee: José Correia
>Priority: Major
> Fix For: Content Distribution Journal Core 0.1.28
>
> Original Estimate: 4h
> Remaining Estimate: 4h
>
> We should emit a metric that calculates the time in milliseconds that a
> package spends in the journal.
>
> We already have a metric called {{request_distributed_duration}} that tracks
> the time since a package is enqueued until it is successfully imported.
> However, since this timer includes the import of the package content, we are
> not measuring the latency in the journal.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Assigned] (SLING-11607) Emit metric on the time that a package spends in the journal
[
https://issues.apache.org/jira/browse/SLING-11607?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Timothee Maret reassigned SLING-11607:
--
Assignee: José Correia
> Emit metric on the time that a package spends in the journal
>
>
> Key: SLING-11607
> URL: https://issues.apache.org/jira/browse/SLING-11607
> Project: Sling
> Issue Type: Improvement
> Components: Content Distribution
>Reporter: José Correia
>Assignee: José Correia
>Priority: Major
> Fix For: Content Distribution Journal Core 0.1.28
>
> Original Estimate: 4h
> Remaining Estimate: 4h
>
> We should emit a metric that calculates the time in milliseconds that a
> package spends in the journal.
>
> We already have a metric called {{request_distributed_duration}} that tracks
> the time since a package is enqueued until it is successfully imported.
> However, since this timer includes the import of the package content, we are
> not measuring the latency in the journal.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (SLING-11579) Error Distribution queue is not getting created on forward agent creation
[ https://issues.apache.org/jira/browse/SLING-11579?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Timothee Maret resolved SLING-11579. Resolution: Fixed > Error Distribution queue is not getting created on forward agent creation > -- > > Key: SLING-11579 > URL: https://issues.apache.org/jira/browse/SLING-11579 > Project: Sling > Issue Type: Bug >Reporter: Gagan Malpani >Assignee: Timothee Maret >Priority: Critical > Fix For: Content Distribution Core 0.6.0 > > Time Spent: 2h 10m > Remaining Estimate: 0h > > Error Distribution queue is not getting created on forward agent creation > due to mismatch of config variables. > [https://github.com/apache/sling-org-apache-sling-distribution-core/blob/master/src/main/java/org/apache/sling/distribution/agent/impl/ForwardDistributionAgentFactory.java#L94] > RETRY_STRATEGY should be "retry.strategy" > RETRY_ATTEMPTS should be "retry.attempts" > CC: [~mohiaror] -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (SLING-11579) Error Distribution queue is not getting created on forward agent creation
[ https://issues.apache.org/jira/browse/SLING-11579?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Timothee Maret updated SLING-11579: --- Fix Version/s: Content Distribution Core 0.6.0 > Error Distribution queue is not getting created on forward agent creation > -- > > Key: SLING-11579 > URL: https://issues.apache.org/jira/browse/SLING-11579 > Project: Sling > Issue Type: Bug >Reporter: Gagan Malpani >Assignee: Timothee Maret >Priority: Critical > Fix For: Content Distribution Core 0.6.0 > > Time Spent: 2h 10m > Remaining Estimate: 0h > > Error Distribution queue is not getting created on forward agent creation > due to mismatch of config variables. > [https://github.com/apache/sling-org-apache-sling-distribution-core/blob/master/src/main/java/org/apache/sling/distribution/agent/impl/ForwardDistributionAgentFactory.java#L94] > RETRY_STRATEGY should be "retry.strategy" > RETRY_ATTEMPTS should be "retry.attempts" > CC: [~mohiaror] -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (SLING-11579) Error Distribution queue is not getting created on forward agent creation
[ https://issues.apache.org/jira/browse/SLING-11579?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Timothee Maret reassigned SLING-11579: -- Assignee: Timothee Maret > Error Distribution queue is not getting created on forward agent creation > -- > > Key: SLING-11579 > URL: https://issues.apache.org/jira/browse/SLING-11579 > Project: Sling > Issue Type: Bug >Reporter: Gagan Malpani >Assignee: Timothee Maret >Priority: Critical > Time Spent: 2h 10m > Remaining Estimate: 0h > > Error Distribution queue is not getting created on forward agent creation > due to mismatch of config variables. > [https://github.com/apache/sling-org-apache-sling-distribution-core/blob/master/src/main/java/org/apache/sling/distribution/agent/impl/ForwardDistributionAgentFactory.java#L94] > RETRY_STRATEGY should be "retry.strategy" > RETRY_ATTEMPTS should be "retry.attempts" > CC: [~mohiaror] -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (SLING-11579) Error Distribution queue is not getting created on forward agent creation
[ https://issues.apache.org/jira/browse/SLING-11579?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17608257#comment-17608257 ] Timothee Maret commented on SLING-11579: Thank you. This fixes a regression introduced in the big refactoring tracked in SLING-8595. Merged. > Error Distribution queue is not getting created on forward agent creation > -- > > Key: SLING-11579 > URL: https://issues.apache.org/jira/browse/SLING-11579 > Project: Sling > Issue Type: Bug >Reporter: Gagan Malpani >Assignee: Timothee Maret >Priority: Critical > Time Spent: 2h 10m > Remaining Estimate: 0h > > Error Distribution queue is not getting created on forward agent creation > due to mismatch of config variables. > [https://github.com/apache/sling-org-apache-sling-distribution-core/blob/master/src/main/java/org/apache/sling/distribution/agent/impl/ForwardDistributionAgentFactory.java#L94] > RETRY_STRATEGY should be "retry.strategy" > RETRY_ATTEMPTS should be "retry.attempts" > CC: [~mohiaror] -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (SLING-11560) Vault error when importing a node with the same name and UUID as a pre-existing non-sibling node
[
https://issues.apache.org/jira/browse/SLING-11560?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Timothee Maret resolved SLING-11560.
Fix Version/s: Content Distribution Journal Core 0.1.28
Resolution: Fixed
> Vault error when importing a node with the same name and UUID as a
> pre-existing non-sibling node
>
>
> Key: SLING-11560
> URL: https://issues.apache.org/jira/browse/SLING-11560
> Project: Sling
> Issue Type: Bug
> Components: Content Distribution
>Reporter: Manas Kumar Maji
>Assignee: Timothee Maret
>Priority: Major
> Fix For: Content Distribution Journal Core 0.1.28, Content
> Distribution Core 0.4.6
>
> Time Spent: 4h 50m
> Remaining Estimate: 0h
>
> The latest version of _org.apache.jackrabbit.vault_
> (_3.6.1.T20220805092633-0b8a2641_) is throwing an exception when trying to
> install a content package (via SCD), which has a node with the same name and
> UUID as an existing non-sibling node.
> {noformat}
> Caused by: javax.jcr.ReferentialIntegrityException: Node identifier
> Optional[df89c4d9-6d47-480a-af2d-1bffa49bc5d1] already taken by node
> /content/dam/test/SYEW0105.JPG
> at
> org.apache.jackrabbit.vault.fs.impl.io.DocViewImporter.addNode(DocViewImporter.java:862)
> [org.apache.jackrabbit.vault:3.6.1.T20220805092633-0b8a2641]
> at
> org.apache.jackrabbit.vault.fs.impl.io.DocViewImporter.startDocViewNode(DocViewImporter.java:405)
> [org.apache.jackrabbit.vault:3.6.1.T20220805092633-0b8a2641]
> at
> org.apache.jackrabbit.vault.fs.impl.io.DocViewSAXHandler.startElement(DocViewSAXHandler.java:348)
> [org.apache.jackrabbit.vault:3.6.1.T20220805092633-0b8a2641]
> {noformat}
> *Older Behaviour:* In the older version of jackrabbit vault (3.4.6), an new
> UUID would be created for the new node:
> {noformat}
> 17.08.2022 17:37:00.739 *WARN* [qtp1778855870-1811]
> org.apache.jackrabbit.vault.fs.impl.io.DocViewSAXImporter Packaged node at
> /content/dam/hunting/SYEW0105.JPG is referenceable and collides with existing
> node at /content/dam/test/SYEW0105.JPG. Will create new UUID.
> {noformat}
> *Current Behaviour:* From the AEM author logs, it seems that the OSGi config
> having the _IdConflictPolicy.LEGACY_ is not being respected by SCD:
> {noformat}
> 24.08.2022 15:10:45.799 *WARN* [qtp1859723769-86]
> org.apache.jackrabbit.vault.fs.impl.io.DocViewImporter Node Collision: To-be
> imported node /content/dam/hunting/SYEW0105.JPG uses a node identifier
> Optional[df89c4d9-6d47-480a-af2d-1bffa49bc5d1] which is already taken by
> /content/dam/test/SYEW0105.JPG, trying to resolve conflict according to
> policy FAIL
> {noformat}
> *Expected Behaviour:* SCD should take the _IdConflictPolicy_ into
> consideration when installing the content packages. So if
> _IdConflictPolicy.LEGACY_ is set, then a new UUID should be generated for the
> new node.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (SLING-11560) Vault error when importing a node with the same name and UUID as a pre-existing non-sibling node
[
https://issues.apache.org/jira/browse/SLING-11560?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Timothee Maret updated SLING-11560:
---
Fix Version/s: Content Distribution Core 0.6.0
(was: Content Distribution Journal Core 0.1.28)
> Vault error when importing a node with the same name and UUID as a
> pre-existing non-sibling node
>
>
> Key: SLING-11560
> URL: https://issues.apache.org/jira/browse/SLING-11560
> Project: Sling
> Issue Type: Bug
> Components: Content Distribution
>Reporter: Manas Kumar Maji
>Assignee: Timothee Maret
>Priority: Major
> Fix For: Content Distribution Core 0.6.0, Content Distribution
> Core 0.4.6
>
> Time Spent: 4h 50m
> Remaining Estimate: 0h
>
> The latest version of _org.apache.jackrabbit.vault_
> (_3.6.1.T20220805092633-0b8a2641_) is throwing an exception when trying to
> install a content package (via SCD), which has a node with the same name and
> UUID as an existing non-sibling node.
> {noformat}
> Caused by: javax.jcr.ReferentialIntegrityException: Node identifier
> Optional[df89c4d9-6d47-480a-af2d-1bffa49bc5d1] already taken by node
> /content/dam/test/SYEW0105.JPG
> at
> org.apache.jackrabbit.vault.fs.impl.io.DocViewImporter.addNode(DocViewImporter.java:862)
> [org.apache.jackrabbit.vault:3.6.1.T20220805092633-0b8a2641]
> at
> org.apache.jackrabbit.vault.fs.impl.io.DocViewImporter.startDocViewNode(DocViewImporter.java:405)
> [org.apache.jackrabbit.vault:3.6.1.T20220805092633-0b8a2641]
> at
> org.apache.jackrabbit.vault.fs.impl.io.DocViewSAXHandler.startElement(DocViewSAXHandler.java:348)
> [org.apache.jackrabbit.vault:3.6.1.T20220805092633-0b8a2641]
> {noformat}
> *Older Behaviour:* In the older version of jackrabbit vault (3.4.6), an new
> UUID would be created for the new node:
> {noformat}
> 17.08.2022 17:37:00.739 *WARN* [qtp1778855870-1811]
> org.apache.jackrabbit.vault.fs.impl.io.DocViewSAXImporter Packaged node at
> /content/dam/hunting/SYEW0105.JPG is referenceable and collides with existing
> node at /content/dam/test/SYEW0105.JPG. Will create new UUID.
> {noformat}
> *Current Behaviour:* From the AEM author logs, it seems that the OSGi config
> having the _IdConflictPolicy.LEGACY_ is not being respected by SCD:
> {noformat}
> 24.08.2022 15:10:45.799 *WARN* [qtp1859723769-86]
> org.apache.jackrabbit.vault.fs.impl.io.DocViewImporter Node Collision: To-be
> imported node /content/dam/hunting/SYEW0105.JPG uses a node identifier
> Optional[df89c4d9-6d47-480a-af2d-1bffa49bc5d1] which is already taken by
> /content/dam/test/SYEW0105.JPG, trying to resolve conflict according to
> policy FAIL
> {noformat}
> *Expected Behaviour:* SCD should take the _IdConflictPolicy_ into
> consideration when installing the content packages. So if
> _IdConflictPolicy.LEGACY_ is set, then a new UUID should be generated for the
> new node.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (SLING-11560) Vault error when importing a node with the same name and UUID as a pre-existing non-sibling node
[
https://issues.apache.org/jira/browse/SLING-11560?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17608173#comment-17608173
]
Timothee Maret commented on SLING-11560:
Thank you [~manasmaji4] . Squashed and merged
[https://github.com/apache/sling-org-apache-sling-distribution-core/pull/66]
> Vault error when importing a node with the same name and UUID as a
> pre-existing non-sibling node
>
>
> Key: SLING-11560
> URL: https://issues.apache.org/jira/browse/SLING-11560
> Project: Sling
> Issue Type: Bug
> Components: Content Distribution
>Reporter: Manas Kumar Maji
>Assignee: Timothee Maret
>Priority: Major
> Fix For: Content Distribution Core 0.4.6
>
> Time Spent: 4h 50m
> Remaining Estimate: 0h
>
> The latest version of _org.apache.jackrabbit.vault_
> (_3.6.1.T20220805092633-0b8a2641_) is throwing an exception when trying to
> install a content package (via SCD), which has a node with the same name and
> UUID as an existing non-sibling node.
> {noformat}
> Caused by: javax.jcr.ReferentialIntegrityException: Node identifier
> Optional[df89c4d9-6d47-480a-af2d-1bffa49bc5d1] already taken by node
> /content/dam/test/SYEW0105.JPG
> at
> org.apache.jackrabbit.vault.fs.impl.io.DocViewImporter.addNode(DocViewImporter.java:862)
> [org.apache.jackrabbit.vault:3.6.1.T20220805092633-0b8a2641]
> at
> org.apache.jackrabbit.vault.fs.impl.io.DocViewImporter.startDocViewNode(DocViewImporter.java:405)
> [org.apache.jackrabbit.vault:3.6.1.T20220805092633-0b8a2641]
> at
> org.apache.jackrabbit.vault.fs.impl.io.DocViewSAXHandler.startElement(DocViewSAXHandler.java:348)
> [org.apache.jackrabbit.vault:3.6.1.T20220805092633-0b8a2641]
> {noformat}
> *Older Behaviour:* In the older version of jackrabbit vault (3.4.6), an new
> UUID would be created for the new node:
> {noformat}
> 17.08.2022 17:37:00.739 *WARN* [qtp1778855870-1811]
> org.apache.jackrabbit.vault.fs.impl.io.DocViewSAXImporter Packaged node at
> /content/dam/hunting/SYEW0105.JPG is referenceable and collides with existing
> node at /content/dam/test/SYEW0105.JPG. Will create new UUID.
> {noformat}
> *Current Behaviour:* From the AEM author logs, it seems that the OSGi config
> having the _IdConflictPolicy.LEGACY_ is not being respected by SCD:
> {noformat}
> 24.08.2022 15:10:45.799 *WARN* [qtp1859723769-86]
> org.apache.jackrabbit.vault.fs.impl.io.DocViewImporter Node Collision: To-be
> imported node /content/dam/hunting/SYEW0105.JPG uses a node identifier
> Optional[df89c4d9-6d47-480a-af2d-1bffa49bc5d1] which is already taken by
> /content/dam/test/SYEW0105.JPG, trying to resolve conflict according to
> policy FAIL
> {noformat}
> *Expected Behaviour:* SCD should take the _IdConflictPolicy_ into
> consideration when installing the content packages. So if
> _IdConflictPolicy.LEGACY_ is set, then a new UUID should be generated for the
> new node.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (SLING-11560) Vault error when importing a node with the same name and UUID as a pre-existing non-sibling node
[
https://issues.apache.org/jira/browse/SLING-11560?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17607688#comment-17607688
]
Timothee Maret commented on SLING-11560:
PR for journal module
https://github.com/apache/sling-org-apache-sling-distribution-journal/pull/111
> Vault error when importing a node with the same name and UUID as a
> pre-existing non-sibling node
>
>
> Key: SLING-11560
> URL: https://issues.apache.org/jira/browse/SLING-11560
> Project: Sling
> Issue Type: Bug
> Components: Content Distribution
>Reporter: Manas Kumar Maji
>Assignee: Timothee Maret
>Priority: Major
> Fix For: Content Distribution Core 0.4.6
>
> Time Spent: 4h 40m
> Remaining Estimate: 0h
>
> The latest version of _org.apache.jackrabbit.vault_
> (_3.6.1.T20220805092633-0b8a2641_) is throwing an exception when trying to
> install a content package (via SCD), which has a node with the same name and
> UUID as an existing non-sibling node.
> {noformat}
> Caused by: javax.jcr.ReferentialIntegrityException: Node identifier
> Optional[df89c4d9-6d47-480a-af2d-1bffa49bc5d1] already taken by node
> /content/dam/test/SYEW0105.JPG
> at
> org.apache.jackrabbit.vault.fs.impl.io.DocViewImporter.addNode(DocViewImporter.java:862)
> [org.apache.jackrabbit.vault:3.6.1.T20220805092633-0b8a2641]
> at
> org.apache.jackrabbit.vault.fs.impl.io.DocViewImporter.startDocViewNode(DocViewImporter.java:405)
> [org.apache.jackrabbit.vault:3.6.1.T20220805092633-0b8a2641]
> at
> org.apache.jackrabbit.vault.fs.impl.io.DocViewSAXHandler.startElement(DocViewSAXHandler.java:348)
> [org.apache.jackrabbit.vault:3.6.1.T20220805092633-0b8a2641]
> {noformat}
> *Older Behaviour:* In the older version of jackrabbit vault (3.4.6), an new
> UUID would be created for the new node:
> {noformat}
> 17.08.2022 17:37:00.739 *WARN* [qtp1778855870-1811]
> org.apache.jackrabbit.vault.fs.impl.io.DocViewSAXImporter Packaged node at
> /content/dam/hunting/SYEW0105.JPG is referenceable and collides with existing
> node at /content/dam/test/SYEW0105.JPG. Will create new UUID.
> {noformat}
> *Current Behaviour:* From the AEM author logs, it seems that the OSGi config
> having the _IdConflictPolicy.LEGACY_ is not being respected by SCD:
> {noformat}
> 24.08.2022 15:10:45.799 *WARN* [qtp1859723769-86]
> org.apache.jackrabbit.vault.fs.impl.io.DocViewImporter Node Collision: To-be
> imported node /content/dam/hunting/SYEW0105.JPG uses a node identifier
> Optional[df89c4d9-6d47-480a-af2d-1bffa49bc5d1] which is already taken by
> /content/dam/test/SYEW0105.JPG, trying to resolve conflict according to
> policy FAIL
> {noformat}
> *Expected Behaviour:* SCD should take the _IdConflictPolicy_ into
> consideration when installing the content packages. So if
> _IdConflictPolicy.LEGACY_ is set, then a new UUID should be generated for the
> new node.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (SLING-11560) Vault error when importing a node with the same name and UUID as a pre-existing non-sibling node
[
https://issues.apache.org/jira/browse/SLING-11560?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17605332#comment-17605332
]
Timothee Maret commented on SLING-11560:
Makes sense to reuse the existing configuration.
> Vault error when importing a node with the same name and UUID as a
> pre-existing non-sibling node
>
>
> Key: SLING-11560
> URL: https://issues.apache.org/jira/browse/SLING-11560
> Project: Sling
> Issue Type: Bug
> Components: Content Distribution
>Reporter: Manas Kumar Maji
>Assignee: Timothee Maret
>Priority: Major
> Fix For: Content Distribution Core 0.4.6
>
> Time Spent: 50m
> Remaining Estimate: 0h
>
> The latest version of _org.apache.jackrabbit.vault_
> (_3.6.1.T20220805092633-0b8a2641_) is throwing an exception when trying to
> install a content package (via SCD), which has a node with the same name and
> UUID as an existing non-sibling node.
> {noformat}
> Caused by: javax.jcr.ReferentialIntegrityException: Node identifier
> Optional[df89c4d9-6d47-480a-af2d-1bffa49bc5d1] already taken by node
> /content/dam/test/SYEW0105.JPG
> at
> org.apache.jackrabbit.vault.fs.impl.io.DocViewImporter.addNode(DocViewImporter.java:862)
> [org.apache.jackrabbit.vault:3.6.1.T20220805092633-0b8a2641]
> at
> org.apache.jackrabbit.vault.fs.impl.io.DocViewImporter.startDocViewNode(DocViewImporter.java:405)
> [org.apache.jackrabbit.vault:3.6.1.T20220805092633-0b8a2641]
> at
> org.apache.jackrabbit.vault.fs.impl.io.DocViewSAXHandler.startElement(DocViewSAXHandler.java:348)
> [org.apache.jackrabbit.vault:3.6.1.T20220805092633-0b8a2641]
> {noformat}
> *Older Behaviour:* In the older version of jackrabbit vault (3.4.6), an new
> UUID would be created for the new node:
> {noformat}
> 17.08.2022 17:37:00.739 *WARN* [qtp1778855870-1811]
> org.apache.jackrabbit.vault.fs.impl.io.DocViewSAXImporter Packaged node at
> /content/dam/hunting/SYEW0105.JPG is referenceable and collides with existing
> node at /content/dam/test/SYEW0105.JPG. Will create new UUID.
> {noformat}
> *Current Behaviour:* From the AEM author logs, it seems that the OSGi config
> having the _IdConflictPolicy.LEGACY_ is not being respected by SCD:
> {noformat}
> 24.08.2022 15:10:45.799 *WARN* [qtp1859723769-86]
> org.apache.jackrabbit.vault.fs.impl.io.DocViewImporter Node Collision: To-be
> imported node /content/dam/hunting/SYEW0105.JPG uses a node identifier
> Optional[df89c4d9-6d47-480a-af2d-1bffa49bc5d1] which is already taken by
> /content/dam/test/SYEW0105.JPG, trying to resolve conflict according to
> policy FAIL
> {noformat}
> *Expected Behaviour:* SCD should take the _IdConflictPolicy_ into
> consideration when installing the content packages. So if
> _IdConflictPolicy.LEGACY_ is set, then a new UUID should be generated for the
> new node.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (SLING-11582) VaultDistrubtionPackageBuilderFactory mixed up ordering of attribute definition for type
[ https://issues.apache.org/jira/browse/SLING-11582?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17605325#comment-17605325 ] Timothee Maret commented on SLING-11582: That works as well. > VaultDistrubtionPackageBuilderFactory mixed up ordering of attribute > definition for type > > > Key: SLING-11582 > URL: https://issues.apache.org/jira/browse/SLING-11582 > Project: Sling > Issue Type: Bug > Components: Content Distribution >Affects Versions: Content Distribution Journal Core 0.1.26 >Reporter: Ben Helleman >Priority: Major > > The VaultDistributionPackageBuilderFactory's AttributeDefintion [0] for > "type" has the label and values swapped. > The impact is that someone creating an OSGi configuration that uses the value > of "in memory packages" will not have in memory packages created as the > "label" is what is used to check if packages should be created in memory [1]. > The OSGi docs for Option [2] identify the label as being a human readable > string and the value should be the value. > At the same time fix the typo in the ObjectClassDefintion [3] > > [0] > [https://github.com/apache/sling-org-apache-sling-distribution-core/blob/master/src/main/java/org/apache/sling/distribution/serialization/impl/vlt/VaultDistributionPackageBuilderFactory.java#L76-L80] > > [1][https://github.com/apache/sling-org-apache-sling-distribution-core/blob/master/src/main/java/org/apache/sling/distribution/serialization/impl/vlt/VaultDistributionPackageBuilderFactory.java#L241] > [2] > [http://docs.osgi.org/javadoc/r6/cmpn/org/osgi/service/metatype/annotations/Option.html] > > [3] > [https://github.com/apache/sling-org-apache-sling-distribution-core/blob/master/src/main/java/org/apache/sling/distribution/serialization/impl/vlt/VaultDistributionPackageBuilderFactory.java#L71] > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (SLING-11582) VaultDistrubtionPackageBuilderFactory mixed up ordering of attribute definition for type
[ https://issues.apache.org/jira/browse/SLING-11582?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17605167#comment-17605167 ] Timothee Maret commented on SLING-11582: Good catch [~bhellema] . I guess this was not found before because that configuration is typically done via content package or repoinit, not through the console UI. It makes sense to fix it nevertheless. It should be possible to fix it in a backward compatible way. The type conditions should accept both values (e.g. "inmemory" and "in memory packages"). > VaultDistrubtionPackageBuilderFactory mixed up ordering of attribute > definition for type > > > Key: SLING-11582 > URL: https://issues.apache.org/jira/browse/SLING-11582 > Project: Sling > Issue Type: Bug > Components: Content Distribution >Affects Versions: Content Distribution Journal Core 0.1.26 >Reporter: Ben Helleman >Priority: Major > > The VaultDistributionPackageBuilderFactory's AttributeDefintion [0] for > "type" has the label and values swapped. > The impact is that someone creating an OSGi configuration that uses the value > of "in memory packages" will not have in memory packages created as the > "label" is what is used to check if packages should be created in memory [1]. > The OSGi docs for Option [2] identify the label as being a human readable > string and the value should be the value. > At the same time fix the typo in the ObjectClassDefintion [3] > > [0] > [https://github.com/apache/sling-org-apache-sling-distribution-core/blob/master/src/main/java/org/apache/sling/distribution/serialization/impl/vlt/VaultDistributionPackageBuilderFactory.java#L76-L80] > > [1][https://github.com/apache/sling-org-apache-sling-distribution-core/blob/master/src/main/java/org/apache/sling/distribution/serialization/impl/vlt/VaultDistributionPackageBuilderFactory.java#L241] > [2] > [http://docs.osgi.org/javadoc/r6/cmpn/org/osgi/service/metatype/annotations/Option.html] > > [3] > [https://github.com/apache/sling-org-apache-sling-distribution-core/blob/master/src/main/java/org/apache/sling/distribution/serialization/impl/vlt/VaultDistributionPackageBuilderFactory.java#L71] > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (SLING-11560) Vault error when importing a node with the same name and UUID as a pre-existing non-sibling node
[
https://issues.apache.org/jira/browse/SLING-11560?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17601747#comment-17601747
]
Timothee Maret commented on SLING-11560:
[~reschke] [~kwin] Sling Content Distribution [imports content using the
ZipStreamArchive|https://github.com/apache/sling-org-apache-sling-distribution-core/blob/b8acb3a1f6dec7b34431778d4097f1ddf2a0a177/src/main/java/org/apache/sling/distribution/serialization/impl/vlt/FileVaultContentSerializer.java#L129-L179].
Is it using the PackagingImpl under the hood ? If not, we may still need to
set the IdConflictPolicy mode as suggested in this ticket because the
PackagingImpl configuration won't be honoured.
> Vault error when importing a node with the same name and UUID as a
> pre-existing non-sibling node
>
>
> Key: SLING-11560
> URL: https://issues.apache.org/jira/browse/SLING-11560
> Project: Sling
> Issue Type: Bug
> Components: Content Distribution
>Reporter: Manas Kumar Maji
>Assignee: Timothee Maret
>Priority: Major
> Fix For: Content Distribution Core 0.4.6
>
> Time Spent: 50m
> Remaining Estimate: 0h
>
> The latest version of _org.apache.jackrabbit.vault_
> (_3.6.1.T20220805092633-0b8a2641_) is throwing an exception when trying to
> install a content package (via SCD), which has a node with the same name and
> UUID as an existing non-sibling node.
> {noformat}
> Caused by: javax.jcr.ReferentialIntegrityException: Node identifier
> Optional[df89c4d9-6d47-480a-af2d-1bffa49bc5d1] already taken by node
> /content/dam/test/SYEW0105.JPG
> at
> org.apache.jackrabbit.vault.fs.impl.io.DocViewImporter.addNode(DocViewImporter.java:862)
> [org.apache.jackrabbit.vault:3.6.1.T20220805092633-0b8a2641]
> at
> org.apache.jackrabbit.vault.fs.impl.io.DocViewImporter.startDocViewNode(DocViewImporter.java:405)
> [org.apache.jackrabbit.vault:3.6.1.T20220805092633-0b8a2641]
> at
> org.apache.jackrabbit.vault.fs.impl.io.DocViewSAXHandler.startElement(DocViewSAXHandler.java:348)
> [org.apache.jackrabbit.vault:3.6.1.T20220805092633-0b8a2641]
> {noformat}
> *Older Behaviour:* In the older version of jackrabbit vault (3.4.6), an new
> UUID would be created for the new node:
> {noformat}
> 17.08.2022 17:37:00.739 *WARN* [qtp1778855870-1811]
> org.apache.jackrabbit.vault.fs.impl.io.DocViewSAXImporter Packaged node at
> /content/dam/hunting/SYEW0105.JPG is referenceable and collides with existing
> node at /content/dam/test/SYEW0105.JPG. Will create new UUID.
> {noformat}
> *Current Behaviour:* From the AEM author logs, it seems that the OSGi config
> having the _IdConflictPolicy.LEGACY_ is not being respected by SCD:
> {noformat}
> 24.08.2022 15:10:45.799 *WARN* [qtp1859723769-86]
> org.apache.jackrabbit.vault.fs.impl.io.DocViewImporter Node Collision: To-be
> imported node /content/dam/hunting/SYEW0105.JPG uses a node identifier
> Optional[df89c4d9-6d47-480a-af2d-1bffa49bc5d1] which is already taken by
> /content/dam/test/SYEW0105.JPG, trying to resolve conflict according to
> policy FAIL
> {noformat}
> *Expected Behaviour:* SCD should take the _IdConflictPolicy_ into
> consideration when installing the content packages. So if
> _IdConflictPolicy.LEGACY_ is set, then a new UUID should be generated for the
> new node.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (SLING-11560) Vault error when importing a node with the same name and UUID as a pre-existing non-sibling node
[
https://issues.apache.org/jira/browse/SLING-11560?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17600088#comment-17600088
]
Timothee Maret commented on SLING-11560:
[~manasmaji4] could you validate the fix as suggested by [~kwin] ?
> Vault error when importing a node with the same name and UUID as a
> pre-existing non-sibling node
>
>
> Key: SLING-11560
> URL: https://issues.apache.org/jira/browse/SLING-11560
> Project: Sling
> Issue Type: Bug
> Components: Content Distribution
>Reporter: Manas Kumar Maji
>Assignee: Timothee Maret
>Priority: Major
> Fix For: Content Distribution Core 0.4.6
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> The latest version of _org.apache.jackrabbit.vault_
> (_3.6.1.T20220805092633-0b8a2641_) is throwing an exception when trying to
> install a content package (via SCD), which has a node with the same name and
> UUID as an existing non-sibling node.
> {noformat}
> Caused by: javax.jcr.ReferentialIntegrityException: Node identifier
> Optional[df89c4d9-6d47-480a-af2d-1bffa49bc5d1] already taken by node
> /content/dam/test/SYEW0105.JPG
> at
> org.apache.jackrabbit.vault.fs.impl.io.DocViewImporter.addNode(DocViewImporter.java:862)
> [org.apache.jackrabbit.vault:3.6.1.T20220805092633-0b8a2641]
> at
> org.apache.jackrabbit.vault.fs.impl.io.DocViewImporter.startDocViewNode(DocViewImporter.java:405)
> [org.apache.jackrabbit.vault:3.6.1.T20220805092633-0b8a2641]
> at
> org.apache.jackrabbit.vault.fs.impl.io.DocViewSAXHandler.startElement(DocViewSAXHandler.java:348)
> [org.apache.jackrabbit.vault:3.6.1.T20220805092633-0b8a2641]
> {noformat}
> *Older Behaviour:* In the older version of jackrabbit vault (3.4.6), an new
> UUID would be created for the new node:
> {noformat}
> 17.08.2022 17:37:00.739 *WARN* [qtp1778855870-1811]
> org.apache.jackrabbit.vault.fs.impl.io.DocViewSAXImporter Packaged node at
> /content/dam/hunting/SYEW0105.JPG is referenceable and collides with existing
> node at /content/dam/test/SYEW0105.JPG. Will create new UUID.
> {noformat}
> *Current Behaviour:* From the AEM author logs, it seems that the OSGi config
> having the _IdConflictPolicy.LEGACY_ is not being respected by SCD:
> {noformat}
> 24.08.2022 15:10:45.799 *WARN* [qtp1859723769-86]
> org.apache.jackrabbit.vault.fs.impl.io.DocViewImporter Node Collision: To-be
> imported node /content/dam/hunting/SYEW0105.JPG uses a node identifier
> Optional[df89c4d9-6d47-480a-af2d-1bffa49bc5d1] which is already taken by
> /content/dam/test/SYEW0105.JPG, trying to resolve conflict according to
> policy FAIL
> {noformat}
> *Expected Behaviour:* SCD should take the _IdConflictPolicy_ into
> consideration when installing the content packages. So if
> _IdConflictPolicy.LEGACY_ is set, then a new UUID should be generated for the
> new node.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Assigned] (SLING-11560) Vault error when importing a node with the same name and UUID as a pre-existing non-sibling node
[
https://issues.apache.org/jira/browse/SLING-11560?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Timothee Maret reassigned SLING-11560:
--
Assignee: Timothee Maret
> Vault error when importing a node with the same name and UUID as a
> pre-existing non-sibling node
>
>
> Key: SLING-11560
> URL: https://issues.apache.org/jira/browse/SLING-11560
> Project: Sling
> Issue Type: Bug
> Components: Content Distribution
>Reporter: Manas Kumar Maji
>Assignee: Timothee Maret
>Priority: Major
> Fix For: Content Distribution Core 0.4.6
>
>
> The latest version of _org.apache.jackrabbit.vault_
> (_3.6.1.T20220805092633-0b8a2641_) is throwing an exception when trying to
> install a content package (via SCD), which has a node with the same name and
> UUID as an existing non-sibling node.
> {noformat}
> Caused by: javax.jcr.ReferentialIntegrityException: Node identifier
> Optional[df89c4d9-6d47-480a-af2d-1bffa49bc5d1] already taken by node
> /content/dam/test/SYEW0105.JPG
> at
> org.apache.jackrabbit.vault.fs.impl.io.DocViewImporter.addNode(DocViewImporter.java:862)
> [org.apache.jackrabbit.vault:3.6.1.T20220805092633-0b8a2641]
> at
> org.apache.jackrabbit.vault.fs.impl.io.DocViewImporter.startDocViewNode(DocViewImporter.java:405)
> [org.apache.jackrabbit.vault:3.6.1.T20220805092633-0b8a2641]
> at
> org.apache.jackrabbit.vault.fs.impl.io.DocViewSAXHandler.startElement(DocViewSAXHandler.java:348)
> [org.apache.jackrabbit.vault:3.6.1.T20220805092633-0b8a2641]
> {noformat}
> *Older Behaviour:* In the older version of jackrabbit vault (3.4.6), an new
> UUID would be created for the new node:
> {noformat}
> 17.08.2022 17:37:00.739 *WARN* [qtp1778855870-1811]
> org.apache.jackrabbit.vault.fs.impl.io.DocViewSAXImporter Packaged node at
> /content/dam/hunting/SYEW0105.JPG is referenceable and collides with existing
> node at /content/dam/test/SYEW0105.JPG. Will create new UUID.
> {noformat}
> *Current Behaviour:* From the AEM author logs, it seems that the OSGi config
> having the _IdConflictPolicy.LEGACY_ is not being respected by SCD:
> {noformat}
> 24.08.2022 15:10:45.799 *WARN* [qtp1859723769-86]
> org.apache.jackrabbit.vault.fs.impl.io.DocViewImporter Node Collision: To-be
> imported node /content/dam/hunting/SYEW0105.JPG uses a node identifier
> Optional[df89c4d9-6d47-480a-af2d-1bffa49bc5d1] which is already taken by
> /content/dam/test/SYEW0105.JPG, trying to resolve conflict according to
> policy FAIL
> {noformat}
> *Expected Behaviour:* SCD should take the _IdConflictPolicy_ into
> consideration when installing the content packages. So if
> _IdConflictPolicy.LEGACY_ is set, then a new UUID should be generated for the
> new node.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (SLING-11560) Vault error when importing a node with the same name and UUID as a pre-existing non-sibling node
[
https://issues.apache.org/jira/browse/SLING-11560?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17585189#comment-17585189
]
Timothee Maret commented on SLING-11560:
Thank you for reporting [~manasmaji4]. I think we'd need to allow configuring
the IdConflictPolicy and set the default to LEGACY. That way we will ensure
backward compatibility while allowing to test with the new default.
This would need to be done in two bundles
1.
[ContentPackageExtractor|https://github.com/apache/sling-org-apache-sling-distribution-journal/blob/264c4092451fe522d453c69e16ae74c0b4cec53f/src/main/java/org/apache/sling/distribution/journal/bookkeeper/ContentPackageExtractor.java#L116]
2.
[VltUtils|https://github.com/apache/sling-org-apache-sling-distribution-core/blob/1511fb3844f8cb699262cb82e5b920095638587f/src/main/java/org/apache/sling/distribution/serialization/impl/vlt/VltUtils.java#L231]
[~manasmaji4] would like to contribute those changes ?
> Vault error when importing a node with the same name and UUID as a
> pre-existing non-sibling node
>
>
> Key: SLING-11560
> URL: https://issues.apache.org/jira/browse/SLING-11560
> Project: Sling
> Issue Type: Bug
> Components: Content Distribution
>Reporter: Manas Kumar Maji
>Priority: Major
> Fix For: Content Distribution Core 0.4.6
>
>
> The latest version of _org.apache.jackrabbit.vault_
> (_3.6.1.T20220805092633-0b8a2641_) is throwing an exception when trying to
> install a content package (via SCD), which has a node with the same name and
> UUID as an existing non-sibling node.
> {noformat}
> Caused by: javax.jcr.ReferentialIntegrityException: Node identifier
> Optional[df89c4d9-6d47-480a-af2d-1bffa49bc5d1] already taken by node
> /content/dam/test/SYEW0105.JPG
> at
> org.apache.jackrabbit.vault.fs.impl.io.DocViewImporter.addNode(DocViewImporter.java:862)
> [org.apache.jackrabbit.vault:3.6.1.T20220805092633-0b8a2641]
> at
> org.apache.jackrabbit.vault.fs.impl.io.DocViewImporter.startDocViewNode(DocViewImporter.java:405)
> [org.apache.jackrabbit.vault:3.6.1.T20220805092633-0b8a2641]
> at
> org.apache.jackrabbit.vault.fs.impl.io.DocViewSAXHandler.startElement(DocViewSAXHandler.java:348)
> [org.apache.jackrabbit.vault:3.6.1.T20220805092633-0b8a2641]
> {noformat}
> *Older Behaviour:* In the older version of jackrabbit vault (3.4.6), an new
> UUID would be created for the new node:
> {noformat}
> 17.08.2022 17:37:00.739 *WARN* [qtp1778855870-1811]
> org.apache.jackrabbit.vault.fs.impl.io.DocViewSAXImporter Packaged node at
> /content/dam/hunting/SYEW0105.JPG is referenceable and collides with existing
> node at /content/dam/test/SYEW0105.JPG. Will create new UUID.
> {noformat}
> *Current Behaviour:* From the AEM author logs, it seems that the OSGi config
> having the _IdConflictPolicy.LEGACY_ is not being respected by SCD:
> {noformat}
> 24.08.2022 15:10:45.799 *WARN* [qtp1859723769-86]
> org.apache.jackrabbit.vault.fs.impl.io.DocViewImporter Node Collision: To-be
> imported node /content/dam/hunting/SYEW0105.JPG uses a node identifier
> Optional[df89c4d9-6d47-480a-af2d-1bffa49bc5d1] which is already taken by
> /content/dam/test/SYEW0105.JPG, trying to resolve conflict according to
> policy FAIL
> {noformat}
> *Expected Behaviour:* SCD should take the _IdConflictPolicy_ into
> consideration when installing the content packages. So if
> _IdConflictPolicy.LEGACY_ is set, then a new UUID should be generated for the
> new node.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Closed] (SLING-11181) Emit metrics that distinguish transient and permanent distribution failures
[
https://issues.apache.org/jira/browse/SLING-11181?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Timothee Maret closed SLING-11181.
--
> Emit metrics that distinguish transient and permanent distribution failures
> ---
>
> Key: SLING-11181
> URL: https://issues.apache.org/jira/browse/SLING-11181
> Project: Sling
> Issue Type: Improvement
> Components: Content Distribution
>Reporter: José Correia
>Assignee: José Correia
>Priority: Major
> Fix For: Content Distribution Journal Core 0.1.26
>
>
> h3. Context
> Currently, our error metrics don't distinguish between distribution failures
> that are permanent and will fail even if retried, or failures that succeed
> after being retried.
> We want to improve this in order to be able to differentiate both scenarios.
> h3. Solution
> Failure metric should be labeled by:
> * {{Transient failure}}
> * {{Permanent failure}}
> h3. Proposed approach
> We can distinguish both these scenarios by using the following rationale:
> * Transient failures happen whenever a package is distributed successfully
> but had more than 1 attempt at being distributed: {{retries > 0}}
>
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Closed] (SLING-11157) Emit content distribution metrics per action type
[
https://issues.apache.org/jira/browse/SLING-11157?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Timothee Maret closed SLING-11157.
--
> Emit content distribution metrics per action type
> -
>
> Key: SLING-11157
> URL: https://issues.apache.org/jira/browse/SLING-11157
> Project: Sling
> Issue Type: Improvement
> Components: Content Distribution
>Reporter: José Correia
>Assignee: José Correia
>Priority: Major
> Fix For: Content Distribution Journal Core 0.1.26
>
>
> This change is related to the addition of the new {{INVALIDATE}} action to
> create cache invalidation distribution requests, as described in:
> * https://issues.apache.org/jira/browse/SLING-10585
>
> We want to improve the observability of the content distribution requests by
> emitting metrics per action type, which can have the following values:
> * {{ADD}}
> * {{DELETE}}
> * {{INVALIDATE}}
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Closed] (SLING-11255) Update to parent bundle 47
[ https://issues.apache.org/jira/browse/SLING-11255?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Timothee Maret closed SLING-11255. -- > Update to parent bundle 47 > -- > > Key: SLING-11255 > URL: https://issues.apache.org/jira/browse/SLING-11255 > Project: Sling > Issue Type: Improvement > Components: Content Distribution >Reporter: Christian Schneider >Assignee: Joerg Hoh >Priority: Major > Fix For: Content Distribution Sample 0.2.0, Content Distribution > Core 0.6.0, Content Distribution Journal Kafka 0.4.0, Content Distribution > Journal Messages 0.5.0, Content Distribution Journal Messages 0.5.2, Content > Distribution API 0.7.2 > > Time Spent: 20m > Remaining Estimate: 0h > > Remaining distribution bundles with parent < 47: > > ||Bundle||State|| > |org.apache.sling.distribution.it|Captured in SLING-11288| > |org.apache.sling.distribution.journal.it|Captured in SLING-11289| > |org.apache.sling.distribution.sample|done| > |org.apache.sling.distribution.avro-serializer|deprecated| > |org.apache.sling.distribution.kryo-serializer|deprecated| > > -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Commented] (SLING-11289) Update org.apache.sling.distribution.journal.it to latest parent bundle 47
[ https://issues.apache.org/jira/browse/SLING-11289?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17529930#comment-17529930 ] Timothee Maret commented on SLING-11289: Blocked by SLING-11290 > Update org.apache.sling.distribution.journal.it to latest parent bundle 47 > -- > > Key: SLING-11289 > URL: https://issues.apache.org/jira/browse/SLING-11289 > Project: Sling > Issue Type: Task > Components: Content Distribution >Reporter: Timothee Maret >Priority: Major > Fix For: Content Distribution Journal ITs 0.1.4 > > -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Created] (SLING-11290) Content Distribution Journal Kafka module should build Java 8 module
Timothee Maret created SLING-11290:
--
Summary: Content Distribution Journal Kafka module should build
Java 8 module
Key: SLING-11290
URL: https://issues.apache.org/jira/browse/SLING-11290
Project: Sling
Issue Type: Task
Reporter: Timothee Maret
The module compiles to a Java 11 target since this
[commit|https://github.com/apache/sling-org-apache-sling-distribution-journal-kafka/commit/2f9ae2bcdaeeda69acd62621e2991962f018412e]
part of SLING-11037. Java 11 classes are not compatible with the journal.it
module and break the tests with
{code}
[ERROR] Failed to execute goal
org.codehaus.mojo:animal-sniffer-maven-plugin:1.16:check (default) on project
org.apache.sling.distribution.journal.it: Failed to check signatures: failed
to process jar
/Users/tmaret/.m2/repository/org/apache/sling/org.apache.sling.distribution.journal.kafka/0.3.0/org.apache.sling.distribution.journal.kafka-0.3.0.jar
: Bad class file
/Users/tmaret/.m2/repository/org/apache/sling/org.apache.sling.distribution.journal.kafka/0.3.0/org.apache.sling.distribution.journal.kafka-0.3.0.jar:org/apache/sling/distribution/journal/kafka/CLSwitch.class:
IllegalArgumentException -> [Help 1]
{code}
We should either migrate all the Content Distribution bundles to Java 11 or
none. Migrating is a larger effort that should be tracked independently. At
this point, there's no need to use Java 11, so this issue is about compiling to
the default Java version. This will also unblock the effort to update the
journal.it bundle to the latest Sling parent tracked in SLING-11289.
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Comment Edited] (SLING-11255) Update to parent bundle 47
[ https://issues.apache.org/jira/browse/SLING-11255?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17529924#comment-17529924 ] Timothee Maret edited comment on SLING-11255 at 4/29/22 11:38 AM: -- I have captured updating the IT bundles in SLING-11288 and SLING-11289 as they will take more time. [~cschneider] , [~joerghoh] do you see any issue with resolving this issue ? was (Author: marett): I have captured updating the IT bundles in SLING-11288 and SLING-11289 as they will take more time. [~joerghoh] do you see any issue with resolving this issue ? > Update to parent bundle 47 > -- > > Key: SLING-11255 > URL: https://issues.apache.org/jira/browse/SLING-11255 > Project: Sling > Issue Type: Improvement > Components: Content Distribution >Reporter: Christian Schneider >Assignee: Joerg Hoh >Priority: Major > Fix For: Content Distribution Sample 0.2.0, Content Distribution > Core 0.6.0, Content Distribution Journal Kafka 0.4.0, Content Distribution > Journal Messages 0.5.0, Content Distribution Journal Messages 0.5.2, Content > Distribution API 0.7.2 > > Time Spent: 20m > Remaining Estimate: 0h > > Remaining distribution bundles with parent < 47: > > ||Bundle||State|| > |org.apache.sling.distribution.it|Captured in SLING-11288| > |org.apache.sling.distribution.journal.it|Captured in SLING-11289| > |org.apache.sling.distribution.sample|done| > |org.apache.sling.distribution.avro-serializer|deprecated| > |org.apache.sling.distribution.kryo-serializer|deprecated| > > -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Updated] (SLING-11255) Update to parent bundle 47
[ https://issues.apache.org/jira/browse/SLING-11255?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Timothee Maret updated SLING-11255: --- Description: Remaining distribution bundles with parent < 47: ||Bundle||State|| |org.apache.sling.distribution.it|Captured in SLING-11288| |org.apache.sling.distribution.journal.it|Captured in SLING-11289| |org.apache.sling.distribution.sample|done| |org.apache.sling.distribution.avro-serializer|deprecated| |org.apache.sling.distribution.kryo-serializer|deprecated| was: Remaining distribution bundles with parent < 47: ||Bundle||State|| |org.apache.sling.distribution.it|Captured in SLING-11288| |org.apache.sling.distribution.journal.it|Captured in SLING-11289| |org.apache.sling.distribution.sample|done| |org.apache.sling.distribution.avro-serializer|will be deprecated| |org.apache.sling.distribution.kryo-serializer|will be deprecated| > Update to parent bundle 47 > -- > > Key: SLING-11255 > URL: https://issues.apache.org/jira/browse/SLING-11255 > Project: Sling > Issue Type: Improvement > Components: Content Distribution >Reporter: Christian Schneider >Assignee: Joerg Hoh >Priority: Major > Fix For: Content Distribution Sample 0.2.0, Content Distribution > Core 0.6.0, Content Distribution Journal Kafka 0.4.0, Content Distribution > Journal Messages 0.5.0, Content Distribution Journal Messages 0.5.2, Content > Distribution API 0.7.2 > > Time Spent: 20m > Remaining Estimate: 0h > > Remaining distribution bundles with parent < 47: > > ||Bundle||State|| > |org.apache.sling.distribution.it|Captured in SLING-11288| > |org.apache.sling.distribution.journal.it|Captured in SLING-11289| > |org.apache.sling.distribution.sample|done| > |org.apache.sling.distribution.avro-serializer|deprecated| > |org.apache.sling.distribution.kryo-serializer|deprecated| > > -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Commented] (SLING-11255) Update to parent bundle 47
[ https://issues.apache.org/jira/browse/SLING-11255?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17529924#comment-17529924 ] Timothee Maret commented on SLING-11255: I have captured updating the IT bundles in SLING-11288 and SLING-11289 as they will take more time. [~joerghoh] do you see any issue with resolving this issue ? > Update to parent bundle 47 > -- > > Key: SLING-11255 > URL: https://issues.apache.org/jira/browse/SLING-11255 > Project: Sling > Issue Type: Improvement > Components: Content Distribution >Reporter: Christian Schneider >Assignee: Joerg Hoh >Priority: Major > Fix For: Content Distribution Sample 0.2.0, Content Distribution > Core 0.6.0, Content Distribution Journal Kafka 0.4.0, Content Distribution > Journal Messages 0.5.0, Content Distribution Journal Messages 0.5.2, Content > Distribution API 0.7.2 > > Time Spent: 20m > Remaining Estimate: 0h > > Remaining distribution bundles with parent < 47: > > ||Bundle||State|| > |org.apache.sling.distribution.it|Captured in SLING-11288| > |org.apache.sling.distribution.journal.it|Captured in SLING-11289| > |org.apache.sling.distribution.sample|done| > |org.apache.sling.distribution.avro-serializer|will be deprecated| > |org.apache.sling.distribution.kryo-serializer|will be deprecated| > > -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Updated] (SLING-11255) Update to parent bundle 47
[ https://issues.apache.org/jira/browse/SLING-11255?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Timothee Maret updated SLING-11255: --- Description: Remaining distribution bundles with parent < 47: ||Bundle||State|| |org.apache.sling.distribution.it|Captured in SLING-11288| |org.apache.sling.distribution.journal.it|Captured in SLING-11289| |org.apache.sling.distribution.sample|done| |org.apache.sling.distribution.avro-serializer|will be deprecated| |org.apache.sling.distribution.kryo-serializer|will be deprecated| was: Remaining distribution bundles with parent < 47: ||Bundle||State|| |org.apache.sling.distribution.it|to be done| |org.apache.sling.distribution.journal.it|to be done| |org.apache.sling.distribution.sample|done| |org.apache.sling.distribution.avro-serializer|will be deprecated| |org.apache.sling.distribution.kryo-serializer|will be deprecated| > Update to parent bundle 47 > -- > > Key: SLING-11255 > URL: https://issues.apache.org/jira/browse/SLING-11255 > Project: Sling > Issue Type: Improvement > Components: Content Distribution >Reporter: Christian Schneider >Assignee: Joerg Hoh >Priority: Major > Fix For: Content Distribution Sample 0.2.0, Content Distribution > Core 0.6.0, Content Distribution Journal Kafka 0.4.0, Content Distribution > Journal Messages 0.5.2, Content Distribution API 0.7.2 > > Time Spent: 20m > Remaining Estimate: 0h > > Remaining distribution bundles with parent < 47: > > ||Bundle||State|| > |org.apache.sling.distribution.it|Captured in SLING-11288| > |org.apache.sling.distribution.journal.it|Captured in SLING-11289| > |org.apache.sling.distribution.sample|done| > |org.apache.sling.distribution.avro-serializer|will be deprecated| > |org.apache.sling.distribution.kryo-serializer|will be deprecated| > > -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Updated] (SLING-11255) Update to parent bundle 47
[ https://issues.apache.org/jira/browse/SLING-11255?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Timothee Maret updated SLING-11255: --- Fix Version/s: Content Distribution Journal Messages 0.5.0 > Update to parent bundle 47 > -- > > Key: SLING-11255 > URL: https://issues.apache.org/jira/browse/SLING-11255 > Project: Sling > Issue Type: Improvement > Components: Content Distribution >Reporter: Christian Schneider >Assignee: Joerg Hoh >Priority: Major > Fix For: Content Distribution Sample 0.2.0, Content Distribution > Core 0.6.0, Content Distribution Journal Kafka 0.4.0, Content Distribution > Journal Messages 0.5.0, Content Distribution Journal Messages 0.5.2, Content > Distribution API 0.7.2 > > Time Spent: 20m > Remaining Estimate: 0h > > Remaining distribution bundles with parent < 47: > > ||Bundle||State|| > |org.apache.sling.distribution.it|Captured in SLING-11288| > |org.apache.sling.distribution.journal.it|Captured in SLING-11289| > |org.apache.sling.distribution.sample|done| > |org.apache.sling.distribution.avro-serializer|will be deprecated| > |org.apache.sling.distribution.kryo-serializer|will be deprecated| > > -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Updated] (SLING-11289) Update org.apache.sling.distribution.journal.it to latest parent bundle 47
[ https://issues.apache.org/jira/browse/SLING-11289?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Timothee Maret updated SLING-11289: --- Fix Version/s: Content Distribution Journal ITs 0.1.4 > Update org.apache.sling.distribution.journal.it to latest parent bundle 47 > -- > > Key: SLING-11289 > URL: https://issues.apache.org/jira/browse/SLING-11289 > Project: Sling > Issue Type: Task > Components: Content Distribution >Reporter: Timothee Maret >Priority: Major > Fix For: Content Distribution Journal ITs 0.1.4 > > -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Created] (SLING-11289) Update org.apache.sling.distribution.journal.it to latest parent bundle 47
Timothee Maret created SLING-11289: -- Summary: Update org.apache.sling.distribution.journal.it to latest parent bundle 47 Key: SLING-11289 URL: https://issues.apache.org/jira/browse/SLING-11289 Project: Sling Issue Type: Task Components: Content Distribution Reporter: Timothee Maret -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Updated] (SLING-11288) Update org.apache.sling.distribution.it to latest parent bundle 47
[ https://issues.apache.org/jira/browse/SLING-11288?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Timothee Maret updated SLING-11288: --- Fix Version/s: Content Distribution IT 0.1.0 > Update org.apache.sling.distribution.it to latest parent bundle 47 > -- > > Key: SLING-11288 > URL: https://issues.apache.org/jira/browse/SLING-11288 > Project: Sling > Issue Type: Task > Components: Content Distribution >Reporter: Timothee Maret >Priority: Major > Fix For: Content Distribution IT 0.1.0 > > -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Created] (SLING-11288) Update org.apache.sling.distribution.it to latest parent bundle 47
Timothee Maret created SLING-11288: -- Summary: Update org.apache.sling.distribution.it to latest parent bundle 47 Key: SLING-11288 URL: https://issues.apache.org/jira/browse/SLING-11288 Project: Sling Issue Type: Task Components: Content Distribution Reporter: Timothee Maret -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Closed] (SLING-9389) Distribution Event Packages should contain queue item creation time
[ https://issues.apache.org/jira/browse/SLING-9389?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Timothee Maret closed SLING-9389. - > Distribution Event Packages should contain queue item creation time > --- > > Key: SLING-9389 > URL: https://issues.apache.org/jira/browse/SLING-9389 > Project: Sling > Issue Type: Improvement > Components: Content Distribution >Reporter: Harsh Chiki >Assignee: Timothee Maret >Priority: Major > Fix For: Content Distribution Journal Core 0.1.26, Content > Distribution API 0.7.0 > > Attachments: image-2020-04-30-10-28-58-011.png, scdapi.patch, > scdcore.patch > > Time Spent: 2h 10m > Remaining Estimate: 0h > > Currently the Distribution Event package contains the following details: > * Distribution Component Name > * Distribution Component Kind > * Distribution Type > * Distribution Paths > > Improvement aims at adding the queue item creation time, essentially when the > the item was creation for the first time, and enqueue into the queue. The > value does not change over retries (on failure). > > The purpose to get this detail is to be able to capture metrics at the > consumer level. The consumers could have an event handler, which can capture > the duration which turns out to be (NOW MINUS queue item creation time thrown > in the distribution event package); NOW being the current time in the event > handler (consumer). > > \cc: [~shgu...@adobe.com], [~ashishc] -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Closed] (SLING-10585) Add support for invalidation requests
[
https://issues.apache.org/jira/browse/SLING-10585?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Timothee Maret closed SLING-10585.
--
> Add support for invalidation requests
> -
>
> Key: SLING-10585
> URL: https://issues.apache.org/jira/browse/SLING-10585
> Project: Sling
> Issue Type: New Feature
> Components: Content Distribution
>Reporter: Timothee Maret
>Assignee: Roxana-Elena Balasoiu
>Priority: Major
> Fix For: Content Distribution Journal Core 0.1.26, Content
> Distribution Journal Messages 0.5.0, Content Distribution API 0.7.0
>
> Time Spent: 40m
> Remaining Estimate: 0h
>
> Caching invalidation is typically triggered by content distribution, after
> processing an `ADD` or `DELETE` distribution request. When distributing
> referenced content, invalidation must also include on the referencing
> resources. To support this use case, we'll add support for a new type of
> distribution request that invalidates the caches without importing content.
> To support this, the org.apache.sling.distribution.DistributionRequestType
> API will be extended with
> {code:java}
> /**
> * Action type for invalidating content
> */
> INVALIDATE,
> {code}
> The PackageMessage.ReqType will be extended with the new INVALIDATION type.
> The DistributionPublisher will handle the invalidation distribution requests
> by sending a package message with the INVALIDATION type and no payload (like
> the DELETE package messages).
> The DistributionSubscriber will process invalidation messages by raising
> imported events and invoking the import post processors.
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Updated] (SLING-9389) Distribution Event Packages should contain queue item creation time
[ https://issues.apache.org/jira/browse/SLING-9389?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Timothee Maret updated SLING-9389: -- Fix Version/s: Content Distribution API 0.7.0 > Distribution Event Packages should contain queue item creation time > --- > > Key: SLING-9389 > URL: https://issues.apache.org/jira/browse/SLING-9389 > Project: Sling > Issue Type: Improvement > Components: Content Distribution >Reporter: Harsh Chiki >Assignee: Timothee Maret >Priority: Major > Fix For: Content Distribution Journal Core 0.1.26, Content > Distribution API 0.7.0 > > Attachments: image-2020-04-30-10-28-58-011.png, scdapi.patch, > scdcore.patch > > Time Spent: 2h 10m > Remaining Estimate: 0h > > Currently the Distribution Event package contains the following details: > * Distribution Component Name > * Distribution Component Kind > * Distribution Type > * Distribution Paths > > Improvement aims at adding the queue item creation time, essentially when the > the item was creation for the first time, and enqueue into the queue. The > value does not change over retries (on failure). > > The purpose to get this detail is to be able to capture metrics at the > consumer level. The consumers could have an event handler, which can capture > the duration which turns out to be (NOW MINUS queue item creation time thrown > in the distribution event package); NOW being the current time in the event > handler (consumer). > > \cc: [~shgu...@adobe.com], [~ashishc] -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Commented] (SLING-11255) Update to parent bundle 47
[ https://issues.apache.org/jira/browse/SLING-11255?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17529290#comment-17529290 ] Timothee Maret commented on SLING-11255: org.apache.sling.distribution.it and org.apache.sling.distribution.journal.it will require more work. How about capturing those in two Jira tickets? > Update to parent bundle 47 > -- > > Key: SLING-11255 > URL: https://issues.apache.org/jira/browse/SLING-11255 > Project: Sling > Issue Type: Improvement > Components: Content Distribution >Reporter: Christian Schneider >Assignee: Joerg Hoh >Priority: Major > Fix For: Content Distribution Sample 0.2.0, Content Distribution > Core 0.6.0, Content Distribution Journal Kafka 0.4.0, Content Distribution > Journal Messages 0.5.2, Content Distribution API 0.7.2 > > Time Spent: 20m > Remaining Estimate: 0h > > Remaining distribution bundles with parent < 47: > > ||Bundle||State|| > |org.apache.sling.distribution.it|to be done| > |org.apache.sling.distribution.journal.it|to be done| > |org.apache.sling.distribution.sample|done| > |org.apache.sling.distribution.avro-serializer|will be deprecated| > |org.apache.sling.distribution.kryo-serializer|will be deprecated| > > -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Updated] (SLING-11255) Update to parent bundle 47
[ https://issues.apache.org/jira/browse/SLING-11255?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Timothee Maret updated SLING-11255: --- Fix Version/s: Content Distribution Sample 0.2.0 > Update to parent bundle 47 > -- > > Key: SLING-11255 > URL: https://issues.apache.org/jira/browse/SLING-11255 > Project: Sling > Issue Type: Improvement > Components: Content Distribution >Reporter: Christian Schneider >Assignee: Joerg Hoh >Priority: Major > Fix For: Content Distribution Sample 0.2.0, Content Distribution > Core 0.6.0, Content Distribution Journal Kafka 0.4.0, Content Distribution > Journal Messages 0.5.2, Content Distribution API 0.7.2 > > Time Spent: 20m > Remaining Estimate: 0h > -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Commented] (SLING-11255) Update to parent bundle 47
[ https://issues.apache.org/jira/browse/SLING-11255?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17528731#comment-17528731 ] Timothee Maret commented on SLING-11255: [~joerghoh] it seems that all bundles have been updated. Could we resolve this one ? > Update to parent bundle 47 > -- > > Key: SLING-11255 > URL: https://issues.apache.org/jira/browse/SLING-11255 > Project: Sling > Issue Type: Improvement > Components: Content Distribution >Reporter: Christian Schneider >Assignee: Joerg Hoh >Priority: Major > Fix For: Content Distribution Core 0.6.0, Content Distribution > Journal Kafka 0.4.0, Content Distribution Journal Messages 0.5.2, Content > Distribution API 0.7.2 > > -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Updated] (SLING-11255) Update to parent bundle 47
[ https://issues.apache.org/jira/browse/SLING-11255?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Timothee Maret updated SLING-11255: --- Fix Version/s: Content Distribution Journal Kafka 0.4.0 > Update to parent bundle 47 > -- > > Key: SLING-11255 > URL: https://issues.apache.org/jira/browse/SLING-11255 > Project: Sling > Issue Type: Improvement > Components: Content Distribution >Reporter: Christian Schneider >Assignee: Joerg Hoh >Priority: Major > Fix For: Content Distribution Journal Kafka 0.4.0, Content > Distribution Journal Messages 0.5.2, Content Distribution API 0.7.2, Content > Distribution Core 0.6.0 > > -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Commented] (SLING-11255) Update to parent bundle 47
[ https://issues.apache.org/jira/browse/SLING-11255?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17528727#comment-17528727 ] Timothee Maret commented on SLING-11255: Done for the distribution.journal.kafka (and fixed the Jenkins build) > Update to parent bundle 47 > -- > > Key: SLING-11255 > URL: https://issues.apache.org/jira/browse/SLING-11255 > Project: Sling > Issue Type: Improvement > Components: Content Distribution >Reporter: Christian Schneider >Assignee: Joerg Hoh >Priority: Major > Fix For: Content Distribution Journal Messages 0.5.2, Content > Distribution API 0.7.2, Content Distribution Core 0.6.0 > > -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Updated] (SLING-11255) Update to parent bundle 47
[ https://issues.apache.org/jira/browse/SLING-11255?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Timothee Maret updated SLING-11255: --- Fix Version/s: Content Distribution Journal Messages 0.5.2 > Update to parent bundle 47 > -- > > Key: SLING-11255 > URL: https://issues.apache.org/jira/browse/SLING-11255 > Project: Sling > Issue Type: Improvement > Components: Content Distribution >Reporter: Christian Schneider >Assignee: Joerg Hoh >Priority: Major > Fix For: Content Distribution Journal Messages 0.5.2, Content > Distribution API 0.7.2, Content Distribution Core 0.6.0 > > -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Commented] (SLING-11255) Update to parent bundle 47
[ https://issues.apache.org/jira/browse/SLING-11255?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17528719#comment-17528719 ] Timothee Maret commented on SLING-11255: Done for the distribution.journal.messages bundle > Update to parent bundle 47 > -- > > Key: SLING-11255 > URL: https://issues.apache.org/jira/browse/SLING-11255 > Project: Sling > Issue Type: Improvement > Components: Content Distribution >Reporter: Christian Schneider >Assignee: Joerg Hoh >Priority: Major > Fix For: Content Distribution API 0.7.2, Content Distribution > Core 0.6.0 > > -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Commented] (SLING-11255) Update to parent bundle 47
[ https://issues.apache.org/jira/browse/SLING-11255?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17528715#comment-17528715 ] Timothee Maret commented on SLING-11255: Done for the distribution.api bundle in [f44647|https://github.com/apache/sling-org-apache-sling-distribution-api/commit/f44647f05698044f892c1e7b059f25f091c02c0a] > Update to parent bundle 47 > -- > > Key: SLING-11255 > URL: https://issues.apache.org/jira/browse/SLING-11255 > Project: Sling > Issue Type: Improvement > Components: Content Distribution >Reporter: Christian Schneider >Assignee: Joerg Hoh >Priority: Major > Fix For: Content Distribution API 0.7.2, Content Distribution > Core 0.6.0 > > -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Updated] (SLING-11255) Update to parent bundle 47
[ https://issues.apache.org/jira/browse/SLING-11255?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Timothee Maret updated SLING-11255: --- Fix Version/s: Content Distribution API 0.7.2 > Update to parent bundle 47 > -- > > Key: SLING-11255 > URL: https://issues.apache.org/jira/browse/SLING-11255 > Project: Sling > Issue Type: Improvement > Components: Content Distribution >Reporter: Christian Schneider >Assignee: Joerg Hoh >Priority: Major > Fix For: Content Distribution API 0.7.2, Content Distribution > Core 0.6.0 > > -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Resolved] (SLING-9389) Distribution Event Packages should contain queue item creation time
[ https://issues.apache.org/jira/browse/SLING-9389?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Timothee Maret resolved SLING-9389. --- Resolution: Fixed > Distribution Event Packages should contain queue item creation time > --- > > Key: SLING-9389 > URL: https://issues.apache.org/jira/browse/SLING-9389 > Project: Sling > Issue Type: Improvement > Components: Content Distribution >Reporter: Harsh Chiki >Assignee: Timothee Maret >Priority: Major > Fix For: Content Distribution Journal Core 0.1.26 > > Attachments: image-2020-04-30-10-28-58-011.png, scdapi.patch, > scdcore.patch > > Time Spent: 2h 10m > Remaining Estimate: 0h > > Currently the Distribution Event package contains the following details: > * Distribution Component Name > * Distribution Component Kind > * Distribution Type > * Distribution Paths > > Improvement aims at adding the queue item creation time, essentially when the > the item was creation for the first time, and enqueue into the queue. The > value does not change over retries (on failure). > > The purpose to get this detail is to be able to capture metrics at the > consumer level. The consumers could have an event handler, which can capture > the duration which turns out to be (NOW MINUS queue item creation time thrown > in the distribution event package); NOW being the current time in the event > handler (consumer). > > \cc: [~shgu...@adobe.com], [~ashishc] -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Updated] (SLING-9389) Distribution Event Packages should contain queue item creation time
[ https://issues.apache.org/jira/browse/SLING-9389?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Timothee Maret updated SLING-9389: -- Fix Version/s: Content Distribution Journal Core 0.1.26 (was: Content Distribution Journal Core 0.1.28) > Distribution Event Packages should contain queue item creation time > --- > > Key: SLING-9389 > URL: https://issues.apache.org/jira/browse/SLING-9389 > Project: Sling > Issue Type: Improvement > Components: Content Distribution >Reporter: Harsh Chiki >Assignee: Timothee Maret >Priority: Major > Fix For: Content Distribution Journal Core 0.1.26 > > Attachments: image-2020-04-30-10-28-58-011.png, scdapi.patch, > scdcore.patch > > Time Spent: 2h 10m > Remaining Estimate: 0h > > Currently the Distribution Event package contains the following details: > * Distribution Component Name > * Distribution Component Kind > * Distribution Type > * Distribution Paths > > Improvement aims at adding the queue item creation time, essentially when the > the item was creation for the first time, and enqueue into the queue. The > value does not change over retries (on failure). > > The purpose to get this detail is to be able to capture metrics at the > consumer level. The consumers could have an event handler, which can capture > the duration which turns out to be (NOW MINUS queue item creation time thrown > in the distribution event package); NOW being the current time in the event > handler (consumer). > > \cc: [~shgu...@adobe.com], [~ashishc] -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Updated] (SLING-9389) Distribution Event Packages should contain queue item creation time
[ https://issues.apache.org/jira/browse/SLING-9389?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Timothee Maret updated SLING-9389: -- Fix Version/s: Content Distribution Journal Core 0.1.28 > Distribution Event Packages should contain queue item creation time > --- > > Key: SLING-9389 > URL: https://issues.apache.org/jira/browse/SLING-9389 > Project: Sling > Issue Type: Improvement > Components: Content Distribution >Reporter: Harsh Chiki >Assignee: Timothee Maret >Priority: Major > Fix For: Content Distribution Journal Core 0.1.28 > > Attachments: image-2020-04-30-10-28-58-011.png, scdapi.patch, > scdcore.patch > > Time Spent: 2h 10m > Remaining Estimate: 0h > > Currently the Distribution Event package contains the following details: > * Distribution Component Name > * Distribution Component Kind > * Distribution Type > * Distribution Paths > > Improvement aims at adding the queue item creation time, essentially when the > the item was creation for the first time, and enqueue into the queue. The > value does not change over retries (on failure). > > The purpose to get this detail is to be able to capture metrics at the > consumer level. The consumers could have an event handler, which can capture > the duration which turns out to be (NOW MINUS queue item creation time thrown > in the distribution event package); NOW being the current time in the event > handler (consumer). > > \cc: [~shgu...@adobe.com], [~ashishc] -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Resolved] (SLING-11181) Emit metrics that distinguish transient and permanent distribution failures
[
https://issues.apache.org/jira/browse/SLING-11181?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Timothee Maret resolved SLING-11181.
Resolution: Fixed
> Emit metrics that distinguish transient and permanent distribution failures
> ---
>
> Key: SLING-11181
> URL: https://issues.apache.org/jira/browse/SLING-11181
> Project: Sling
> Issue Type: Improvement
> Components: Content Distribution
>Reporter: José Correia
>Assignee: José Correia
>Priority: Major
> Fix For: Content Distribution Journal Core 0.1.26
>
>
> h3. Context
> Currently, our error metrics don't distinguish between distribution failures
> that are permanent and will fail even if retried, or failures that succeed
> after being retried.
> We want to improve this in order to be able to differentiate both scenarios.
> h3. Solution
> Failure metric should be labeled by:
> * {{Transient failure}}
> * {{Permanent failure}}
> h3. Proposed approach
> We can distinguish both these scenarios by using the following rationale:
> * Transient failures happen whenever a package is distributed successfully
> but had more than 1 attempt at being distributed: {{retries > 0}}
>
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Updated] (SLING-9143) RangePoller is not closed when the cache is closed
[ https://issues.apache.org/jira/browse/SLING-9143?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Timothee Maret updated SLING-9143: -- Fix Version/s: Content Distribution Journal Core 0.1.28 (was: Content Distribution Journal Core 0.1.26) > RangePoller is not closed when the cache is closed > -- > > Key: SLING-9143 > URL: https://issues.apache.org/jira/browse/SLING-9143 > Project: Sling > Issue Type: Bug > Components: Content Distribution >Affects Versions: Content Distribution Journal Core 0.1.4 >Reporter: Timothee Maret >Assignee: Timothee Maret >Priority: Minor > Fix For: Content Distribution Journal Core 0.1.28 > > > When the PubQueueCache is closed, the underlying head poller (RangePoller) is > not closed. This issue will only manifest when the cache is closed while an > historical page is being fetched. This scenario is more likely when requests > to the journal are being throttled. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Updated] (SLING-9403) Filter status messages by subscriber agent
[ https://issues.apache.org/jira/browse/SLING-9403?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Timothee Maret updated SLING-9403: -- Fix Version/s: Content Distribution Journal Core 0.1.28 (was: Content Distribution Journal Core 0.1.26) > Filter status messages by subscriber agent > -- > > Key: SLING-9403 > URL: https://issues.apache.org/jira/browse/SLING-9403 > Project: Sling > Issue Type: Bug > Components: Content Distribution >Reporter: Timothee Maret >Assignee: Timothee Maret >Priority: Major > Fix For: Content Distribution Journal Core 0.1.28 > > > Status messages are emit by editable subscriber agents. Multiple editable > agents may exist at the same time, e.g. when replacing services using a > rolling update strategy. Different editable agents may evolve differently and > thus the status messages are not interchangeable. > This issue tracks > 1. Identifying the subscriber agent producing the status messages > 2. Extending the staging precondition to filter by subscriber agent -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Updated] (SLING-9321) Update to declarative services 1.4
[ https://issues.apache.org/jira/browse/SLING-9321?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Timothee Maret updated SLING-9321: -- Fix Version/s: Content Distribution Journal Core 0.1.28 (was: Content Distribution Journal Core 0.1.26) > Update to declarative services 1.4 > -- > > Key: SLING-9321 > URL: https://issues.apache.org/jira/browse/SLING-9321 > Project: Sling > Issue Type: Bug > Components: Content Distribution >Affects Versions: Content Distribution Journal Core 0.1.10 >Reporter: Christian Schneider >Assignee: Christian Schneider >Priority: Major > Fix For: Content Distribution Journal Core 0.1.28 > > -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Updated] (SLING-10614) Document package limits
[ https://issues.apache.org/jira/browse/SLING-10614?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Timothee Maret updated SLING-10614: --- Fix Version/s: Content Distribution Journal Core 0.1.28 (was: Content Distribution Journal Core 0.1.26) > Document package limits > --- > > Key: SLING-10614 > URL: https://issues.apache.org/jira/browse/SLING-10614 > Project: Sling > Issue Type: Task > Components: Content Distribution >Reporter: Timothee Maret >Priority: Major > Fix For: Content Distribution Journal Core 0.1.28 > > > With SLING-10528 we started rejecting packages bigger than 5MB. We should > document this limitation and provide strategies to avoid the limit. > The strategy is to use multi paths distribution requests instead of deep > distributing a single path. Limit to max 100 hierarchical node paths per > distribution request. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Updated] (SLING-9078) Keep skipped offsets in memory
[
https://issues.apache.org/jira/browse/SLING-9078?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Timothee Maret updated SLING-9078:
--
Fix Version/s: Content Distribution Journal Core 0.1.28
(was: Content Distribution Journal Core 0.1.26)
> Keep skipped offsets in memory
> --
>
> Key: SLING-9078
> URL: https://issues.apache.org/jira/browse/SLING-9078
> Project: Sling
> Issue Type: Improvement
> Components: Content Distribution
>Affects Versions: Content Distribution Journal Core 0.1.8
>Reporter: Timothee Maret
>Assignee: Christian Schneider
>Priority: Major
> Fix For: Content Distribution Journal Core 0.1.28
>
>
> In SLING-8908 we introduced a mechanism to keep track of skipped packages
> such that in case of journal availability flip flop, the agents would still
> progress. The implementation was done by persisting the offset in the
> repository. In environments where many skipped packages will occur (e.g.
> large customer with multiple agents) then those commits will start to
> generate a non negligible load on the repository, consuming resources and
> creating bottlenecks.
>
> A first mitigation to this issue has been added in SLING-8965, however for
> very large customers the mitigation will not be effective. Increasing the
> grouping of skipped packages (e.g. 1/100 instead of 1/10) reduce the load on
> the repository but may fail to ensure progress in case of flip/flop.
>
> Instead of storing the skipped packages in the repository, we should keep
> them in memory. A new service that does not reference the
> {{JournalAvailable}} service could be added. The offsets would be
> consolidated on demand from the stored offsets and those stored in memory.
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Updated] (SLING-9065) Incorrect error handling for content distribution if binary is not present in blob store
[ https://issues.apache.org/jira/browse/SLING-9065?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Timothee Maret updated SLING-9065: -- Fix Version/s: Content Distribution Journal Core 0.1.28 (was: Content Distribution Journal Core 0.1.26) > Incorrect error handling for content distribution if binary is not present in > blob store > > > Key: SLING-9065 > URL: https://issues.apache.org/jira/browse/SLING-9065 > Project: Sling > Issue Type: Bug > Components: Content Distribution >Affects Versions: Content Distribution Journal Core 0.1.6 >Reporter: Christian Schneider >Assignee: Christian Schneider >Priority: Major > Fix For: Content Distribution Journal Core 0.1.28 > > > We did a content distribution and the publisher used a different blob store. > So the reference to the binary could not be resolved. > We get a stack trace like below but the ui just shows the queue as running > with 0 retries. So it seems the error is not handled correctly. > [https://gist.github.com/cschneider/c663fa7912b4e643c9d761aa8b70906f] -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Updated] (SLING-8595) Update of sling parent pom
[ https://issues.apache.org/jira/browse/SLING-8595?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Timothee Maret updated SLING-8595: -- Fix Version/s: Content Distribution Journal Core 0.1.28 (was: Content Distribution Journal Core 0.1.26) > Update of sling parent pom > -- > > Key: SLING-8595 > URL: https://issues.apache.org/jira/browse/SLING-8595 > Project: Sling > Issue Type: Sub-task > Components: Content Distribution >Reporter: Christian Schneider >Assignee: Christian Schneider >Priority: Blocker > Fix For: Content Distribution Journal Core 0.1.28 > > Time Spent: 4h > Remaining Estimate: 0h > > When running upstream modules together with sling distribution core in > eclipse I got issues as the outdated osgi core jar slipped into the build > dependencies of the upstream module. > I found that updating the parent pom fixed the issue. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Updated] (SLING-11181) Emit metrics that distinguish transient and permanent distribution failures
[
https://issues.apache.org/jira/browse/SLING-11181?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Timothee Maret updated SLING-11181:
---
Fix Version/s: Content Distribution Journal Core 0.1.26
> Emit metrics that distinguish transient and permanent distribution failures
> ---
>
> Key: SLING-11181
> URL: https://issues.apache.org/jira/browse/SLING-11181
> Project: Sling
> Issue Type: Improvement
> Components: Content Distribution
>Reporter: José Correia
>Assignee: José Correia
>Priority: Major
> Fix For: Content Distribution Journal Core 0.1.26
>
>
> h3. Context
> Currently, our error metrics don't distinguish between distribution failures
> that are permanent and will fail even if retried, or failures that succeed
> after being retried.
> We want to improve this in order to be able to differentiate both scenarios.
> h3. Solution
> Failure metric should be labeled by:
> * {{Transient failure}}
> * {{Permanent failure}}
> h3. Proposed approach
> We can distinguish both these scenarios by using the following rationale:
> * Transient failures happen whenever a package is distributed successfully
> but had more than 1 attempt at being distributed: {{retries > 0}}
>
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Assigned] (SLING-11181) Emit metrics that distinguish transient and permanent distribution failures
[
https://issues.apache.org/jira/browse/SLING-11181?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Timothee Maret reassigned SLING-11181:
--
Assignee: José Correia
> Emit metrics that distinguish transient and permanent distribution failures
> ---
>
> Key: SLING-11181
> URL: https://issues.apache.org/jira/browse/SLING-11181
> Project: Sling
> Issue Type: Improvement
> Components: Content Distribution
>Reporter: José Correia
>Assignee: José Correia
>Priority: Major
>
> h3. Context
> Currently, our error metrics don't distinguish between distribution failures
> that are permanent and will fail even if retried, or failures that succeed
> after being retried.
> We want to improve this in order to be able to differentiate both scenarios.
> h3. Solution
> Failure metric should be labeled by:
> * {{Transient failure}}
> * {{Permanent failure}}
> h3. Proposed approach
> We can distinguish both these scenarios by using the following rationale:
> * Transient failures happen whenever a package is distributed successfully
> but had more than 1 attempt at being distributed: {{retries > 0}}
>
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (SLING-11181) Emit metrics that distinguish transient and permanent distribution failures
[
https://issues.apache.org/jira/browse/SLING-11181?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17518696#comment-17518696
]
Timothee Maret commented on SLING-11181:
Thanks for addressing the comments [~jose-correia]. I have merged your PR #
[105|https://github.com/apache/sling-org-apache-sling-distribution-journal/pull/105]
> Emit metrics that distinguish transient and permanent distribution failures
> ---
>
> Key: SLING-11181
> URL: https://issues.apache.org/jira/browse/SLING-11181
> Project: Sling
> Issue Type: Improvement
> Components: Content Distribution
>Reporter: José Correia
>Priority: Major
>
> h3. Context
> Currently, our error metrics don't distinguish between distribution failures
> that are permanent and will fail even if retried, or failures that succeed
> after being retried.
> We want to improve this in order to be able to differentiate both scenarios.
> h3. Solution
> Failure metric should be labeled by:
> * {{Transient failure}}
> * {{Permanent failure}}
> h3. Proposed approach
> We can distinguish both these scenarios by using the following rationale:
> * Transient failures happen whenever a package is distributed successfully
> but had more than 1 attempt at being distributed: {{retries > 0}}
>
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (SLING-11181) Emit metrics that distinguish transient and permanent distribution failures
[
https://issues.apache.org/jira/browse/SLING-11181?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17517397#comment-17517397
]
Timothee Maret commented on SLING-11181:
Thanks [~jose-correia]! I have added some comments in the PR.
> Emit metrics that distinguish transient and permanent distribution failures
> ---
>
> Key: SLING-11181
> URL: https://issues.apache.org/jira/browse/SLING-11181
> Project: Sling
> Issue Type: Improvement
> Components: Content Distribution
>Reporter: José Correia
>Priority: Major
>
> h3. Context
> Currently, our error metrics don't distinguish between distribution failures
> that are permanent and will fail even if retried, or failures that succeed
> after being retried.
> We want to improve this in order to be able to differentiate both scenarios.
> h3. Solution
> Failure metric should be labeled by:
> * {{Transient failure}}
> * {{Permanent failure}}
> h3. Proposed approach
> We can distinguish both these scenarios by using the following rationale:
> * Transient failures happen whenever a package is distributed successfully
> but had more than 1 attempt at being distributed: {{retries > 0}}
>
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Resolved] (SLING-11157) Emit content distribution metrics per action type
[
https://issues.apache.org/jira/browse/SLING-11157?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Timothee Maret resolved SLING-11157.
Resolution: Fixed
> Emit content distribution metrics per action type
> -
>
> Key: SLING-11157
> URL: https://issues.apache.org/jira/browse/SLING-11157
> Project: Sling
> Issue Type: Improvement
> Components: Content Distribution
>Reporter: José Correia
>Assignee: José Correia
>Priority: Major
> Fix For: Content Distribution Journal Core 0.1.26
>
>
> This change is related to the addition of the new {{INVALIDATE}} action to
> create cache invalidation distribution requests, as described in:
> * https://issues.apache.org/jira/browse/SLING-10585
>
> We want to improve the observability of the content distribution requests by
> emitting metrics per action type, which can have the following values:
> * {{ADD}}
> * {{DELETE}}
> * {{INVALIDATE}}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (SLING-11157) Emit content distribution metrics per action type
[
https://issues.apache.org/jira/browse/SLING-11157?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17515120#comment-17515120
]
Timothee Maret commented on SLING-11157:
Thanks [~jose-correia]! I have merged PR
[#104|https://github.com/apache/sling-org-apache-sling-distribution-journal/pull/104]
> Emit content distribution metrics per action type
> -
>
> Key: SLING-11157
> URL: https://issues.apache.org/jira/browse/SLING-11157
> Project: Sling
> Issue Type: Improvement
> Components: Content Distribution
>Reporter: José Correia
>Assignee: José Correia
>Priority: Major
> Fix For: Content Distribution Journal Core 0.1.26
>
>
> This change is related to the addition of the new {{INVALIDATE}} action to
> create cache invalidation distribution requests, as described in:
> * https://issues.apache.org/jira/browse/SLING-10585
>
> We want to improve the observability of the content distribution requests by
> emitting metrics per action type, which can have the following values:
> * {{ADD}}
> * {{DELETE}}
> * {{INVALIDATE}}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Resolved] (SLING-10585) Add support for invalidation requests
[
https://issues.apache.org/jira/browse/SLING-10585?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Timothee Maret resolved SLING-10585.
Resolution: Fixed
> Add support for invalidation requests
> -
>
> Key: SLING-10585
> URL: https://issues.apache.org/jira/browse/SLING-10585
> Project: Sling
> Issue Type: New Feature
> Components: Content Distribution
>Reporter: Timothee Maret
>Assignee: Roxana-Elena Balasoiu
>Priority: Major
> Fix For: Content Distribution Journal Core 0.1.26, Content
> Distribution API 0.7.0, Content Distribution Journal Messages 0.5.0
>
> Time Spent: 40m
> Remaining Estimate: 0h
>
> Caching invalidation is typically triggered by content distribution, after
> processing an `ADD` or `DELETE` distribution request. When distributing
> referenced content, invalidation must also include on the referencing
> resources. To support this use case, we'll add support for a new type of
> distribution request that invalidates the caches without importing content.
> To support this, the org.apache.sling.distribution.DistributionRequestType
> API will be extended with
> {code:java}
> /**
> * Action type for invalidating content
> */
> INVALIDATE,
> {code}
> The PackageMessage.ReqType will be extended with the new INVALIDATION type.
> The DistributionPublisher will handle the invalidation distribution requests
> by sending a package message with the INVALIDATION type and no payload (like
> the DELETE package messages).
> The DistributionSubscriber will process invalidation messages by raising
> imported events and invoking the import post processors.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Assigned] (SLING-10585) Add support for invalidation requests
[
https://issues.apache.org/jira/browse/SLING-10585?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Timothee Maret reassigned SLING-10585:
--
Assignee: Roxana-Elena Balasoiu (was: Timothee Maret)
> Add support for invalidation requests
> -
>
> Key: SLING-10585
> URL: https://issues.apache.org/jira/browse/SLING-10585
> Project: Sling
> Issue Type: New Feature
> Components: Content Distribution
>Reporter: Timothee Maret
>Assignee: Roxana-Elena Balasoiu
>Priority: Major
> Fix For: Content Distribution Journal Core 0.1.26, Content
> Distribution API 0.7.0, Content Distribution Journal Messages 0.5.0
>
> Time Spent: 40m
> Remaining Estimate: 0h
>
> Caching invalidation is typically triggered by content distribution, after
> processing an `ADD` or `DELETE` distribution request. When distributing
> referenced content, invalidation must also include on the referencing
> resources. To support this use case, we'll add support for a new type of
> distribution request that invalidates the caches without importing content.
> To support this, the org.apache.sling.distribution.DistributionRequestType
> API will be extended with
> {code:java}
> /**
> * Action type for invalidating content
> */
> INVALIDATE,
> {code}
> The PackageMessage.ReqType will be extended with the new INVALIDATION type.
> The DistributionPublisher will handle the invalidation distribution requests
> by sending a package message with the INVALIDATION type and no payload (like
> the DELETE package messages).
> The DistributionSubscriber will process invalidation messages by raising
> imported events and invoking the import post processors.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (SLING-10585) Add support for invalidation requests
[
https://issues.apache.org/jira/browse/SLING-10585?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Timothee Maret updated SLING-10585:
---
Fix Version/s: Content Distribution Journal Messages 0.5.0
> Add support for invalidation requests
> -
>
> Key: SLING-10585
> URL: https://issues.apache.org/jira/browse/SLING-10585
> Project: Sling
> Issue Type: New Feature
> Components: Content Distribution
>Reporter: Timothee Maret
>Assignee: Timothee Maret
>Priority: Major
> Fix For: Content Distribution Journal Core 0.1.26, Content
> Distribution API 0.7.0, Content Distribution Journal Messages 0.5.0
>
> Time Spent: 40m
> Remaining Estimate: 0h
>
> Caching invalidation is typically triggered by content distribution, after
> processing an `ADD` or `DELETE` distribution request. When distributing
> referenced content, invalidation must also include on the referencing
> resources. To support this use case, we'll add support for a new type of
> distribution request that invalidates the caches without importing content.
> To support this, the org.apache.sling.distribution.DistributionRequestType
> API will be extended with
> {code:java}
> /**
> * Action type for invalidating content
> */
> INVALIDATE,
> {code}
> The PackageMessage.ReqType will be extended with the new INVALIDATION type.
> The DistributionPublisher will handle the invalidation distribution requests
> by sending a package message with the INVALIDATION type and no payload (like
> the DELETE package messages).
> The DistributionSubscriber will process invalidation messages by raising
> imported events and invoking the import post processors.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (SLING-10585) Add support for invalidation requests
[
https://issues.apache.org/jira/browse/SLING-10585?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Timothee Maret updated SLING-10585:
---
Fix Version/s: Content Distribution API 0.7.0
> Add support for invalidation requests
> -
>
> Key: SLING-10585
> URL: https://issues.apache.org/jira/browse/SLING-10585
> Project: Sling
> Issue Type: New Feature
> Components: Content Distribution
>Reporter: Timothee Maret
>Assignee: Timothee Maret
>Priority: Major
> Fix For: Content Distribution Journal Core 0.1.26, Content
> Distribution API 0.7.0
>
> Time Spent: 40m
> Remaining Estimate: 0h
>
> Caching invalidation is typically triggered by content distribution, after
> processing an `ADD` or `DELETE` distribution request. When distributing
> referenced content, invalidation must also include on the referencing
> resources. To support this use case, we'll add support for a new type of
> distribution request that invalidates the caches without importing content.
> To support this, the org.apache.sling.distribution.DistributionRequestType
> API will be extended with
> {code:java}
> /**
> * Action type for invalidating content
> */
> INVALIDATE,
> {code}
> The PackageMessage.ReqType will be extended with the new INVALIDATION type.
> The DistributionPublisher will handle the invalidation distribution requests
> by sending a package message with the INVALIDATION type and no payload (like
> the DELETE package messages).
> The DistributionSubscriber will process invalidation messages by raising
> imported events and invoking the import post processors.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (SLING-10585) Add support for invalidation requests
[
https://issues.apache.org/jira/browse/SLING-10585?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17509072#comment-17509072
]
Timothee Maret commented on SLING-10585:
Merged PR
[#101|https://github.com/apache/sling-org-apache-sling-distribution-journal/pull/101],
thank you [~balasoiu]!
> Add support for invalidation requests
> -
>
> Key: SLING-10585
> URL: https://issues.apache.org/jira/browse/SLING-10585
> Project: Sling
> Issue Type: New Feature
> Components: Content Distribution
>Reporter: Timothee Maret
>Assignee: Timothee Maret
>Priority: Major
> Fix For: Content Distribution Journal Core 0.1.26
>
> Time Spent: 40m
> Remaining Estimate: 0h
>
> Caching invalidation is typically triggered by content distribution, after
> processing an `ADD` or `DELETE` distribution request. When distributing
> referenced content, invalidation must also include on the referencing
> resources. To support this use case, we'll add support for a new type of
> distribution request that invalidates the caches without importing content.
> To support this, the org.apache.sling.distribution.DistributionRequestType
> API will be extended with
> {code:java}
> /**
> * Action type for invalidating content
> */
> INVALIDATE,
> {code}
> The PackageMessage.ReqType will be extended with the new INVALIDATION type.
> The DistributionPublisher will handle the invalidation distribution requests
> by sending a package message with the INVALIDATION type and no payload (like
> the DELETE package messages).
> The DistributionSubscriber will process invalidation messages by raising
> imported events and invoking the import post processors.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (SLING-10585) Add support for invalidation requests
[
https://issues.apache.org/jira/browse/SLING-10585?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17508913#comment-17508913
]
Timothee Maret commented on SLING-10585:
Thank you [~balasoiu] !
I have merged PR
[#9|https://github.com/apache/sling-org-apache-sling-distribution-journal-messages/pull/9]
with a twist to avoid the backward incompatible change and merged PR
[#11|https://github.com/apache/sling-org-apache-sling-distribution-api/pull/11].
Please update PR
[#101|https://github.com/apache/sling-org-apache-sling-distribution-journal/pull/101]
to reference the SNAPSHOT version of the distribution-api and journal-messages
modules and adjust to the latest journal-messages.
> Add support for invalidation requests
> -
>
> Key: SLING-10585
> URL: https://issues.apache.org/jira/browse/SLING-10585
> Project: Sling
> Issue Type: New Feature
> Components: Content Distribution
>Reporter: Timothee Maret
>Assignee: Timothee Maret
>Priority: Major
> Fix For: Content Distribution Journal Core 0.1.26
>
> Time Spent: 40m
> Remaining Estimate: 0h
>
> Caching invalidation is typically triggered by content distribution, after
> processing an `ADD` or `DELETE` distribution request. When distributing
> referenced content, invalidation must also include on the referencing
> resources. To support this use case, we'll add support for a new type of
> distribution request that invalidates the caches without importing content.
> To support this, the org.apache.sling.distribution.DistributionRequestType
> API will be extended with
> {code:java}
> /**
> * Action type for invalidating content
> */
> INVALIDATE,
> {code}
> The PackageMessage.ReqType will be extended with the new INVALIDATION type.
> The DistributionPublisher will handle the invalidation distribution requests
> by sending a package message with the INVALIDATION type and no payload (like
> the DELETE package messages).
> The DistributionSubscriber will process invalidation messages by raising
> imported events and invoking the import post processors.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (SLING-7969) Memory leak in DiscoveryLiteDescriptor
[
https://issues.apache.org/jira/browse/SLING-7969?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Timothee Maret updated SLING-7969:
--
Fix Version/s: Discovery Commons 1.0.26
> Memory leak in DiscoveryLiteDescriptor
> --
>
> Key: SLING-7969
> URL: https://issues.apache.org/jira/browse/SLING-7969
> Project: Sling
> Issue Type: Bug
> Components: Discovery
>Affects Versions: Discovery Commons 1.0.20
>Reporter: Timothee Maret
>Assignee: Timothee Maret
>Priority: Major
> Labels: discovery
> Fix For: Discovery Commons 1.0.26
>
> Attachments: Screenshot 2022-03-07 at 1.05.33 PM.png, Screenshot
> 2022-03-07 at 1.14.57 PM-1.png, Screenshot 2022-03-07 at 1.14.57 PM.png,
> Screenshot 2022-03-07 at 1.18.07 PM.png, Screenshot 2022-03-07 at 1.18.16
> PM.png, Screenshot 2022-03-07 at 12.26.11 PM.png,
> org.apache.sling.commons.johnzon-1.1.11-SLING-7969.jar,
> org.apache.sling.discovery.commons-1.0.23-SLING-7969.jar
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> As identified in [~volteanu]'s adaptTo
> [presentation|https://adapt.to/2018/en/schedule/sling-memory-deep-dive.html],
> it seems that Sling Discovery on Oak is consuming 42MB of RAM on a standard
> instance.
> Sling discovery deals with transient states (the views, leases, etc.) and is
> not caching significant amount of data. The 42MB figure for the discovery
> feature seems like a symptom of a memory leak.
> [~volteanu] shared in his presentation that the 42MB worth of RAM was mainly
> consumed by a Json Factory reference. There is one static JsonReaderFactory
> in the discovery commons module, in the
> [DiscoveryLiteDescriptor|https://github.com/apache/sling-org-apache-sling-discovery-commons/blob/master/src/main/java/org/apache/sling/discovery/commons/providers/spi/base/DiscoveryLiteDescriptor.java].
> Looking at the code, it seems that each invocation of the
> [getDescriptorFrom|https://github.com/apache/sling-org-apache-sling-discovery-commons/blob/master/src/main/java/org/apache/sling/discovery/commons/providers/spi/base/DiscoveryLiteDescriptor.java#L51]
> method creates a JSON reader but never close it. This may may leave
> resources behind as hinted by the description of the
> [close|https://docs.oracle.com/javaee/7/api/javax/json/JsonReader.html#close--]
> method in the API. AFAIK, the
> [getDescriptorFrom|https://github.com/apache/sling-org-apache-sling-discovery-commons/blob/master/src/main/java/org/apache/sling/discovery/commons/providers/spi/base/DiscoveryLiteDescriptor.java#L51]
> is invoked periodically on a relatively high frequency (< seconds) which may
> be the trigger for the leak on all instances.
> This is only a supposition for now, it should be investigated further, simply
> by running a patched version of \{{org.apache.sling.discovery.commons}} that
> make sure each JSON reader is properly closed.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Resolved] (SLING-7969) Memory leak in DiscoveryLiteDescriptor
[
https://issues.apache.org/jira/browse/SLING-7969?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Timothee Maret resolved SLING-7969.
---
Resolution: Fixed
> Memory leak in DiscoveryLiteDescriptor
> --
>
> Key: SLING-7969
> URL: https://issues.apache.org/jira/browse/SLING-7969
> Project: Sling
> Issue Type: Bug
> Components: Discovery
>Affects Versions: Discovery Commons 1.0.20
>Reporter: Timothee Maret
>Assignee: Timothee Maret
>Priority: Major
> Labels: discovery
> Fix For: Discovery Commons 1.0.26
>
> Attachments: Screenshot 2022-03-07 at 1.05.33 PM.png, Screenshot
> 2022-03-07 at 1.14.57 PM-1.png, Screenshot 2022-03-07 at 1.14.57 PM.png,
> Screenshot 2022-03-07 at 1.18.07 PM.png, Screenshot 2022-03-07 at 1.18.16
> PM.png, Screenshot 2022-03-07 at 12.26.11 PM.png,
> org.apache.sling.commons.johnzon-1.1.11-SLING-7969.jar,
> org.apache.sling.discovery.commons-1.0.23-SLING-7969.jar
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> As identified in [~volteanu]'s adaptTo
> [presentation|https://adapt.to/2018/en/schedule/sling-memory-deep-dive.html],
> it seems that Sling Discovery on Oak is consuming 42MB of RAM on a standard
> instance.
> Sling discovery deals with transient states (the views, leases, etc.) and is
> not caching significant amount of data. The 42MB figure for the discovery
> feature seems like a symptom of a memory leak.
> [~volteanu] shared in his presentation that the 42MB worth of RAM was mainly
> consumed by a Json Factory reference. There is one static JsonReaderFactory
> in the discovery commons module, in the
> [DiscoveryLiteDescriptor|https://github.com/apache/sling-org-apache-sling-discovery-commons/blob/master/src/main/java/org/apache/sling/discovery/commons/providers/spi/base/DiscoveryLiteDescriptor.java].
> Looking at the code, it seems that each invocation of the
> [getDescriptorFrom|https://github.com/apache/sling-org-apache-sling-discovery-commons/blob/master/src/main/java/org/apache/sling/discovery/commons/providers/spi/base/DiscoveryLiteDescriptor.java#L51]
> method creates a JSON reader but never close it. This may may leave
> resources behind as hinted by the description of the
> [close|https://docs.oracle.com/javaee/7/api/javax/json/JsonReader.html#close--]
> method in the API. AFAIK, the
> [getDescriptorFrom|https://github.com/apache/sling-org-apache-sling-discovery-commons/blob/master/src/main/java/org/apache/sling/discovery/commons/providers/spi/base/DiscoveryLiteDescriptor.java#L51]
> is invoked periodically on a relatively high frequency (< seconds) which may
> be the trigger for the leak on all instances.
> This is only a supposition for now, it should be investigated further, simply
> by running a patched version of \{{org.apache.sling.discovery.commons}} that
> make sure each JSON reader is properly closed.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (SLING-7969) Memory leak in DiscoveryLiteDescriptor
[
https://issues.apache.org/jira/browse/SLING-7969?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17503461#comment-17503461
]
Timothee Maret commented on SLING-7969:
---
Thanks for the review [~stefanegli] . I have merged the PR.
> Memory leak in DiscoveryLiteDescriptor
> --
>
> Key: SLING-7969
> URL: https://issues.apache.org/jira/browse/SLING-7969
> Project: Sling
> Issue Type: Bug
> Components: Discovery
>Affects Versions: Discovery Commons 1.0.20
>Reporter: Timothee Maret
>Assignee: Timothee Maret
>Priority: Major
> Labels: discovery
> Attachments: Screenshot 2022-03-07 at 1.05.33 PM.png, Screenshot
> 2022-03-07 at 1.14.57 PM-1.png, Screenshot 2022-03-07 at 1.14.57 PM.png,
> Screenshot 2022-03-07 at 1.18.07 PM.png, Screenshot 2022-03-07 at 1.18.16
> PM.png, Screenshot 2022-03-07 at 12.26.11 PM.png,
> org.apache.sling.commons.johnzon-1.1.11-SLING-7969.jar,
> org.apache.sling.discovery.commons-1.0.23-SLING-7969.jar
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> As identified in [~volteanu]'s adaptTo
> [presentation|https://adapt.to/2018/en/schedule/sling-memory-deep-dive.html],
> it seems that Sling Discovery on Oak is consuming 42MB of RAM on a standard
> instance.
> Sling discovery deals with transient states (the views, leases, etc.) and is
> not caching significant amount of data. The 42MB figure for the discovery
> feature seems like a symptom of a memory leak.
> [~volteanu] shared in his presentation that the 42MB worth of RAM was mainly
> consumed by a Json Factory reference. There is one static JsonReaderFactory
> in the discovery commons module, in the
> [DiscoveryLiteDescriptor|https://github.com/apache/sling-org-apache-sling-discovery-commons/blob/master/src/main/java/org/apache/sling/discovery/commons/providers/spi/base/DiscoveryLiteDescriptor.java].
> Looking at the code, it seems that each invocation of the
> [getDescriptorFrom|https://github.com/apache/sling-org-apache-sling-discovery-commons/blob/master/src/main/java/org/apache/sling/discovery/commons/providers/spi/base/DiscoveryLiteDescriptor.java#L51]
> method creates a JSON reader but never close it. This may may leave
> resources behind as hinted by the description of the
> [close|https://docs.oracle.com/javaee/7/api/javax/json/JsonReader.html#close--]
> method in the API. AFAIK, the
> [getDescriptorFrom|https://github.com/apache/sling-org-apache-sling-discovery-commons/blob/master/src/main/java/org/apache/sling/discovery/commons/providers/spi/base/DiscoveryLiteDescriptor.java#L51]
> is invoked periodically on a relatively high frequency (< seconds) which may
> be the trigger for the leak on all instances.
> This is only a supposition for now, it should be investigated further, simply
> by running a patched version of \{{org.apache.sling.discovery.commons}} that
> make sure each JSON reader is properly closed.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (SLING-10585) Add support for invalidation requests
[
https://issues.apache.org/jira/browse/SLING-10585?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17502829#comment-17502829
]
Timothee Maret commented on SLING-10585:
Thank you [~balasoiu]! I have reviewed your PRs and left some comments. Once
the PRs
[#11|https://github.com/apache/sling-org-apache-sling-distribution-api/pull/11]
and
[#9|https://github.com/apache/sling-org-apache-sling-distribution-journal-messages/pull/9]
are ready, we could release the corresponding bundles and reference them in PR
[#101|https://github.com/apache/sling-org-apache-sling-distribution-journal/pull/101].
> Add support for invalidation requests
> -
>
> Key: SLING-10585
> URL: https://issues.apache.org/jira/browse/SLING-10585
> Project: Sling
> Issue Type: New Feature
> Components: Content Distribution
>Reporter: Timothee Maret
>Assignee: Timothee Maret
>Priority: Major
> Fix For: Content Distribution Journal Core 0.1.24
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Caching invalidation is typically triggered by content distribution, after
> processing an `ADD` or `DELETE` distribution request. When distributing
> referenced content, invalidation must also include on the referencing
> resources. To support this use case, we'll add support for a new type of
> distribution request that invalidates the caches without importing content.
> To support this, the org.apache.sling.distribution.DistributionRequestType
> API will be extended with
> {code:java}
> /**
> * Action type for invalidating content
> */
> INVALIDATE,
> {code}
> The PackageMessage.ReqType will be extended with the new INVALIDATION type.
> The DistributionPublisher will handle the invalidation distribution requests
> by sending a package message with the INVALIDATION type and no payload (like
> the DELETE package messages).
> The DistributionSubscriber will process invalidation messages by raising
> imported events and invoking the import post processors.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (SLING-7969) Memory leak in DiscoveryLiteDescriptor
[
https://issues.apache.org/jira/browse/SLING-7969?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17502782#comment-17502782
]
Timothee Maret commented on SLING-7969:
---
Thanks [~sagarmiglani] for your analysis. I think that closing the reader makes
sense. [~stefanegli] wdyt ?
I have opened the PR
[#5|https://github.com/apache/sling-org-apache-sling-discovery-commons/pull/5]
with the change.
> Memory leak in DiscoveryLiteDescriptor
> --
>
> Key: SLING-7969
> URL: https://issues.apache.org/jira/browse/SLING-7969
> Project: Sling
> Issue Type: Bug
> Components: Discovery
>Affects Versions: Discovery Commons 1.0.20
>Reporter: Timothee Maret
>Assignee: Timothee Maret
>Priority: Major
> Labels: discovery
> Attachments: Screenshot 2022-03-07 at 1.05.33 PM.png, Screenshot
> 2022-03-07 at 1.14.57 PM-1.png, Screenshot 2022-03-07 at 1.14.57 PM.png,
> Screenshot 2022-03-07 at 1.18.07 PM.png, Screenshot 2022-03-07 at 1.18.16
> PM.png, Screenshot 2022-03-07 at 12.26.11 PM.png,
> org.apache.sling.commons.johnzon-1.1.11-SLING-7969.jar,
> org.apache.sling.discovery.commons-1.0.23-SLING-7969.jar
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> As identified in [~volteanu]'s adaptTo
> [presentation|https://adapt.to/2018/en/schedule/sling-memory-deep-dive.html],
> it seems that Sling Discovery on Oak is consuming 42MB of RAM on a standard
> instance.
> Sling discovery deals with transient states (the views, leases, etc.) and is
> not caching significant amount of data. The 42MB figure for the discovery
> feature seems like a symptom of a memory leak.
> [~volteanu] shared in his presentation that the 42MB worth of RAM was mainly
> consumed by a Json Factory reference. There is one static JsonReaderFactory
> in the discovery commons module, in the
> [DiscoveryLiteDescriptor|https://github.com/apache/sling-org-apache-sling-discovery-commons/blob/master/src/main/java/org/apache/sling/discovery/commons/providers/spi/base/DiscoveryLiteDescriptor.java].
> Looking at the code, it seems that each invocation of the
> [getDescriptorFrom|https://github.com/apache/sling-org-apache-sling-discovery-commons/blob/master/src/main/java/org/apache/sling/discovery/commons/providers/spi/base/DiscoveryLiteDescriptor.java#L51]
> method creates a JSON reader but never close it. This may may leave
> resources behind as hinted by the description of the
> [close|https://docs.oracle.com/javaee/7/api/javax/json/JsonReader.html#close--]
> method in the API. AFAIK, the
> [getDescriptorFrom|https://github.com/apache/sling-org-apache-sling-discovery-commons/blob/master/src/main/java/org/apache/sling/discovery/commons/providers/spi/base/DiscoveryLiteDescriptor.java#L51]
> is invoked periodically on a relatively high frequency (< seconds) which may
> be the trigger for the leak on all instances.
> This is only a supposition for now, it should be investigated further, simply
> by running a patched version of \{{org.apache.sling.discovery.commons}} that
> make sure each JSON reader is properly closed.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Assigned] (SLING-11154) Implement DistributionResponse#getDistributionInfo
[ https://issues.apache.org/jira/browse/SLING-11154?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Timothee Maret reassigned SLING-11154: -- Assignee: Amit Jain (was: Timothee Maret) > Implement DistributionResponse#getDistributionInfo > -- > > Key: SLING-11154 > URL: https://issues.apache.org/jira/browse/SLING-11154 > Project: Sling > Issue Type: Improvement > Components: Content Distribution >Affects Versions: Content Distribution Journal Core 0.1.22, Content > Distribution Core 0.4.8 >Reporter: Amit Jain >Assignee: Amit Jain >Priority: Major > Fix For: Content Distribution Journal Core 0.1.24, Content > Distribution Core 0.4.10 > > > Support the extended API from SLING-11150 -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Assigned] (SLING-10077) Mode to raise events only locally
[
https://issues.apache.org/jira/browse/SLING-10077?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Timothee Maret reassigned SLING-10077:
--
Assignee: Roxana-Elena Balasoiu (was: Timothee Maret)
> Mode to raise events only locally
> -
>
> Key: SLING-10077
> URL: https://issues.apache.org/jira/browse/SLING-10077
> Project: Sling
> Issue Type: Improvement
>Affects Versions: Content Distribution Journal Core 0.1.18
>Reporter: Timothee Maret
>Assignee: Roxana-Elena Balasoiu
>Priority: Major
> Fix For: Content Distribution Journal Core 0.1.24
>
>
> Currently the {{o/a/s/d/a/p/queued}} and {{o/a/s/d/a/p/distributed}} events
> are raised as local events in each author instance of a cluster. Handling
> those events in each author instance makes sense for use cases that require
> maintaining a distributed data structure like a cache. However, some use
> cases like content invalidation, would need to handle the events only once
> (deduplicate events).
> Deduplicating events will be done by leveraging the Sling Discovery API. When
> deduplicating is set, only the leader instance will sent distributed events.
> Prior suggested approach of distributing events through the cluster is not a
> good option because it could overload the repository due to steady and
> frequent commits required to support the distribution of events through the
> cluster.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (SLING-10077) Mode to raise events only locally
[
https://issues.apache.org/jira/browse/SLING-10077?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17498161#comment-17498161
]
Timothee Maret commented on SLING-10077:
[~balasoiu] I have added you as Contributor which should allow you to assign
tickets to yourself from now on.
> Mode to raise events only locally
> -
>
> Key: SLING-10077
> URL: https://issues.apache.org/jira/browse/SLING-10077
> Project: Sling
> Issue Type: Improvement
>Affects Versions: Content Distribution Journal Core 0.1.18
>Reporter: Timothee Maret
>Assignee: Roxana-Elena Balasoiu
>Priority: Major
> Fix For: Content Distribution Journal Core 0.1.24
>
>
> Currently the {{o/a/s/d/a/p/queued}} and {{o/a/s/d/a/p/distributed}} events
> are raised as local events in each author instance of a cluster. Handling
> those events in each author instance makes sense for use cases that require
> maintaining a distributed data structure like a cache. However, some use
> cases like content invalidation, would need to handle the events only once
> (deduplicate events).
> Deduplicating events will be done by leveraging the Sling Discovery API. When
> deduplicating is set, only the leader instance will sent distributed events.
> Prior suggested approach of distributing events through the cluster is not a
> good option because it could overload the repository due to steady and
> frequent commits required to support the distribution of events through the
> cluster.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Assigned] (SLING-10583) Ensure o/a/s/d/a/p/distributed events are raised at least once
[ https://issues.apache.org/jira/browse/SLING-10583?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Timothee Maret reassigned SLING-10583: -- Assignee: Roxana-Elena Balasoiu (was: Timothee Maret) > Ensure o/a/s/d/a/p/distributed events are raised at least once > -- > > Key: SLING-10583 > URL: https://issues.apache.org/jira/browse/SLING-10583 > Project: Sling > Issue Type: Improvement > Components: Content Distribution >Reporter: Timothee Maret >Assignee: Roxana-Elena Balasoiu >Priority: Major > Fix For: Content Distribution Journal Core 0.1.24 > > > The org/apache/sling/distribution/agent/package/distributed events are raised > by computing offset ranges from the discovery topic. Events can be lost in > the edge case where no author service is available to compute offset ranges. > Ensuring event delivery in that case could be done by persisting the offset > of the last event raised and include that information when computing the > events to be raised. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (SLING-11157) Emit content distribution metrics per action type
[
https://issues.apache.org/jira/browse/SLING-11157?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17498160#comment-17498160
]
Timothee Maret commented on SLING-11157:
Ah, thanks [~angela]!
> Emit content distribution metrics per action type
> -
>
> Key: SLING-11157
> URL: https://issues.apache.org/jira/browse/SLING-11157
> Project: Sling
> Issue Type: Improvement
> Components: Content Distribution
>Reporter: José Correia
>Assignee: José Correia
>Priority: Major
> Fix For: Content Distribution Journal Core 0.1.24
>
>
> This change is related to the addition of the new {{INVALIDATE}} action to
> create cache invalidation distribution requests, as described in:
> * https://issues.apache.org/jira/browse/SLING-10585
>
> We want to improve the observability of the content distribution requests by
> emitting metrics per action type, which can have the following values:
> * {{ADD}}
> * {{DELETE}}
> * {{INVALIDATE}}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (SLING-11157) Emit content distribution metrics per action type
[
https://issues.apache.org/jira/browse/SLING-11157?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17498133#comment-17498133
]
Timothee Maret commented on SLING-11157:
Thanks [~jose-correia], I can't assign to you either but I'll review your
contribution.
> Emit content distribution metrics per action type
> -
>
> Key: SLING-11157
> URL: https://issues.apache.org/jira/browse/SLING-11157
> Project: Sling
> Issue Type: Improvement
> Components: Content Distribution
>Reporter: José Correia
>Assignee: Timothee Maret
>Priority: Major
> Fix For: Content Distribution Journal Core 0.1.24
>
>
> This change is related to the addition of the new {{INVALIDATE}} action to
> create cache invalidation distribution requests, as described in:
> * https://issues.apache.org/jira/browse/SLING-10585
>
> We want to improve the observability of the content distribution requests by
> emitting metrics per action type, which can have the following values:
> * {{ADD}}
> * {{DELETE}}
> * {{INVALIDATE}}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Resolved] (SLING-11156) Gave up fetching queue state at PubQueueCache
[ https://issues.apache.org/jira/browse/SLING-11156?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Timothee Maret resolved SLING-11156. Resolution: Fixed Resolving since the PR got merged. > Gave up fetching queue state at PubQueueCache > - > > Key: SLING-11156 > URL: https://issues.apache.org/jira/browse/SLING-11156 > Project: Sling > Issue Type: Bug > Components: Content Distribution >Affects Versions: Content Distribution Journal Core 0.1.22 >Reporter: Christian Schneider >Assignee: Christian Schneider >Priority: Major > Fix For: Content Distribution Journal Core 0.1.24 > > > When we create a RangePoller and it does not find a message with a new enough > offset then it never exits successfully. > — > The proposed solution is to send a test message -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (SLING-11157) Emit content distribution metrics per action type
[
https://issues.apache.org/jira/browse/SLING-11157?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17498001#comment-17498001
]
Timothee Maret commented on SLING-11157:
[~jose-correia] are you working on this one ?
> Emit content distribution metrics per action type
> -
>
> Key: SLING-11157
> URL: https://issues.apache.org/jira/browse/SLING-11157
> Project: Sling
> Issue Type: Improvement
> Components: Content Distribution
>Reporter: José Correia
>Assignee: Timothee Maret
>Priority: Major
> Fix For: Content Distribution Journal Core 0.1.24
>
>
> This change is related to the addition of the new {{INVALIDATE}} action to
> create cache invalidation distribution requests, as described in:
> * https://issues.apache.org/jira/browse/SLING-10585
>
> We want to improve the observability of the content distribution requests by
> emitting metrics per action type, which can have the following values:
> * {{ADD}}
> * {{DELETE}}
> * {{INVALIDATE}}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Assigned] (SLING-11157) Emit content distribution metrics per action type
[
https://issues.apache.org/jira/browse/SLING-11157?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Timothee Maret reassigned SLING-11157:
--
Assignee: Timothee Maret
> Emit content distribution metrics per action type
> -
>
> Key: SLING-11157
> URL: https://issues.apache.org/jira/browse/SLING-11157
> Project: Sling
> Issue Type: Improvement
> Components: Content Distribution
>Reporter: José Correia
>Assignee: Timothee Maret
>Priority: Major
> Fix For: Content Distribution Journal Core 0.1.24
>
>
> This change is related to the addition of the new {{INVALIDATE}} action to
> create cache invalidation distribution requests, as described in:
> * https://issues.apache.org/jira/browse/SLING-10585
>
> We want to improve the observability of the content distribution requests by
> emitting metrics per action type, which can have the following values:
> * {{ADD}}
> * {{DELETE}}
> * {{INVALIDATE}}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (SLING-9143) RangePoller is not closed when the cache is closed
[ https://issues.apache.org/jira/browse/SLING-9143?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Timothee Maret updated SLING-9143: -- Fix Version/s: Content Distribution Journal Core 0.1.26 (was: Content Distribution Journal Core 0.1.24) > RangePoller is not closed when the cache is closed > -- > > Key: SLING-9143 > URL: https://issues.apache.org/jira/browse/SLING-9143 > Project: Sling > Issue Type: Bug > Components: Content Distribution >Affects Versions: Content Distribution Journal Core 0.1.4 >Reporter: Timothee Maret >Assignee: Timothee Maret >Priority: Minor > Fix For: Content Distribution Journal Core 0.1.26 > > > When the PubQueueCache is closed, the underlying head poller (RangePoller) is > not closed. This issue will only manifest when the cache is closed while an > historical page is being fetched. This scenario is more likely when requests > to the journal are being throttled. -- This message was sent by Atlassian Jira (v8.20.1#820001)
