[jira] [Commented] (SLING-2939) 3rd-party based implementation of discovery.api
[ https://issues.apache.org/jira/browse/SLING-2939?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14366785#comment-14366785 ] Philipp Suter commented on SLING-2939: -- [~marett] and [~egli]: It could be worth to investigate https://github.com/kuujo/copycat besides etcd to understand if it could be used to embed a Java based clustering solution that implements Raft. It has some interesting features like active and passive members in a cluster. 3rd-party based implementation of discovery.api --- Key: SLING-2939 URL: https://issues.apache.org/jira/browse/SLING-2939 Project: Sling Issue Type: Task Components: Extensions Affects Versions: Discovery API 1.0.0 Reporter: Stefan Egli Assignee: Stefan Egli The Sling Discovery API introduces the abstraction of a topology which contains (Sling) clusters and instances, supports liveliness-detection, leader-election within a cluster and property-propagation between the instances. As a default and reference implementation a resource-based, OOTB implementation was created (org.apache.sling.discovery.impl). Pros and cons of the discovery.impl Although the discovery.impl supports everything required in discovery.api, it has a few limitations. Here's a list of pros and cons: Pros No additional software required (leverages repository for intra-cluster communication/storage and HTTP-REST calls for cross-cluster communication) Very small footprint Perfectly suited for a single clusters, instance and for small, rather stable hub-based topologies Cons Config-/deployment-limitations (aka embedded-limitation): connections between clusters are peer-to-peer and explicit. To span a topology, a number of instances must (be made) know (to) each other, changes in the topology typically requires config adjustments to guarantee high availability of the discovery service Except if a natural hub cluster exists that can serve as connection point for all satellite clusters Other than that, it is less suited for large and/or dynamic topologies Change propagation (for topology parts reported via connectors) is non-atomic and slow, hop-by-hop based No guarantee on order of TopologyEvents sent in individual instances - ie different instances might see different orders of TopologyEvents (ie changes in the topology) but eventually the topology is guaranteed to be consistent Robustness of discovery.impl wrt storm situations depends on robustness of underlying cluster (not a real negative but discovery.impl might in theory unveil repository bugs which would otherwise not have been a problem) Rather new, little tested code which might have issues with edge cases wrt network problems although partitioning-support is not a requirement per se, similar edge-cases might exist wrt network-delays/timing/crashes Reusing a suitable 3rd party library To provide an additional option as implementation of the discovery.api one idea is to use a suitable 3rd party library. Requirements The following is a list of requirements a 3rd party library must support: liveliness detection: detect whether an instance is up and running stable leader election within a cluster: stable describes the fact that a leader will remain leader until it leaves/crashes and no new, joining instance shall take over while a leader exists stable instance ordering: the list of instances within a cluster is ordered and stable, new, joining instances are put at the end of the list property propagation: propagate the properties provided within one instance to everybody in the topology. there are no timing requirements bound to this but the intention of this is not to be used as messaging but to announce config parameters to the topology support large, dynamic clusters: configuration of the new discovery implementation should be easy and support frequent changes in the (large) topology no single point of failure: this is obvious, there should of course be no single point of failure in the setup embedded or dedicated: this might be a hot topic: embedding a library has the advantages of not having to install anything additional. a dedicated service on the other hand requires additional handling in deployment. embedding implies a peer-to-peer setup: nodes communicate peer-to-peer rather than via a centralized service. this IMHO is a negative for large topologies which would typically be cross data-centers. hence a dedicated service could be seen as an advantage in the end. due to need for cross data-center deployments, the transport protocol must be TCP (or HTTP for that matter) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (SLING-4500) using Sling mocks throws NullPointerException when checking the resourceType of the root node
[ https://issues.apache.org/jira/browse/SLING-4500?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] santiago garcía pimentel updated SLING-4500: Summary: using Sling mocks throws NullPointerException when checking the resourceType of the root node (was: Missing primary type in the root node, when using the mocked resource resolver) using Sling mocks throws NullPointerException when checking the resourceType of the root node - Key: SLING-4500 URL: https://issues.apache.org/jira/browse/SLING-4500 Project: Sling Issue Type: Bug Components: Testing Reporter: santiago garcía pimentel Priority: Minor when using the Mocked ResourceResolver (org.apache.sling.testing.resourceresolver.MockResourceResolver), the root node does not have a primary type, this causes that something like Resource root= resourceResolver.getResource(/); root.isResourceType(app/resourceType); will throw a NPE, since the node does not have either resourceType or primary type. Instead, the root node should have a primary type. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (SLING-4359) LargeTopologyWithHubTest.testLargeTopologyWithHub test failure
[
https://issues.apache.org/jira/browse/SLING-4359?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Egli updated SLING-4359:
---
Fix Version/s: (was: Discovery Impl 1.1.0)
Discovery Impl 1.1.2
LargeTopologyWithHubTest.testLargeTopologyWithHub test failure
--
Key: SLING-4359
URL: https://issues.apache.org/jira/browse/SLING-4359
Project: Sling
Issue Type: Bug
Components: Extensions
Affects Versions: Discovery Impl 1.0.12
Reporter: Stefan Egli
Assignee: Stefan Egli
Fix For: Discovery Impl 1.1.2
https://builds.apache.org/job/sling-trunk-1.7/org.apache.sling$org.apache.sling.discovery.impl/1376/testReport/org.apache.sling.discovery.impl.topology/LargeTopologyWithHubTest/testLargeTopologyWithHub/
{code}
java.lang.AssertionError: expected:101 but was:43
at org.junit.Assert.fail(Assert.java:88)
at org.junit.Assert.failNotEquals(Assert.java:743)
at org.junit.Assert.assertEquals(Assert.java:118)
at org.junit.Assert.assertEquals(Assert.java:555)
at org.junit.Assert.assertEquals(Assert.java:542)
at
org.apache.sling.discovery.impl.topology.TopologyTestHelper.assertTopologyConsistsOf(TopologyTestHelper.java:127)
at
org.apache.sling.discovery.impl.topology.LargeTopologyWithHubTest.testLargeTopologyWithHub(LargeTopologyWithHubTest.java:84)
{code}
grepping for log.info testLargeTopologyWithHub shows :
{code}
28.01.2015 08:16:25 *INFO * [main] LargeTopologyWithHubTest:
testLargeTopologyWithHub: checking if all connectors are registered,
TopologyView has 47 Instances
...
28.01.2015 08:16:32 *INFO * [main] LargeTopologyWithHubTest:
testLargeTopologyWithHub: checking if all connectors are registered,
TopologyView has 46 Instances
...
28.01.2015 08:16:38 *INFO * [main] LargeTopologyWithHubTest:
testLargeTopologyWithHub: checking if all connectors are registered,
TopologyView has 45 Instances
...
28.01.2015 08:16:44 *INFO * [main] LargeTopologyWithHubTest:
testLargeTopologyWithHub: checking if all connectors are registered,
TopologyView has 44 Instances
{code}
basically the instances die one after each other - probably due to no longer
sending heartbeats. I'll check
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
Sling Models 1.2, Validation
Hi list, do we already have a release date for Sling Models 1.2 incl. Validation? This version is mentioned in the documentation [1], but not available for download. Best regards Matthias [1] http://sling.apache.org/documentation/bundles/models.html
[jira] [Updated] (SLING-4385) TopologyEventTest.testNonDelayedInitEvent test failure
[
https://issues.apache.org/jira/browse/SLING-4385?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Egli updated SLING-4385:
---
Fix Version/s: (was: Discovery Impl 1.1.0)
Discovery Impl 1.1.2
TopologyEventTest.testNonDelayedInitEvent test failure
--
Key: SLING-4385
URL: https://issues.apache.org/jira/browse/SLING-4385
Project: Sling
Issue Type: Bug
Components: Extensions
Affects Versions: Discovery Impl 1.0.12
Reporter: Stefan Egli
Assignee: Stefan Egli
Fix For: Discovery Impl 1.1.2
TopologyEventTest.testNonDelayedInitEvent sometimes fails.
eg:
https://builds.apache.org/job/sling-trunk-1.8/org.apache.sling$org.apache.sling.discovery.impl/695/testReport/junit/org.apache.sling.discovery.impl.cluster/TopologyEventTest/testNonDelayedInitEvent/
{code}
java.lang.AssertionError: expected:2 but was:1
at org.junit.Assert.fail(Assert.java:88)
at org.junit.Assert.failNotEquals(Assert.java:743)
at org.junit.Assert.assertEquals(Assert.java:118)
at org.junit.Assert.assertEquals(Assert.java:555)
at org.junit.Assert.assertEquals(Assert.java:542)
at
org.apache.sling.discovery.impl.cluster.TopologyEventTest.testNonDelayedInitEvent(TopologyEventTest.java:255)
{code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
Re: Sling leader / CRX master mapping
Hi Timothee, On 3/17/15 5:37 PM, Timothée Maret timothee.ma...@gmail.com wrote: Due to an edge-case in job distribution (job is started and executed on CRX master, master crashes before slave is updated, slave becomes master, slave executes job a second time) the suggestion is to make anything *but* the CRX master become the discovery leader. Ok, but isn't it still prone to double execution even when leader != master ? Assuming one master, two slaves and the following scenario: master receives a job, the job replicated to slaves, one slave executes the job and commits its changes, slave crashes before the changes are replicated, the other slave picks the job and execute it again. The time window between committing the changes and finishing the job is much smaller though. There is no absolute guarantee, right, but it is less likely. Can we offer guarantees against double execution, unordered or missing execution without some sort of distributed locking, a way to make sure the content is replicated or some sort of centralised job dispatcher ? An absolute guarantee not. And I don't think we aim to magically make this work with this 'slave be the leader' default. But it reduces the likelihood a lot. Re unordered/missing execution: if there is network partitioning (real of pseudo) then you the ordering would no longer be guaranteed, agreed. Not sure if you could really miss a job execution though! Network partitioning is not currently supported though. Anyway, AFAIU enforcing 'leader != master' would be against an active/passive setup. Indeed, if enabled, an application could either process on exactly one crx slave Right. Why would it be 'against' such a setup though? The application should not depend on the underlying cluster technology nor deployment. Ideally it would just make use of the fact that one instance in the cluster is nominated 'leader' and if it has something to execute only once, then it should choose that leader to do it. I fear there is no explicit way atm to force the behavior you want. About the closest one I can think of is: the leader is defined to be stable, ie once an instance is leader, it stays leader until it leaves/crashes. Or in other words: the first instance started on a fresh setup becomes leader. IIUC, currently we can have either I. strong guarantees that 'leader != master' or II. best effort to enforce 'leader == master'. Assuming avoiding quirks in jobs processing requires a broader solution than what was introduced in SLING-3253, wouldn't it make sense to allow guaranteeing II. ? What you can always do is make your implementation also check on the underlying repository descriptor yourself - and take that one if it is set, otherwise use the sling discovery.. IMO the leader would still be relatively stable (not impacted by addition of new instances in the topology) and would allow to guarantee an active/passive cluster setup. Both I and II have the negative side-effect that in case the master crashes, the leader might change. So in that sense, they both break the 'strong leader' argument - so it would not introduce anything more negative there. So yes, discovery could support II - but you could also read the descriptor explicitly as an alternative. Depends on which way you'd like to go - if you'd like to have this though, could you pls create a ticket? Cheers, Stefan
[VOTE] Release Apache Sling discovery.impl 1.1.0
Hi, We solved 14 issues in this release: https://issues.apache.org/jira/browse/SLING/fixforversion/12328787/ Staging repository: https://repository.apache.org/content/repositories/orgapachesling-1214 You can use this UNIX script to download the release and verify the signatures: http://svn.apache.org/repos/asf/sling/trunk/check_staged_release.sh Usage: sh check_staged_release.sh 1214 /tmp/sling-staging Please vote to approve this release: [ ] +1 Approve the release [ ] 0 Don't care [ ] -1 Don't release, because ... This majority vote is open for at least 72 hours. Cheers, Stefan
Jenkins build became unstable: sling-trunk-1.8 #863
See https://builds.apache.org/job/sling-trunk-1.8/863/changes
[jira] [Updated] (SLING-3434) Make intra-cluster discovery-heartbeats independent from machine clock differences
[ https://issues.apache.org/jira/browse/SLING-3434?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Munteanu updated SLING-3434: --- Fix Version/s: (was: Discovery Impl 1.1.0) Make intra-cluster discovery-heartbeats independent from machine clock differences -- Key: SLING-3434 URL: https://issues.apache.org/jira/browse/SLING-3434 Project: Sling Issue Type: Bug Components: Extensions Affects Versions: Discovery Impl 1.0.2 Reporter: Stefan Egli Assignee: Stefan Egli SLING-2967 fixed an issue where topology connectors were dependent on having machine clocks in sync - so inter-cluster we're no longer dependent on NTP-synching. Inside a cluster though, this problem is still there. Since heartbeats are written as absolute time - based on the originator's machine clock - it still only works fine the whole cluster is NTP-synched. In general I think this is not a problem as it is best-practice to make sure machines have NTP set up. Nevertheless, it would help if discovery.impl could become independent from this. Also, if clocks are off by too much, pseudo-network-partitions can occur, with the result of having multiple leaders in a cluster (also see SLING-3432) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
Re: [VOTE] Release Apache Sling discovery.impl 1.1.0
On Wed, Mar 18, 2015 at 3:48 PM, Stefan Egli stefane...@apache.org wrote: Please vote to approve this release: [ ] +1 Approve the release +1 Robert
Jenkins build became unstable: sling-trunk-1.7 #1573
See https://builds.apache.org/job/sling-trunk-1.7/1573/changes
[jira] [Updated] (SLING-3829) Add support for Content-Disposition attachment
[ https://issues.apache.org/jira/browse/SLING-3829?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Antonio Sanso updated SLING-3829: - Attachment: (was: ContentDispositionFilter.java) Add support for Content-Disposition attachment --- Key: SLING-3829 URL: https://issues.apache.org/jira/browse/SLING-3829 Project: Sling Issue Type: Improvement Components: Extensions Reporter: Antonio Sanso Assignee: Antonio Sanso Priority: Minor Attachments: ContentDispositionFilter.java In some situation will be useful (and safer) to force Content-Disposition attachment for some Content-Type (configurable ) under some specific (and sensitive) path (configurable) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (SLING-3829) Add support for Content-Disposition attachment
[
https://issues.apache.org/jira/browse/SLING-3829?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14367381#comment-14367381
]
Alexander Klimetschek commented on SLING-3829:
--
What is the {{UniversalExfiltrator.swf}} in the content-disposition header for?
Add support for Content-Disposition attachment
---
Key: SLING-3829
URL: https://issues.apache.org/jira/browse/SLING-3829
Project: Sling
Issue Type: Improvement
Components: Extensions
Reporter: Antonio Sanso
Assignee: Antonio Sanso
Priority: Minor
Attachments: ContentDispositionFilter.java
In some situation will be useful (and safer) to force Content-Disposition
attachment for some Content-Type (configurable ) under some specific (and
sensitive) path (configurable)
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (SLING-3829) Add support for Content-Disposition attachment
[ https://issues.apache.org/jira/browse/SLING-3829?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Antonio Sanso updated SLING-3829: - Attachment: ContentDispositionFilter.java Add support for Content-Disposition attachment --- Key: SLING-3829 URL: https://issues.apache.org/jira/browse/SLING-3829 Project: Sling Issue Type: Improvement Components: Extensions Reporter: Antonio Sanso Assignee: Antonio Sanso Priority: Minor Attachments: ContentDispositionFilter.java In some situation will be useful (and safer) to force Content-Disposition attachment for some Content-Type (configurable ) under some specific (and sensitive) path (configurable) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (SLING-3829) Add support for Content-Disposition attachment
[ https://issues.apache.org/jira/browse/SLING-3829?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14367389#comment-14367389 ] Antonio Sanso commented on SLING-3829: -- ops sorry it is a refuse... updated the file Add support for Content-Disposition attachment --- Key: SLING-3829 URL: https://issues.apache.org/jira/browse/SLING-3829 Project: Sling Issue Type: Improvement Components: Extensions Reporter: Antonio Sanso Assignee: Antonio Sanso Priority: Minor Attachments: ContentDispositionFilter.java In some situation will be useful (and safer) to force Content-Disposition attachment for some Content-Type (configurable ) under some specific (and sensitive) path (configurable) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (SLING-3829) Add support for Content-Disposition attachment
[ https://issues.apache.org/jira/browse/SLING-3829?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Antonio Sanso updated SLING-3829: - Attachment: (was: ContentDispositionFilter.java) Add support for Content-Disposition attachment --- Key: SLING-3829 URL: https://issues.apache.org/jira/browse/SLING-3829 Project: Sling Issue Type: Improvement Components: Extensions Reporter: Antonio Sanso Assignee: Antonio Sanso Priority: Minor Attachments: ContentDispositionFilter.java In some situation will be useful (and safer) to force Content-Disposition attachment for some Content-Type (configurable ) under some specific (and sensitive) path (configurable) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (SLING-4515) Insufficient cleanup of the JavaScript execution engine leads to runtime errors
Radu Cotescu created SLING-4515:
---
Summary: Insufficient cleanup of the JavaScript execution engine
leads to runtime errors
Key: SLING-4515
URL: https://issues.apache.org/jira/browse/SLING-4515
Project: Sling
Issue Type: Bug
Components: Scripting
Reporter: Radu Cotescu
Assignee: Radu Cotescu
Fix For: Scripting Sightly JS Use Provider 1.0.0
Insufficient cleanup of the JavaScript execution engine leads to runtime errors
if the {{org.apache.sling.scripting.sightly.js.provider}} bundle is restarted a
couple of times. This is caused by not calling the
{{org.apache.sling.scripting.sightly.js.impl.JsEnvironment#cleanup}} method
before finishing the execution of
{{org.apache.sling.scripting.sightly.js.impl.JsUseProvider#provide}}.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (SLING-3829) Add support for Content-Disposition attachment
[ https://issues.apache.org/jira/browse/SLING-3829?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14367367#comment-14367367 ] Antonio Sanso commented on SLING-3829: -- just in case we still want to go with the original Content-Disposition filter I added a basic strawman patch. This covers only the basic case. E.g. no exception based on content type. Also performance wise there are some concerns. the filter “complexity will be linear to the number of the configuration set in the filter (this can of course be improved) Add support for Content-Disposition attachment --- Key: SLING-3829 URL: https://issues.apache.org/jira/browse/SLING-3829 Project: Sling Issue Type: Improvement Components: Extensions Reporter: Antonio Sanso Assignee: Antonio Sanso Priority: Minor Attachments: ContentDispositionFilter.java In some situation will be useful (and safer) to force Content-Disposition attachment for some Content-Type (configurable ) under some specific (and sensitive) path (configurable) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (SLING-4515) Insufficient cleanup of the JavaScript execution engine leads to runtime errors
[
https://issues.apache.org/jira/browse/SLING-4515?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14367431#comment-14367431
]
Radu Cotescu commented on SLING-4515:
-
Fixed in
[r1667586|https://svn.apache.org/viewvc?view=revisionrevision=1667586].
Insufficient cleanup of the JavaScript execution engine leads to runtime
errors
---
Key: SLING-4515
URL: https://issues.apache.org/jira/browse/SLING-4515
Project: Sling
Issue Type: Bug
Components: Scripting
Reporter: Radu Cotescu
Assignee: Radu Cotescu
Fix For: Scripting Sightly JS Use Provider 1.0.0
Insufficient cleanup of the JavaScript execution engine leads to runtime
errors if the {{org.apache.sling.scripting.sightly.js.provider}} bundle is
restarted a couple of times. This is caused by not calling the
{{org.apache.sling.scripting.sightly.js.impl.JsEnvironment#cleanup}} method
before finishing the execution of
{{org.apache.sling.scripting.sightly.js.impl.JsUseProvider#provide}}.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
Re: [VOTE] Release Apache Sling discovery.impl 1.1.0
Another seemingly missed dependency in the current version of the Launchpad: org.apache.http -- Cannot be resolved org.apache.http.auth,version=[4.3,5) -- Cannot be resolved org.apache.http.client,version=[4.3,5) -- Cannot be resolved org.apache.http.client.config,version=[4.3,5) -- Cannot be resolved org.apache.http.client.methods,version=[4.3,5) -- Cannot be resolved org.apache.http.client.protocol,version=[4.3,5) -- Cannot be resolved org.apache.http.config -- Cannot be resolved org.apache.http.entity -- Cannot be resolved org.apache.http.impl.client,version=[4.3,5) -- Cannot be resolved org.apache.http.protocol -- Cannot be resolved Version 1.0.12 does not have this issue. Just a question for the group: does it matter? I mean it feels like these bundles should install into the SNAPSHOT Launchpad, but I don't want to be wasting people's time if it's not necessary. -Dan On Wed, Mar 18, 2015 at 10:44 AM, Robert Munteanu romb...@apache.org wrote: On Wed, Mar 18, 2015 at 3:48 PM, Stefan Egli stefane...@apache.org wrote: Please vote to approve this release: [ ] +1 Approve the release +1 Robert
[jira] [Updated] (SLING-3829) Add support for Content-Disposition attachment
[ https://issues.apache.org/jira/browse/SLING-3829?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Antonio Sanso updated SLING-3829: - Attachment: ContentDispositionFilter.java adding strawman patch Add support for Content-Disposition attachment --- Key: SLING-3829 URL: https://issues.apache.org/jira/browse/SLING-3829 Project: Sling Issue Type: Improvement Components: Extensions Reporter: Antonio Sanso Assignee: Antonio Sanso Priority: Minor Attachments: ContentDispositionFilter.java In some situation will be useful (and safer) to force Content-Disposition attachment for some Content-Type (configurable ) under some specific (and sensitive) path (configurable) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (SLING-3829) Add support for Content-Disposition attachment
[ https://issues.apache.org/jira/browse/SLING-3829?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Antonio Sanso updated SLING-3829: - Attachment: ContentDispositionFilter.java Add support for Content-Disposition attachment --- Key: SLING-3829 URL: https://issues.apache.org/jira/browse/SLING-3829 Project: Sling Issue Type: Improvement Components: Extensions Reporter: Antonio Sanso Assignee: Antonio Sanso Priority: Minor Attachments: ContentDispositionFilter.java In some situation will be useful (and safer) to force Content-Disposition attachment for some Content-Type (configurable ) under some specific (and sensitive) path (configurable) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
Jenkins build is back to stable : sling-trunk-1.8 #864
See https://builds.apache.org/job/sling-trunk-1.8/864/changes
Re: Sling leader / CRX master mapping
Hi Timothee, On 3/18/15 6:45 PM, Timothée Maret timothee.ma...@gmail.com wrote: Anyway, AFAIU enforcing 'leader != master' would be against an active/passive setup. Indeed, if enabled, an application could either process on exactly one crx slave Right. Why would it be 'against' such a setup though? Because it leads to writing on the slave and have changes replicated to master where we would expect the slave to only receives replicated changes from master in an active/passive setup. Agreed Cheers, Stefan
[jira] [Updated] (SLING-4516) Allow to configure the leader to follow the crx master
[ https://issues.apache.org/jira/browse/SLING-4516?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Egli updated SLING-4516: --- Fix Version/s: Discovery Impl 1.1.2 Assignee: Stefan Egli Allow to configure the leader to follow the crx master -- Key: SLING-4516 URL: https://issues.apache.org/jira/browse/SLING-4516 Project: Sling Issue Type: Bug Components: Extensions Affects Versions: Discovery Impl 1.0.12 Reporter: Timothee Maret Assignee: Stefan Egli Priority: Minor Fix For: Discovery Impl 1.1.2 As discussed in [0] in deployments involving a CRX cluster in active/passive setup, it would be beneficial to allow the Sling leader to match the CRX master at all time, thus avoiding to write on the CRX slave. This issue is about enabling this as an optional support. This is only relevant for setups on CRX and should not impact other clustering technologies. [0] http://apache-sling.73963.n3.nabble.com/Sling-leader-CRX-master-mapping-td4048533.html -- This message was sent by Atlassian JIRA (v6.3.4#6332)
Re: [VOTE] Release Apache Sling discovery.impl 1.1.0
On Wed, Mar 18, 2015 at 5:32 PM, Daniel Klco dk...@apache.org wrote: Another seemingly missed dependency in the current version of the Launchpad: org.apache.http -- Cannot be resolved org.apache.http.auth,version=[4.3,5) -- Cannot be resolved org.apache.http.client,version=[4.3,5) -- Cannot be resolved org.apache.http.client.config,version=[4.3,5) -- Cannot be resolved org.apache.http.client.methods,version=[4.3,5) -- Cannot be resolved org.apache.http.client.protocol,version=[4.3,5) -- Cannot be resolved org.apache.http.config -- Cannot be resolved org.apache.http.entity -- Cannot be resolved org.apache.http.impl.client,version=[4.3,5) -- Cannot be resolved org.apache.http.protocol -- Cannot be resolved Version 1.0.12 does not have this issue. Just a question for the group: does it matter? I mean it feels like these bundles should install into the SNAPSHOT Launchpad, but I don't want to be wasting people's time if it's not necessary. Since the discovery bundles are part of the launchpad and we'll want them up-to-date it should deploy in the launchpad. ( The XSS one was only part of contrib though ) Stefan, can you tell us which additional bundles need to be deployed to the current Sling launchpad for this version of discovery.impl? Thanks, Robert -Dan On Wed, Mar 18, 2015 at 10:44 AM, Robert Munteanu romb...@apache.org wrote: On Wed, Mar 18, 2015 at 3:48 PM, Stefan Egli stefane...@apache.org wrote: Please vote to approve this release: [ ] +1 Approve the release +1 Robert
[jira] [Updated] (SLING-4371) Create 'cluster clocks in sync' health check
[ https://issues.apache.org/jira/browse/SLING-4371?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carsten Ziegeler updated SLING-4371: Fix Version/s: (was: Discovery Impl 1.0.14) Create 'cluster clocks in sync' health check Key: SLING-4371 URL: https://issues.apache.org/jira/browse/SLING-4371 Project: Sling Issue Type: Sub-task Components: Extensions, Health Check Reporter: Stefan Egli Write a health-check (probably in the discovery.impl bundle itself?) that checks the newly added 'votedAt' timestamp of each cluster instance and makes sure they don't differ too much. If they do, fail the check. This would be a very simple check to make sysadmins aware that the clocks are not in sync - or for that matter, that there is a problem in the repository, ie that there are too large write-delays between instances hooked to the same repository. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
Jenkins build is back to stable : sling-trunk-1.7 #1576
See https://builds.apache.org/job/sling-trunk-1.7/1576/changes
[jira] [Created] (SLING-4517) Update debian packaging to use crankstart.
Bruce Edge created SLING-4517: - Summary: Update debian packaging to use crankstart. Key: SLING-4517 URL: https://issues.apache.org/jira/browse/SLING-4517 Project: Sling Issue Type: Bug Components: Crankstart Affects Versions: Launchpad Builder 8 Reporter: Bruce Edge Priority: Minor The current debian packaging is launchpad based. This is OK for simple getting started configurations, but falls short of an end-user customizable solution that allows full configurability within the bounds of a pre-packaged env. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (SLING-4517) Update debian packaging to use crankstart.
[ https://issues.apache.org/jira/browse/SLING-4517?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14368200#comment-14368200 ] Bruce Edge commented on SLING-4517: --- Currently working on this. Will have patch soon. Update debian packaging to use crankstart. -- Key: SLING-4517 URL: https://issues.apache.org/jira/browse/SLING-4517 Project: Sling Issue Type: Bug Components: Crankstart Affects Versions: Launchpad Builder 8 Reporter: Bruce Edge Priority: Minor The current debian packaging is launchpad based. This is OK for simple getting started configurations, but falls short of an end-user customizable solution that allows full configurability within the bounds of a pre-packaged env. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (SLING-2192) Support JAX-RS resource classes
[ https://issues.apache.org/jira/browse/SLING-2192?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14367708#comment-14367708 ] Roy Teeuwen commented on SLING-2192: Could anyone tell me what ever happend with this? No support yet for jax-rs? Support JAX-RS resource classes --- Key: SLING-2192 URL: https://issues.apache.org/jira/browse/SLING-2192 Project: Sling Issue Type: New Feature Reporter: Reto Gmür Attachments: SLING-2192-20110310.patch, SLING-2192-20111004.patch, SLING-2192-20111013.patch, SLING-2192-new-jax-rs-bundle.patch, SLING-2192-new-jax-rs-bundle.patch, SLING-2192-with-sling-style-style-registration.patch, SLING-2192-with-tests.patch, jaxrs-in-contrib.patch, slingr-on-wink-osgi.patch It should be possible to register jax resource classes and providers as services. As they don't implement a specific interface services that expose java.lang.Object should be considered as javx-rs services iff they have the service property javax.ws.rs set to true. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
Jenkins build is still unstable: sling-trunk-1.7 #1574
See https://builds.apache.org/job/sling-trunk-1.7/changes
[jira] [Created] (SLING-4516) Allow to configure the leader to follow the crx master
Timothee Maret created SLING-4516: - Summary: Allow to configure the leader to follow the crx master Key: SLING-4516 URL: https://issues.apache.org/jira/browse/SLING-4516 Project: Sling Issue Type: Bug Components: Extensions Affects Versions: Discovery Impl 1.0.12 Reporter: Timothee Maret Priority: Minor As discussed in [0] in deployments involving a CRX cluster in active/passive setup, it would be beneficial to allow the Sling leader to match the CRX master at all time, thus avoiding to write on the CRX slave. This issue is about enabling this as an optional support. This is only relevant for setups on CRX and should not impact other clustering technologies. [0] http://apache-sling.73963.n3.nabble.com/Sling-leader-CRX-master-mapping-td4048533.html -- This message was sent by Atlassian JIRA (v6.3.4#6332)
Re: Sling leader / CRX master mapping
Hi Stefan, Thanks again for your input, more inline below. 2015-03-18 12:59 GMT+01:00 Stefan Egli stefane...@apache.org: Hi Timothee, On 3/17/15 5:37 PM, Timothée Maret timothee.ma...@gmail.com wrote: Due to an edge-case in job distribution (job is started and executed on CRX master, master crashes before slave is updated, slave becomes master, slave executes job a second time) the suggestion is to make anything *but* the CRX master become the discovery leader. Ok, but isn't it still prone to double execution even when leader != master ? Assuming one master, two slaves and the following scenario: master receives a job, the job replicated to slaves, one slave executes the job and commits its changes, slave crashes before the changes are replicated, the other slave picks the job and execute it again. The time window between committing the changes and finishing the job is much smaller though. There is no absolute guarantee, right, but it is less likely. I agree. Can we offer guarantees against double execution, unordered or missing execution without some sort of distributed locking, a way to make sure the content is replicated or some sort of centralised job dispatcher ? An absolute guarantee not. And I don't think we aim to magically make this work with this 'slave be the leader' default. But it reduces the likelihood a lot. thanks for shedding some light here regarding the guarantees offered. Re unordered/missing execution: if there is network partitioning (real of pseudo) then you the ordering would no longer be guaranteed, agreed. Not sure if you could really miss a job execution though! Network partitioning is not currently supported though. Anyway, AFAIU enforcing 'leader != master' would be against an active/passive setup. Indeed, if enabled, an application could either process on exactly one crx slave Right. Why would it be 'against' such a setup though? Because it leads to writing on the slave and have changes replicated to master where we would expect the slave to only receives replicated changes from master in an active/passive setup. The application should not depend on the underlying cluster technology nor deployment. Ideally it would just make use of the fact that one instance in the cluster is nominated 'leader' and if it has something to execute only once, then it should choose that leader to do it. I fear there is no explicit way atm to force the behavior you want. About the closest one I can think of is: the leader is defined to be stable, ie once an instance is leader, it stays leader until it leaves/crashes. Or in other words: the first instance started on a fresh setup becomes leader. IIUC, currently we can have either I. strong guarantees that 'leader != master' or II. best effort to enforce 'leader == master'. Assuming avoiding quirks in jobs processing requires a broader solution than what was introduced in SLING-3253, wouldn't it make sense to allow guaranteeing II. ? What you can always do is make your implementation also check on the underlying repository descriptor yourself - and take that one if it is set, otherwise use the sling discovery.. Yes, we could still implement it at the application level. However at the application level we can't influence code in Sling which is leveraging the leader which IIRC is the case for Sling jobs. IMO the leader would still be relatively stable (not impacted by addition of new instances in the topology) and would allow to guarantee an active/passive cluster setup. Both I and II have the negative side-effect that in case the master crashes, the leader might change. So in that sense, they both break the 'strong leader' argument - so it would not introduce anything more negative there. +1 So yes, discovery could support II - but you could also read the descriptor explicitly as an alternative. Depends on which way you'd like to go - if you'd like to have this though, could you pls create a ticket? For the time being, our service could go with a custom implementation. I have opened SLING-4516 to track adding the possibility to configure CRX master == Sling leader as it might be beneficial to other deployments running on CRX. This addition only makes sense for this clustering technology though. Regards, Timothee Cheers, Stefan
[jira] [Updated] (SLING-4516) Allow to configure the leader to follow the crx master
[ https://issues.apache.org/jira/browse/SLING-4516?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Egli updated SLING-4516: --- Issue Type: Improvement (was: Bug) Allow to configure the leader to follow the crx master -- Key: SLING-4516 URL: https://issues.apache.org/jira/browse/SLING-4516 Project: Sling Issue Type: Improvement Components: Extensions Affects Versions: Discovery Impl 1.0.12 Reporter: Timothee Maret Assignee: Stefan Egli Priority: Minor Fix For: Discovery Impl 1.1.2 As discussed in [0] in deployments involving a CRX cluster in active/passive setup, it would be beneficial to allow the Sling leader to match the CRX master at all time, thus avoiding to write on the CRX slave. This issue is about enabling this as an optional support. This is only relevant for setups on CRX and should not impact other clustering technologies. [0] http://apache-sling.73963.n3.nabble.com/Sling-leader-CRX-master-mapping-td4048533.html -- This message was sent by Atlassian JIRA (v6.3.4#6332)
Jenkins build is still unstable: sling-trunk-1.7 #1575
See https://builds.apache.org/job/sling-trunk-1.7/changes
