Re: [ANN] New Committer : Stefan Egli
Thanks for the welcome guys! :) On 4/23/13 9:23 AM, Carsten Ziegeler cziege...@apache.org wrote: Welcome Stefan (and sorry for the typo in your last name!) No worries! Cheers, Stefan Carsten 2013/4/23 Carsten Ziegeler cziege...@apache.org The Project Management Committee (PMC) for Apache Slinghas asked Stefan Eglie to become a committer and we are pleased to announce that they have accepted. Being a committer enables easier contribution to theproject since there is no need to go via the patchsubmission process. This should enable better productivity.Being a PMC member enables assistance with the managementand to guide the direction of the project. Regards Carsten -- Carsten Ziegeler cziege...@apache.org -- Carsten Ziegeler cziege...@apache.org
Re: [ANN] New Committer : Stefan Egli
Hi all, Let me give you a brief introduction of myself. I am working for Adobe Systems for a year now in the CQ5 team and have been involved in several different aspects of it. The latest the distributed job handling where I had the chance to work with Carsten on the new discovery API and subsequently on the sling-out-of-the-box implementation of the same. Very much looking forward to continuing on discovery.impl and working on this project! Cheers, Stefan On 4/23/13 9:34 AM, Stefan Egli e...@adobe.com wrote: Thanks for the welcome guys! :) On 4/23/13 9:23 AM, Carsten Ziegeler cziege...@apache.org wrote: Welcome Stefan (and sorry for the typo in your last name!) No worries! Cheers, Stefan Carsten 2013/4/23 Carsten Ziegeler cziege...@apache.org The Project Management Committee (PMC) for Apache Slinghas asked Stefan Eglie to become a committer and we are pleased to announce that they have accepted. Being a committer enables easier contribution to theproject since there is no need to go via the patchsubmission process. This should enable better productivity.Being a PMC member enables assistance with the managementand to guide the direction of the project. Regards Carsten -- Carsten Ziegeler cziege...@apache.org -- Carsten Ziegeler cziege...@apache.org
Re: Updates to the Sling Event Bundle
Hi Bertrand, On 4/26/13 12:24 PM, Bertrand Delacretaz bdelacre...@apache.org wrote: Hi Carsten, On Fri, Apr 26, 2013 at 9:10 AM, Carsten Ziegeler cziege...@apache.org wrote: ...The discovery API also does a leader election, so there is one dedicated instance which can be used for things that really should only run on a single instance... Are you confident that the ClusterView's every ClusterView is guaranteed to have one and only one leader invariant is adequately covered by the existing tests? Or are you planning more testing to simulate edge cases like timeouts, intermittent disconnects, PersistenceException etc? A quick look at the tests seems to indicate that they test happy cases so far - but maybe I missed something. +1 for more testing to come. The current state of the tests is indeed rather on the happy side of things and more disaster cases should be added. Cheers, Stefan
Re: Releasing discovery
On 5/21/13 11:13 AM, Bertrand Delacretaz bdelacre...@apache.org wrote: On Fri, May 17, 2013 at 9:33 AM, Carsten Ziegeler cziege...@apache.org wrote: ...I'm planning to cut a release of the discovery modules next week... Can we have some docs about these modules? Dan's probably not the only one wondering what they're about. Even something minimal like I did for the health check module (just what's that and how to play with it) at http://sling.apache.org/documentation/bundles/sling-health-check-tool.html is good to have IMO, so that a web search for sling discovery modules lands in a place that has at least basic info. I shall be looking into this. Is the 'Misc' section under http://sling.apache.org/documentation/bundles.html a good place? Cheers, Stefan -Bertrand
Re: Releasing discovery
On 5/21/13 5:20 PM, Bertrand Delacretaz bdelacre...@apache.org wrote: On Tue, May 21, 2013 at 4:52 PM, Stefan Egli e...@adobe.com wrote: On 5/21/13 11:13 AM, Bertrand Delacretaz bdelacre...@apache.org wrote: Can we have some docs about these modules?... I shall be looking into this. Is the 'Misc' section under http://sling.apache.org/documentation/bundles.html a good place?... I think so - if it's your first time using the Apache CMS, the simplest is to add the new .mdtext file at https://svn.apache.org/repos/asf/sling/site/trunk/content/documentation/bu ndles and then edit it and the bundles.mdtext page from https://cms.apache.org/sling/ Thanks. The documentation is now ready. Much appreciate comments and feedback. It can already be found here: http://sling.staging.apache.org/documentation/bundles/discovery-api-and-imp l.html But should soon be here too: http://sling.apache.org/documentation/bundles/discovery-api-and-impl.html Cheers, Stefan
Re: Releasing discovery
Excellent, thanks a lot for the review fixes! Cheers, Stefan On 5/22/13 2:29 PM, Bertrand Delacretaz bdelacre...@apache.org wrote: Hi Stefan, On Wed, May 22, 2013 at 2:03 PM, Stefan Egli e...@adobe.com wrote: The documentation is now ready... http://sling.staging.apache.org/documentation/bundles/discovery-api-and-i mp l.html Very cool! I have fixed a few typos and made some minor changes while reviewing, and I now understand what this module is about ;-) You can review my changes at http://svn.apache.org/r1485185 and as far as I'm concerned this can go live. -Bertrand
Re: Releasing discovery
And the page is now live: http://sling.apache.org/documentation/bundles/discovery-api-and-impl.html Cheers, Stefan On 5/22/13 2:35 PM, Stefan Egli e...@adobe.com wrote: Excellent, thanks a lot for the review fixes! Cheers, Stefan On 5/22/13 2:29 PM, Bertrand Delacretaz bdelacre...@apache.org wrote: Hi Stefan, On Wed, May 22, 2013 at 2:03 PM, Stefan Egli e...@adobe.com wrote: The documentation is now ready... http://sling.staging.apache.org/documentation/bundles/discovery-api-and- i mp l.html Very cool! I have fixed a few typos and made some minor changes while reviewing, and I now understand what this module is about ;-) You can review my changes at http://svn.apache.org/r1485185 and as far as I'm concerned this can go live. -Bertrand
Re: Releasing discovery
On 5/21/13 12:00 PM, Bertrand Delacretaz bdelacre...@apache.org wrote: On Fri, May 17, 2013 at 9:33 AM, Carsten Ziegeler cziege...@apache.org wrote: ...If you see any issues with releasing this stuff, please speak up now... I had another (quick) look at the tests, and unless I missed something it's still mostly or only happy cases that are tested. I personally wouldn't trust this stuff until torture tests that break it are implemented...multi-instance discovery and consensus will usually break when someone pulls power and network plugs randomly, and the question is then how robust the recovery algorithms are. Such simulations can be hard to implement, but maybe just running lots of test threads and killing some of them at random would help discover how the discovery implementation handles unexpected failures and timeouts. We can let such tests run on Jenkins even if they are slow. FYI: that's on my list .. Cheers, Stefan This doesn't prevent us from releasing the API, of course, but for the implementation it might be good to include a note about what level of testing exists so far, to avoid unrealistic expectations. -Bertrand
Re: svn commit: r1487591 - in /sling/trunk/bundles/extensions/discovery/impl: pom.xml src/main/java/org/apache/sling/discovery/impl/common/heartbeat/HeartbeatHandler.java src/test/java/org/apache/slin
Hi Felix, On 5/29/13 9:52 PM, Felix Meschberger fmesc...@adobe.com wrote: Hi Am 29.05.2013 um 20:54 schrieb stefane...@apache.org stefane...@apache.org: +/** SLING-2892: remember the value of the heartbeat this instance has written the last time **/ +private Calendar lastHeartbeatWritten = null; Is there a reason you use Calendar here ? I have the impression that a long being System.currentTimeMillis would be sufficient. I've chosen to use Calendar for the 'lastHeartbeat' (instead of a long) to have a human readable value. That's basically why then this new field also got the type Calendar, as I simply cache the last 'lastHeartbeat' value. It could of course just cache the long value of the Calendar, agreed. Cheers, Stefan
[Discovery] missing features and 3rd party implementation of discovery.api
Hi, I've created SLING-2939 [0] to track an additional, 3rd party based implementation of the discovery.api. The idea is to complement the discovery.impl (which is ootb, entirely sling-based) with a more mature, specialized, scalable implementation based on a clustering library. I've summarized some pros/cons of possible candidates, including some already received feedback in the ticket. I would appreciated further feedback! It looks like Zookeeper/Curator would be a very good fit, requirement-wise – but there was also an argument for using JGroups (or something like Infinispan ontop of it), although that's LGPL at the moment. At the same time, it might be a good time to discuss if there's any need for api changes, like 'topology-wide leader' or 'grouping/spliting/organizing topologies'. In discussions surrounding topologies, other more consensus-like topics came up (things which zookeeper/curator would cover nicely). The question here is though if that fits into the discovery api itself or if that's not something completely different and out-of-scope of discovery. Thanks, Cheers, Stefan -- [0] - https://issues.apache.org/jira/browse/SLING-2939
Re: [Discovery] missing features and 3rd party implementation of discovery.api
Does the fact that JGroups uses LGPL at the moment (they plan to switch to APL 'soon') prevent it from being used in Sling? Cheers, Stefan On 7/3/13 3:05 PM, Carsten Ziegeler cziege...@apache.org wrote: Thanks for taking this up, Stefan. I think we should also try to close down the first version of the discovery api and release this, so other parts of our code can really rely on this api. Apart from that, I don't have a strong preference, although it would be nice to just use Apache stuff :) Regards Carsten 2013/7/1 Stefan Egli e...@adobe.com Hi, I've created SLING-2939 [0] to track an additional, 3rd party based implementation of the discovery.api. The idea is to complement the discovery.impl (which is ootb, entirely sling-based) with a more mature, specialized, scalable implementation based on a clustering library. I've summarized some pros/cons of possible candidates, including some already received feedback in the ticket. I would appreciated further feedback! It looks like Zookeeper/Curator would be a very good fit, requirement-wise but there was also an argument for using JGroups (or something like Infinispan ontop of it), although that's LGPL at the moment. At the same time, it might be a good time to discuss if there's any need for api changes, like 'topology-wide leader' or 'grouping/spliting/organizing topologies'. In discussions surrounding topologies, other more consensus-like topics came up (things which zookeeper/curator would cover nicely). The question here is though if that fits into the discovery api itself or if that's not something completely different and out-of-scope of discovery. Thanks, Cheers, Stefan -- [0] - https://issues.apache.org/jira/browse/SLING-2939 -- Carsten Ziegeler cziege...@apache.org
[ide] VLT vs Resource-based (was: [ide] Moving the IDE tools to contrib)
Hi, On 7/24/13 11:42 PM, Justin Edelson jus...@justinedelson.com wrote: On Wed, Jul 24, 2013 at 1:54 PM, Robert Munteanu rob...@lmn.ro wrote: Once we can use VLT, we'll see what fits best. I admit that I have an inclination towards the resource-based API, but it's not my personal decision to make. I think to make an apples-to-apples comparison, the packaging format and installaion services will also need to be at least defined (better yet would be to have prototypes available). I thought that was the outcome of the prior thread we had on this subject. As I said at that point, the advantage of leveraging VLT is that the existing packaging tool ecosystem would not need to be recreated. Seems still to be a hot topic - VLT vs Resource-based. And I think we should soon get to a decision on this. I think the decision which one to choose is not only related to how well it fits into the IDE, but also related to the impact on the overall picture. Especially given that there is quite some existing packaging ecosystem around, as Justin mentioned. So IMHO if the tooling chooses to go another direction than VLT, that either means that the packaging ecosystem should switch as well - or it ends up not being used by many people. For the short term I dont see a problem having the possibility to play with both - but I think we are in some sort of agreement that in the end result there should only be one way. Cheers, Stefan
Re: TopologyConnectorServlet
Hi Ian,
+1
I like the idea of making an API out of this. One thing to remember is
that this API would be part of discovery.impl rather than discovery.api -
since the discovery.api does not make any assumptions on how
instances/clusters discover each other. Nevertheless I think it's a good
idea.
Additionally, I wonder if we could also include the possibility of
encrypting/decrypting the payload that discovery.impl sends around via the
topology connectors? It could be a separate service - eg
DiscoveryPayloadHandler - and provide methods to encrypt and
decrypt/verify.
Cheers,
Stefan
On 10/8/13 7:40 PM, Ian Boston i...@tfd.co.uk wrote:
Hi,
The whitelist configuration in this servlet is causing some problems
where the contents of the whitelist is potentially large and changing,
since it requires constant re-configuration.
Would it be possible to have a API service that is consulted if
present to check if the request is allowed. For those that want to use
the service they would configure the whitelist to reject everything
while the service was not present so avoid startup issues.
eg
+@Reference(cardinality=ReferenceCardinality.OPTIONAL_UNARY)
+ private WhiteListProvider whiteListProvider;
/** Checks if the provided request's remote server is whitelisted **/
private boolean isWhitelisted(final SlingHttpServletRequest request) {
+ if (whiteListProvider != null) {
+ whiteListProvider.isWhitelisted(request);
+}
if (whitelist.contains(request.getRemoteAddr())) {
return true;
} else if (whitelist.contains(request.getRemoteHost())) {
return true;
}
logger.info(isWhitelisted: rejecting + request.getRemoteAddr()
+ , + request.getRemoteHost());
return false;
}
and in the API, presumably discovery api.
public interface WhiteListProvider {
private boolean isWhitelisted(HttpServletRequest request);
}
Best Regards
Ian
Re: TopologyConnectorServlet
On 10/9/13 10:34 AM, Ian Boston i...@tfd.co.uk wrote:
On 9 October 2013 09:16, Stefan Egli e...@adobe.com wrote:
Hi Ian,
+1
I like the idea of making an API out of this. One thing to remember is
that this API would be part of discovery.impl rather than discovery.api
-
since the discovery.api does not make any assumptions on how
instances/clusters discover each other. Nevertheless I think it's a good
idea.
Ok, thats probably easier if its Ok for the Discovery Impl to export a
package.
I forgot 1 thing, there will need to be support for creating the
aspects of the request that make it trusted, as well as white listing
it.
I added a suggestion for the API to SLING-3154 - do you see additional
properties (to the plain request object) needed to decide if a request can
be trusted?
Additionally, I wonder if we could also include the possibility of
encrypting/decrypting the payload that discovery.impl sends around via
the
topology connectors? It could be a separate service - eg
DiscoveryPayloadHandler - and provide methods to encrypt and
decrypt/verify.
That would be a larger patch, but would also work. If its going to
cover all bases, does it need to be outside the Discovery impl ?
I see it as an optional thing, surely. But was thinking it would be a good
idea to make the API also support that case.
Cheers,
Stefan
I've started a jira for this [1]
Best Regards
Ian
1 https://issues.apache.org/jira/browse/SLING-3154
Cheers,
Stefan
On 10/8/13 7:40 PM, Ian Boston i...@tfd.co.uk wrote:
Hi,
The whitelist configuration in this servlet is causing some problems
where the contents of the whitelist is potentially large and changing,
since it requires constant re-configuration.
Would it be possible to have a API service that is consulted if
present to check if the request is allowed. For those that want to use
the service they would configure the whitelist to reject everything
while the service was not present so avoid startup issues.
eg
+@Reference(cardinality=ReferenceCardinality.OPTIONAL_UNARY)
+ private WhiteListProvider whiteListProvider;
/** Checks if the provided request's remote server is whitelisted
**/
private boolean isWhitelisted(final SlingHttpServletRequest
request) {
+ if (whiteListProvider != null) {
+ whiteListProvider.isWhitelisted(request);
+}
if (whitelist.contains(request.getRemoteAddr())) {
return true;
} else if (whitelist.contains(request.getRemoteHost())) {
return true;
}
logger.info(isWhitelisted: rejecting +
request.getRemoteAddr()
+ , + request.getRemoteHost());
return false;
}
and in the API, presumably discovery api.
public interface WhiteListProvider {
private boolean isWhitelisted(HttpServletRequest request);
}
Best Regards
Ian
[Discovery] should we deprecate ClusterView.getId()?
Hi, The discovery's ClusterView contains a 'getId()' which returns the current ClusterView's ID. I'm not sure this ID is any good though. First, it is only valid for the lifetime of the ClusterView - ie if an instance joins a cluster, a new ClusterView is created, with a new ID. Second, what would this ID be usable for, especially given the relatively short validity/lifetime of it? It does not reflect a stable, persistent identifier of the cluster after all. If you want to learn which other instances are part of the local instance, then the API already provides that access. Comparing this to InstanceDescription.getSlingId(): that one iss by definition the 'slingId' which is retrieved from SettingsService and is thus guaranteed to be stable/persistent. So the API is somewhat inconsistent regarding the ClusterView.getId. I thus suggest getting rid of ClusterView.getId – ie marking it as deprecated. (Or, an alternative would be to come up with a stable, persistent clusterId – but that is potentially more complex) Wdyt? Cheers, Stefan
Re: [Discovery] should we deprecate ClusterView.getId()?
On 10/11/13 1:35 PM, Carsten Ziegeler cziege...@apache.org wrote: Hi, yes, I totally agree either we have the id stable or its of no use - I thought that it is stable, actually :) But fortunately the javadocs are unclear about this. I guess it heavily depends on the used implementation whether a stable id is easy to implement or not Given that we have a cluster leader I would assume that the leader could define the cluster Id. However I see problems when two clusters join each other (as is possible eg in crx): there the two clusters both would have had 'stable' cluster ids. After the join, for one of the two parties the cluster id would change. Hence it might be inherently impossible to have stable cluster ids.. in that case, what's the gain of having it in the API.. it would only be 'stable-but'.. - I could imagine use cases where the id corresponds to the data center where the cluster is running and therefore provide useful information. Therefore I'm a little bit hesitant to remove the method - however we could add javadocs like it is not guaranteed that the id is stable across view changes, however implementation should provide stable ids I'd vote for either removing it (ie first deprecating it) or improving it (ie making it 'stable-but'). Cheers, Stefan WDYT? Carsten 2013/10/11 Stefan Egli e...@adobe.com Hi, The discovery's ClusterView contains a 'getId()' which returns the current ClusterView's ID. I'm not sure this ID is any good though. First, it is only valid for the lifetime of the ClusterView - ie if an instance joins a cluster, a new ClusterView is created, with a new ID. Second, what would this ID be usable for, especially given the relatively short validity/lifetime of it? It does not reflect a stable, persistent identifier of the cluster after all. If you want to learn which other instances are part of the local instance, then the API already provides that access. Comparing this to InstanceDescription.getSlingId(): that one iss by definition the 'slingId' which is retrieved from SettingsService and is thus guaranteed to be stable/persistent. So the API is somewhat inconsistent regarding the ClusterView.getId. I thus suggest getting rid of ClusterView.getId ie marking it as deprecated. (Or, an alternative would be to come up with a stable, persistent clusterId but that is potentially more complex) Wdyt? Cheers, Stefan -- Carsten Ziegeler cziege...@apache.org
Re: [Discovery] should we deprecate ClusterView.getId()?
FYI: Created https://issues.apache.org/jira/browse/SLING-3164 for this. Without objections I will go ahead and adjust the javadoc of the API.. Cheers, Stefan On 10/11/13 2:45 PM, Carsten Ziegeler cziege...@apache.org wrote: Rethink this, I guess my use cases call more for a cluster name or cluster description - which is a user created information. The more I think about it, the more I tend to agree that we should deprecate it and clearly state that the id is not guaranteed to be stable (for people using is already). And once my use cases are more concrete than ideas, we can see how to fulfil them. Carsten 2013/10/11 Stefan Egli e...@adobe.com On 10/11/13 1:35 PM, Carsten Ziegeler cziege...@apache.org wrote: Hi, yes, I totally agree either we have the id stable or its of no use - I thought that it is stable, actually :) But fortunately the javadocs are unclear about this. I guess it heavily depends on the used implementation whether a stable id is easy to implement or not Given that we have a cluster leader I would assume that the leader could define the cluster Id. However I see problems when two clusters join each other (as is possible eg in crx): there the two clusters both would have had 'stable' cluster ids. After the join, for one of the two parties the cluster id would change. Hence it might be inherently impossible to have stable cluster ids.. in that case, what's the gain of having it in the API.. it would only be 'stable-but'.. - I could imagine use cases where the id corresponds to the data center where the cluster is running and therefore provide useful information. Therefore I'm a little bit hesitant to remove the method - however we could add javadocs like it is not guaranteed that the id is stable across view changes, however implementation should provide stable ids I'd vote for either removing it (ie first deprecating it) or improving it (ie making it 'stable-but'). Cheers, Stefan WDYT? Carsten 2013/10/11 Stefan Egli e...@adobe.com Hi, The discovery's ClusterView contains a 'getId()' which returns the current ClusterView's ID. I'm not sure this ID is any good though. First, it is only valid for the lifetime of the ClusterView - ie if an instance joins a cluster, a new ClusterView is created, with a new ID. Second, what would this ID be usable for, especially given the relatively short validity/lifetime of it? It does not reflect a stable, persistent identifier of the cluster after all. If you want to learn which other instances are part of the local instance, then the API already provides that access. Comparing this to InstanceDescription.getSlingId(): that one iss by definition the 'slingId' which is retrieved from SettingsService and is thus guaranteed to be stable/persistent. So the API is somewhat inconsistent regarding the ClusterView.getId. I thus suggest getting rid of ClusterView.getId ie marking it as deprecated. (Or, an alternative would be to come up with a stable, persistent clusterId but that is potentially more complex) Wdyt? Cheers, Stefan -- Carsten Ziegeler cziege...@apache.org -- Carsten Ziegeler cziege...@apache.org
Re: [Discovery] should we deprecate ClusterView.getId()?
After some offline discussion with Carsten, here's a summary of a possible replacement-implementation for calculating a more stable clusterid: 1. The clusterId is stored in the repository (eg /var/discovery/impl/clusterId) 2. The cluster leader is in charge of making sure, this id is set 3. When a node joins a cluster, it 'inherits' the clusterId and thus its clusterId changes (an absolutely stable clusterId is impossible) 4. In the opposite case, ie in a network partitioning case (or a node otherwise leaves a cluster), they initially both have the same clusterId stored in the repository. If they are in different Topologies, no one notices. If they are in the same Topology though, you'd end up with ClusterView's with the same ID.. Re 4: This could either be seen as: * a bug: the id would no longer be unique (in a topology) * a feature: it would allow to detect a network partitioning! (by checking clusterview.id's uniqueness in a topology). The question now is: should we still deprecate ClusterView.getId() or apply above logic (and change the API javadoc accordingly)? What do people think? Cheers, Stefan On 10/12/13 6:05 PM, Carsten Ziegeler cziege...@apache.orgmailto:cziege...@apache.org wrote: Exactly, thats what I wrote :) Carsten 2013/10/11 Felix Meschberger fmesc...@adobe.commailto:fmesc...@adobe.com Hi Am 11.10.2013 um 05:45 schrieb Carsten Ziegeler: Rethink this, I guess my use cases call more for a cluster name or cluster description - which is a user created information. The more I think about it, the more I tend to agree that we should deprecate it and clearly state that the id is not guaranteed to be stable (for people using is already). And once my use cases are more concrete than ideas, we can see how to fulfil them. Whatever -- deprecate or not -- I wold like to have the doc be clear: Either stable or not. The longer I use APIs the more I realize that notions such as not guaranteed to ... essentially mean, that it is not usable and dependable. Regards Felix Carsten 2013/10/11 Stefan Egli e...@adobe.commailto:e...@adobe.com On 10/11/13 1:35 PM, Carsten Ziegeler cziege...@apache.orgmailto:cziege...@apache.org wrote: Hi, yes, I totally agree either we have the id stable or its of no use - I thought that it is stable, actually :) But fortunately the javadocs are unclear about this. I guess it heavily depends on the used implementation whether a stable id is easy to implement or not Given that we have a cluster leader I would assume that the leader could define the cluster Id. However I see problems when two clusters join each other (as is possible eg in crx): there the two clusters both would have had 'stable' cluster ids. After the join, for one of the two parties the cluster id would change. Hence it might be inherently impossible to have stable cluster ids.. in that case, what's the gain of having it in the API.. it would only be 'stable-but'.. - I could imagine use cases where the id corresponds to the data center where the cluster is running and therefore provide useful information. Therefore I'm a little bit hesitant to remove the method - however we could add javadocs like it is not guaranteed that the id is stable across view changes, however implementation should provide stable ids I'd vote for either removing it (ie first deprecating it) or improving it (ie making it 'stable-but'). Cheers, Stefan WDYT? Carsten 2013/10/11 Stefan Egli e...@adobe.commailto:e...@adobe.com Hi, The discovery's ClusterView contains a 'getId()' which returns the current ClusterView's ID. I'm not sure this ID is any good though. First, it is only valid for the lifetime of the ClusterView - ie if an instance joins a cluster, a new ClusterView is created, with a new ID. Second, what would this ID be usable for, especially given the relatively short validity/lifetime of it? It does not reflect a stable, persistent identifier of the cluster after all. If you want to learn which other instances are part of the local instance, then the API already provides that access. Comparing this to InstanceDescription.getSlingId(): that one iss by definition the 'slingId' which is retrieved from SettingsService and is thus guaranteed to be stable/persistent. So the API is somewhat inconsistent regarding the ClusterView.getId. I thus suggest getting rid of ClusterView.getId ie marking it as deprecated. (Or, an alternative would be to come up with a stable, persistent clusterId but that is potentially more complex) Wdyt? Cheers, Stefan -- Carsten Ziegeler cziege...@apache.orgmailto:cziege...@apache.org -- Carsten Ziegeler cziege...@apache.orgmailto:cziege...@apache.org -- Carsten Ziegeler cziege...@apache.orgmailto:cziege...@apache.org
Re: [Discovery] should we deprecate ClusterView.getId()?
Hi Chetan, Thanks. I think we should go ahead then and undo the deprecation of ClusterView.getId() and instead making the id 'officially' more stable.. Cheers, Stefan On 10/21/13 1:33 PM, Chetan Mehrotra chetan.mehro...@gmail.com wrote: Hi Stefan I have created SLING-3195 to track this. It would be better if we can make existing id attribute stable Chetan Mehrotra On Tue, Oct 15, 2013 at 7:45 PM, Stefan Egli e...@adobe.com wrote: After some offline discussion with Carsten, here's a summary of a possible replacement-implementation for calculating a more stable clusterid: The clusterId is stored in the repository (eg /var/discovery/impl/clusterId) The cluster leader is in charge of making sure, this id is set When a node joins a cluster, it 'inherits' the clusterId and thus its clusterId changes (an absolutely stable clusterId is impossible) In the opposite case, ie in a network partitioning case (or a node otherwise leaves a cluster), they initially both have the same clusterId stored in the repository. If they are in different Topologies, no one notices. If they are in the same Topology though, you'd end up with ClusterView's with the same ID.. Re 4: This could either be seen as: a bug: the id would no longer be unique (in a topology) a feature: it would allow to detect a network partitioning! (by checking clusterview.id's uniqueness in a topology). The question now is: should we still deprecate ClusterView.getId() or apply above logic (and change the API javadoc accordingly)? What do people think? Cheers, Stefan On 10/12/13 6:05 PM, Carsten Ziegeler cziege...@apache.org wrote: Exactly, thats what I wrote :) Carsten 2013/10/11 Felix Meschberger fmesc...@adobe.com Hi Am 11.10.2013 um 05:45 schrieb Carsten Ziegeler: Rethink this, I guess my use cases call more for a cluster name or cluster description - which is a user created information. The more I think about it, the more I tend to agree that we should deprecate it and clearly state that the id is not guaranteed to be stable (for people using is already). And once my use cases are more concrete than ideas, we can see how to fulfil them. Whatever -- deprecate or not -- I wold like to have the doc be clear: Either stable or not. The longer I use APIs the more I realize that notions such as not guaranteed to ... essentially mean, that it is not usable and dependable. Regards Felix Carsten 2013/10/11 Stefan Egli e...@adobe.com On 10/11/13 1:35 PM, Carsten Ziegeler cziege...@apache.org wrote: Hi, yes, I totally agree either we have the id stable or its of no use - I thought that it is stable, actually :) But fortunately the javadocs are unclear about this. I guess it heavily depends on the used implementation whether a stable id is easy to implement or not Given that we have a cluster leader I would assume that the leader could define the cluster Id. However I see problems when two clusters join each other (as is possible eg in crx): there the two clusters both would have had 'stable' cluster ids. After the join, for one of the two parties the cluster id would change. Hence it might be inherently impossible to have stable cluster ids.. in that case, what's the gain of having it in the API.. it would only be 'stable-but'.. - I could imagine use cases where the id corresponds to the data center where the cluster is running and therefore provide useful information. Therefore I'm a little bit hesitant to remove the method - however we could add javadocs like it is not guaranteed that the id is stable across view changes, however implementation should provide stable ids I'd vote for either removing it (ie first deprecating it) or improving it (ie making it 'stable-but'). Cheers, Stefan WDYT? Carsten 2013/10/11 Stefan Egli e...@adobe.com Hi, The discovery's ClusterView contains a 'getId()' which returns the current ClusterView's ID. I'm not sure this ID is any good though. First, it is only valid for the lifetime of the ClusterView - ie if an instance joins a cluster, a new ClusterView is created, with a new ID. Second, what would this ID be usable for, especially given the relatively short validity/lifetime of it? It does not reflect a stable, persistent identifier of the cluster after all. If you want to learn which other instances are part of the local instance, then the API already provides that access. Comparing this to InstanceDescription.getSlingId(): that one iss by definition the 'slingId' which is retrieved from SettingsService and is thus guaranteed to be stable/persistent. So the API is somewhat inconsistent regarding the ClusterView.getId. I thus suggest getting rid of ClusterView.getId ie marking it as deprecated. (Or, an alternative would be to come up with a stable, persistent clusterId but that is potentially more complex) Wdyt? Cheers, Stefan -- Carsten Ziegeler cziege...@apache.org
Re: JARs in SVN
Afaik this was necessary due to a snapshot dependency on vault while it was not yet released. @Robert, we could get rid of this now, right? Cheers, Stefan On 10/23/13 1:29 AM, Felix Meschberger fmesc...@adobe.com wrote: Hi I just realized that the tooling/ide/vlt-wrapper project stores libraries in SVN. I think this is not a good idea (read it is a bad idea). I suggest these JARs to be removed from SVN and build tooling to be used to get them form Maven Repositories. Thanks Felix
[VOTE] Release Apache Sling discovery.impl 1.0.2
Hi, We solved 4 issues in this release: https://issues.apache.org/jira/browse/SLING/fixforversion/12324866 Staging repository: https://repository.apache.org/content/repositories/orgapachesling-013/ 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 013 /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
Re: [VOTE] Release Apache Sling discovery.impl 1.0.2
Hi Ian, It should be there now. (It was 'in the pipeline somewhere'..) Cheers, Stefan On 11/27/13 2:47 PM, Ian Boston i...@tfd.co.uk wrote: Hi Could you add your signing key to the KEYS file please. Thanks Ian On 27 November 2013 11:59, Amit.. Gupta. amitg...@adobe.com wrote: +1 -Amit -Original Message- From: Stefan Egli [mailto:e...@adobe.com] Sent: 27 November 2013 16:53 To: dev@sling.apache.org Subject: [VOTE] Release Apache Sling discovery.impl 1.0.2 Hi, We solved 4 issues in this release: https://issues.apache.org/jira/browse/SLING/fixforversion/12324866 Staging repository: https://repository.apache.org/content/repositories/orgapachesling-013/ 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 013 /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
Re: [VOTE] Release Apache Sling discovery.impl 1.0.2
My bad. I must have used the wrong one of my two keys for signing. The two keys are at http://pgp.mit.edu:11371/pks/lookup?search=stefanegliop=index I have now added the second one to my apache profile too, where it should appear within a few hours. Or do I revoke and sign again? Cheers, Stefan On 11/29/13 11:20 AM, Bertrand Delacretaz bdelacre...@apache.org wrote: On Wednesday, November 27, 2013, Stefan Egli wrote: ...It should be there now... the release is signed with key DE41359E and I cannot find that key in any of https://people.apache.org/keys/group/sling.asc http://archive.apache.org/dist/sling/KEYS http://pgp.mit.edu/ where should I see it? Apart from that the release looks good to me, checked that the below source release builds fine, release artifacts match the corresponding svn tags and Apache file headers look good. Checked MD5 (org.apache.sling.discovery.impl-1.0.2-source-release.zip) = 6db157b29cb0c7070dc368005c977cf5 Several unit tests take a long time to run, making them integration tests might be convenient as people can then disable them selectively. But that doesn't impact the release. I'll wait for the key clarification before giving it my +1. -Bertrand
[RESULT][VOTE] Release Apache Sling discovery.impl 1.0.2
The vote passed with 4 binding votes from Ian Boston, Felix Meschberger, Bertrand Delacretaz and Mike Müller and one non-binding vote from Amit Gupta. Thanks for voting! I'll go through the remaining steps next. Cheers, Stefan On 11/29/13 4:31 PM, Mike Müller mike...@mysign.ch wrote: +1 best regards mike -Original Message- From: Stefan Egli [mailto:e...@adobe.com] Sent: Wednesday, November 27, 2013 3:03 PM To: dev@sling.apache.org Subject: Re: [VOTE] Release Apache Sling discovery.impl 1.0.2 Hi Ian, It should be there now. (It was 'in the pipeline somewhere'..) Cheers, Stefan On 11/27/13 2:47 PM, Ian Boston i...@tfd.co.uk wrote: Hi Could you add your signing key to the KEYS file please. Thanks Ian On 27 November 2013 11:59, Amit.. Gupta. amitg...@adobe.com wrote: +1 -Amit -Original Message- From: Stefan Egli [mailto:e...@adobe.com] Sent: 27 November 2013 16:53 To: dev@sling.apache.org Subject: [VOTE] Release Apache Sling discovery.impl 1.0.2 Hi, We solved 4 issues in this release: https://issues.apache.org/jira/browse/SLING/fixforversion/12324866 Staging repository: https://repository.apache.org/content/repositories/orgapachesling-013/ 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 013 /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
Re: [ANN] Welcome Tommaso Teofili as a Sling committer!
Bienvenuti, Tommaso! On 1/14/14 9:48 PM, Robert Munteanu romb...@apache.org wrote: Welcome, Tommaso! On Tue, Jan 14, 2014 at 7:15 PM, Felix Meschberger fmesc...@adobe.com wrote: Congratulations, welcome and keep up the good work Tommaso ! Regards Felix Am 14.01.2014 um 07:26 schrieb Tommaso Teofili tommaso.teof...@gmail.com: Thanks a lot to the whole Sling PMC for your trust, I look forward to keep working and having fun in Sling. Regards, Tommaso 2014/1/14 Bertrand Delacretaz bdelacre...@apache.org Hi, Based on his ongoing and valuable contributions, the Apache Sling Project Management Committee (PMC) has voted to invite Tommaso as a Sling committer, and he has accepted the invitation. According to http://people.apache.org/committer-index.html that makes him a committer in *eleven* Apache projects, along with being an ASF member an Incubator PMC member. Thanks Tommaso for your good contributions, keep up the good work! -Bertrand
[CQ on mongo] 2nd startup on mongo runs into endless loop (in register node type)
Hi all, I'm trying to get CQ on mongo running and run into this issue on second startup of the first node (2nd node is stopped at this stage): 17.01.2014 06:40:06.072 *ERROR* [FelixStartLevel] org.apache.sling.jcr.base.internal.loader.Loader Error loading node types SLING-INF/nodetypes/osgiconfig.cnd from bundle org.apache.sling.installer.provider.jcr: javax.jcr.nodetype.ConstraintViolationException: Failed to register node types. 17.01.2014 06:40:06.122 *ERROR* [FelixStartLevel] org.apache.sling.jcr.base.internal.loader.Loader Stacktrace javax.jcr.nodetype.ConstraintViolationException: Failed to register node types. at org.apache.jackrabbit.oak.api.CommitFailedException.asRepositoryException(CommitFailedException.java:225) ~[na:na] at org.apache.jackrabbit.oak.plugins.nodetype.write.ReadWriteNodeTypeManager.registerNodeTypes(ReadWriteNodeTypeManager.java:157) ~[na:na] at org.apache.jackrabbit.commons.cnd.CndImporter.registerNodeTypes(CndImporter.java:162) ~[jackrabbit-jcr-commons-2.7.3.jar:na] at org.apache.sling.jcr.base.NodeTypeLoader.registerNodeType(NodeTypeLoader.java:124) ~[org.apache.sling.jcr.base-2.1.2.jar:na] Anyone seen this? At this stage it seems to do a busy loop 'forever', somewhere near here: at com.google.common.collect.Iterators$5.hasNext(Iterators.java:542) at org.apache.jackrabbit.oak.plugins.memory.EmptyNodeState.compareAgainstEmptyState(EmptyNodeState.java:161) at org.apache.jackrabbit.oak.kernel.KernelNodeState.compareAgainstBaseState(KernelNodeState.java:465) at org.apache.jackrabbit.oak.spi.commit.EditorDiff.childNodeAdded(EditorDiff.java:125) at org.apache.jackrabbit.oak.plugins.memory.EmptyNodeState.compareAgainstEmptyState(EmptyNodeState.java:162) at org.apache.jackrabbit.oak.kernel.KernelNodeState.compareAgainstBaseState(KernelNodeState.java:465) at org.apache.jackrabbit.oak.spi.commit.EditorDiff.childNodeAdded(EditorDiff.java:125) at org.apache.jackrabbit.oak.plugins.memory.EmptyNodeState.compareAgainstEmptyState(EmptyNodeState.java:162) at org.apache.jackrabbit.oak.kernel.KernelNodeState.compareAgainstBaseState(KernelNodeState.java:465) at org.apache.jackrabbit.oak.spi.commit.EditorDiff.childNodeAdded(EditorDiff.java:125) at org.apache.jackrabbit.oak.plugins.memory.EmptyNodeState.compareAgainstEmptyState(EmptyNodeState.java:162) at org.apache.jackrabbit.oak.kernel.KernelNodeState.compareAgainstBaseState(KernelNodeState.java:465) at org.apache.jackrabbit.oak.spi.commit.EditorDiff.childNodeAdded(EditorDiff.java:125) at org.apache.jackrabbit.oak.plugins.memory.EmptyNodeState.compareAgainstEmptyState(EmptyNodeState.java:162) at org.apache.jackrabbit.oak.kernel.KernelNodeState.compareAgainstBaseState(KernelNodeState.java:465) at org.apache.jackrabbit.oak.spi.commit.EditorDiff.childNodeAdded(EditorDiff.java:125) at org.apache.jackrabbit.oak.plugins.memory.ModifiedNodeState$1.childNodeAdded(ModifiedNodeState.java:412) at org.apache.jackrabbit.oak.plugins.memory.EmptyNodeState.compareAgainstEmptyState(EmptyNodeState.java:162) at org.apache.jackrabbit.oak.kernel.KernelNodeState.compareAgainstBaseState(KernelNodeState.java:465) at org.apache.jackrabbit.oak.plugins.memory.ModifiedNodeState.compareAgainstBaseState(ModifiedNodeState.java:393) at org.apache.jackrabbit.oak.spi.commit.EditorDiff.process(EditorDiff.java:52) at org.apache.jackrabbit.oak.plugins.nodetype.TypeEditorProvider.getRootEditor(TypeEditorProvider.java:77) at org.apache.jackrabbit.oak.spi.commit.CompositeEditorProvider.getRootEditor(CompositeEditorProvider.java:79) at org.apache.jackrabbit.oak.spi.commit.EditorHook.processCommit(EditorHook.java:51) at org.apache.jackrabbit.oak.spi.commit.CompositeHook.processCommit(CompositeHook.java:59) at org.apache.jackrabbit.oak.spi.commit.CompositeHook.processCommit(CompositeHook.java:59) at org.apache.jackrabbit.oak.spi.state.AbstractNodeStoreBranch$InMemory.merge(AbstractNodeStoreBranch.java:464) at org.apache.jackrabbit.oak.spi.state.AbstractNodeStoreBranch.merge(AbstractNodeStoreBranch.java:275) at org.apache.jackrabbit.oak.kernel.KernelNodeStoreBranch.merge(KernelNodeStoreBranch.java:142) at org.apache.jackrabbit.oak.kernel.KernelRootBuilder.merge(KernelRootBuilder.java:150) at org.apache.jackrabbit.oak.kernel.KernelNodeStore.merge(KernelNodeStore.java:163) at org.apache.jackrabbit.oak.core.AbstractRoot.commit(AbstractRoot.java:270) at org.apache.jackrabbit.oak.core.AbstractRoot.commit(AbstractRoot.java:260) at org.apache.jackrabbit.oak.plugins.nodetype.write.ReadWriteNodeTypeManager.registerNodeTypes(ReadWriteNodeTypeManager.java:146) Cheers, Stefan
Re: [CQ on mongo] 2nd startup on mongo runs into endless loop (in register node type)
Sorry, wrong list :S From: Stefan Egli e...@adobe.commailto:e...@adobe.com Date: Friday, January 17, 2014 12:48 PM To: dev@sling.apache.orgmailto:dev@sling.apache.org dev@sling.apache.orgmailto:dev@sling.apache.org Subject: [CQ on mongo] 2nd startup on mongo runs into endless loop (in register node type) Hi all, I'm trying to get CQ on mongo running and run into this issue on second startup of the first node (2nd node is stopped at this stage): 17.01.2014 06:40:06.072 *ERROR* [FelixStartLevel] org.apache.sling.jcr.base.internal.loader.Loader Error loading node types SLING-INF/nodetypes/osgiconfig.cnd from bundle org.apache.sling.installer.provider.jcr: javax.jcr.nodetype.ConstraintViolationException: Failed to register node types. 17.01.2014 06:40:06.122 *ERROR* [FelixStartLevel] org.apache.sling.jcr.base.internal.loader.Loader Stacktrace javax.jcr.nodetype.ConstraintViolationException: Failed to register node types. at org.apache.jackrabbit.oak.api.CommitFailedException.asRepositoryException(CommitFailedException.java:225) ~[na:na] at org.apache.jackrabbit.oak.plugins.nodetype.write.ReadWriteNodeTypeManager.registerNodeTypes(ReadWriteNodeTypeManager.java:157) ~[na:na] at org.apache.jackrabbit.commons.cnd.CndImporter.registerNodeTypes(CndImporter.java:162) ~[jackrabbit-jcr-commons-2.7.3.jar:na] at org.apache.sling.jcr.base.NodeTypeLoader.registerNodeType(NodeTypeLoader.java:124) ~[org.apache.sling.jcr.base-2.1.2.jar:na] Anyone seen this? At this stage it seems to do a busy loop 'forever', somewhere near here: at com.google.common.collect.Iterators$5.hasNext(Iterators.java:542) at org.apache.jackrabbit.oak.plugins.memory.EmptyNodeState.compareAgainstEmptyState(EmptyNodeState.java:161) at org.apache.jackrabbit.oak.kernel.KernelNodeState.compareAgainstBaseState(KernelNodeState.java:465) at org.apache.jackrabbit.oak.spi.commit.EditorDiff.childNodeAdded(EditorDiff.java:125) at org.apache.jackrabbit.oak.plugins.memory.EmptyNodeState.compareAgainstEmptyState(EmptyNodeState.java:162) at org.apache.jackrabbit.oak.kernel.KernelNodeState.compareAgainstBaseState(KernelNodeState.java:465) at org.apache.jackrabbit.oak.spi.commit.EditorDiff.childNodeAdded(EditorDiff.java:125) at org.apache.jackrabbit.oak.plugins.memory.EmptyNodeState.compareAgainstEmptyState(EmptyNodeState.java:162) at org.apache.jackrabbit.oak.kernel.KernelNodeState.compareAgainstBaseState(KernelNodeState.java:465) at org.apache.jackrabbit.oak.spi.commit.EditorDiff.childNodeAdded(EditorDiff.java:125) at org.apache.jackrabbit.oak.plugins.memory.EmptyNodeState.compareAgainstEmptyState(EmptyNodeState.java:162) at org.apache.jackrabbit.oak.kernel.KernelNodeState.compareAgainstBaseState(KernelNodeState.java:465) at org.apache.jackrabbit.oak.spi.commit.EditorDiff.childNodeAdded(EditorDiff.java:125) at org.apache.jackrabbit.oak.plugins.memory.EmptyNodeState.compareAgainstEmptyState(EmptyNodeState.java:162) at org.apache.jackrabbit.oak.kernel.KernelNodeState.compareAgainstBaseState(KernelNodeState.java:465) at org.apache.jackrabbit.oak.spi.commit.EditorDiff.childNodeAdded(EditorDiff.java:125) at org.apache.jackrabbit.oak.plugins.memory.ModifiedNodeState$1.childNodeAdded(ModifiedNodeState.java:412) at org.apache.jackrabbit.oak.plugins.memory.EmptyNodeState.compareAgainstEmptyState(EmptyNodeState.java:162) at org.apache.jackrabbit.oak.kernel.KernelNodeState.compareAgainstBaseState(KernelNodeState.java:465) at org.apache.jackrabbit.oak.plugins.memory.ModifiedNodeState.compareAgainstBaseState(ModifiedNodeState.java:393) at org.apache.jackrabbit.oak.spi.commit.EditorDiff.process(EditorDiff.java:52) at org.apache.jackrabbit.oak.plugins.nodetype.TypeEditorProvider.getRootEditor(TypeEditorProvider.java:77) at org.apache.jackrabbit.oak.spi.commit.CompositeEditorProvider.getRootEditor(CompositeEditorProvider.java:79) at org.apache.jackrabbit.oak.spi.commit.EditorHook.processCommit(EditorHook.java:51) at org.apache.jackrabbit.oak.spi.commit.CompositeHook.processCommit(CompositeHook.java:59) at org.apache.jackrabbit.oak.spi.commit.CompositeHook.processCommit(CompositeHook.java:59) at org.apache.jackrabbit.oak.spi.state.AbstractNodeStoreBranch$InMemory.merge(AbstractNodeStoreBranch.java:464) at org.apache.jackrabbit.oak.spi.state.AbstractNodeStoreBranch.merge(AbstractNodeStoreBranch.java:275) at org.apache.jackrabbit.oak.kernel.KernelNodeStoreBranch.merge(KernelNodeStoreBranch.java:142) at org.apache.jackrabbit.oak.kernel.KernelRootBuilder.merge(KernelRootBuilder.java:150) at org.apache.jackrabbit.oak.kernel.KernelNodeStore.merge(KernelNodeStore.java:163) at org.apache.jackrabbit.oak.core.AbstractRoot.commit(AbstractRoot.java:270
[discovery] including commons-net
Hi all, For implementing SLING-3001 I'd like to include apache's commons-net (3.3) as it contains a nice utility for doing CIDR and mask calculations (SubnetUtils). Any objects? Cheers, Stefan
Re: [discovery] including commons-net
Yes, I'm only using that one atm. So inlining sounds like a good idea! Cheers, Stefan On 2/5/14 12:26 PM, Chetan Mehrotra chetan.mehro...@gmail.com wrote: If you are only going to use SubnetUtils [1] then we can possibly inline it in the bundle as it appears to be not depending on any other class in commons-net Chetan Mehrotra [1] https://github.com/apache/commons-net/blob/trunk/src/main/java/org/apache/ commons/net/util/SubnetUtils.java On Wed, Feb 5, 2014 at 4:44 PM, Stefan Egli e...@adobe.com wrote: Just checked. The exports look clean: only org.apache.commons.net.* The imports too: javax.crypto,javax.crypto.spec,javax.net,javax.net.ssl But the size is not tremendously small - it is 280kB.. - but within the range of the other apache's commons-* Cheers, Stefan On 2/5/14 11:53 AM, Bertrand Delacretaz bdelacre...@apache.org wrote: Hi Stefan, On Wed, Feb 5, 2014 at 11:46 AM, Stefan Egli e...@adobe.com wrote: ...For implementing SLING-3001 I'd like to include apache's commons-net (3.3) as it contains a nice utility for doing CIDR and mask calculations (SubnetUtils) What does that mean, is that just a new small bundle with clean package exports/imports? If yes I'm ok with it. -Bertrand
Re: [discovery] including commons-net
On 2/5/14 2:28 PM, Bertrand Delacretaz bdelacre...@apache.org wrote: On Wed, Feb 5, 2014 at 1:22 PM, Stefan Egli e...@adobe.com wrote: Yes, I'm only using that one atm. So inlining sounds like a good idea!... I agree, if it's just one class that might be easier. I embedded that one class for now (in discovery.impl). If we need more classes of commons-net we can still require that entire bundle. Cheers, Stefan
[discovery] different heartbeats for repository vs connectors
Hi, During an offline discussion, Felix brought up the suggestion to lower the topology connector's heartbeat frequency. Currently they are sent every 15 or 30 sec, which might seem a lot - especially as they were way too chatty (which is fixed now with SLING-3377). The main reason for having a high heartbeat frequency is quicker failure detection - but it's obviously a trade-off as it increases load. I would like to get some opinion on to the following proposal: * introduce two different sets of heartbeats, one for repository and one for connectors * the repository ones would remain at the current frequency (suggested default: 30sec interval, 60sec timeout). The idea is that we would want to detect crashes within a cluster rather quickly, more quickly than in the topology in general. * the connectors would get a back-off behavior, where initially the values are the same (30sec/60sec) but then they send out less frequent heartbeats over time, reaching a max (eg 5min). This would have to be controlled by the receiving side, ie both sides of the connector have to agree that interval and timeout are the same. I've opened a Jira to track this, please comment there: https://issues.apache.org/jira/browse/SLING-3382 Thanks, Cheers, Stefan
Re: Sling Topology heartbeat: reduce the amount of repo write activity
What could be done for level 3: a) at startup the behavior is as is today, cluster-ready, writing repository-heartbeats as configured b) this is done for a configured amount of time at least, eg for 5 minutes (exploring phase) - the idea of this being to avoid any race-conditions of two nodes starting simultaneously c) if after this time, the node realizes, that it is alone (and no-one joined or left during this time), it assumes that it is indeed in a standalone setup and stops sending heartbeats (solitude phase) d) if another node starts up in the same cluster, it would as normal start doing these heartbeats for a few minutes (exploring phase) - giving the original node time to wake up to the idea that it was never alone (alien phase) - at which point it quickly starts to go back to sending heartbeats and voting and all those things (party phase) phase d) is obviously slightly tricky .. Cheers, Stefan On 2/7/14 3:00 PM, Stefan Egli e...@adobe.com wrote: Hi, I like the idea of reducing write-bandwidth used by topology. I'd sum it into three possible levels though: 1) keep the (topology-connector) announcement's lastHeartbeat as a separate property and only update that (on receiving a connector-heartbeat) instead of updating the entire announcement-json as is now. 2) we might even be able to not having to store the announcement's lastHeartbeat when the logic is changed, such that the announcement is valid as long as the recipient of the announcement (ie the owner) is alive. This would increase the reaction time on crash of a remote instance longer though. 3) avoid repository (ie cluster-local) heartbeats entirely for the single-node case (in which case keeping the announcement in memory is feasible). I see level 1 as something we should do, level 2 to be further analyzed (verify the implications, but I think it's possible). But I have my reservations re level 3, as this would complicate the 'cluster first' goal: we'd have to detect situations where a single-node is 'suddenly' accompanied by another node to form a cluster, as this would have to be detected by discovery.impl. And I fear that this might in the end-effect again result in some sort of heartbeat (maybe for a limited time after startup only though). Question is, whether it's a problem to have cluster-heartbeats stored every say 30 sec and whether that justifies complicating the algorithm for this case. Cheers, Stefan On 2/7/14 2:44 PM, Jörg Hoh jhoh...@googlemail.com wrote: Hi, I am thinking if we reduce the amount of data persisted in the repository with every topology heartbeat. For example we could just update the timestamp of the of announcement hearbeat, if the topology hasn't changed at all (instead of writing the complete announcement). A more radical approach would be to avoid the persisting of topology information to repo completely, if this node isn't part of a cluster at all. All the state could be kept in memory, and in case of crash/restart the topology needs to gathered again. Of course this would require some more logic in case if a single node is being promoted to a member of an cluster, as then the current behaviour should be used. WDYT? Jörg -- http://cqdump.wordpress.com Twitter: @joerghoh
Re: Sling Topology heartbeat: reduce the amount of repo write activity
I think this is basically what I proposed - except that I would be careful to handle race-conditions with startups/cluster-delays/observation-threading and thus propose to have a period of a few minutes in which it assumes to be in a cluster, and only afterwards switch back if that's not the case. Cheers, Stefan On 2/7/14 3:58 PM, Jörg Hoh jhoh...@googlemail.com wrote: Hi, some ideas regarding the cluster detection: * When a cluster node comes up, it writes it's intial I am here annoucement to the repo. * The node then comes to the listing mode, in which he listens if there's any pong or if a new ping comes in, but here it doesn't write any cluster heartbeat information. * If the node receives a ping or a pong, it knows, that it is running indeed in a cluster (either a new partner joined or the node itself joined a cluster) and then starts up the regular cluster heartbeat. In such a case you wouldn't need to handle the cluster case differently from a single node mode, you don't even have to have a timeout. Jörg 2014-02-07 Stefan Egli e...@adobe.com: What could be done for level 3: a) at startup the behavior is as is today, cluster-ready, writing repository-heartbeats as configured b) this is done for a configured amount of time at least, eg for 5 minutes (exploring phase) - the idea of this being to avoid any race-conditions of two nodes starting simultaneously c) if after this time, the node realizes, that it is alone (and no-one joined or left during this time), it assumes that it is indeed in a standalone setup and stops sending heartbeats (solitude phase) d) if another node starts up in the same cluster, it would as normal start doing these heartbeats for a few minutes (exploring phase) - giving the original node time to wake up to the idea that it was never alone (alien phase) - at which point it quickly starts to go back to sending heartbeats and voting and all those things (party phase) phase d) is obviously slightly tricky .. Cheers, Stefan On 2/7/14 3:00 PM, Stefan Egli e...@adobe.com wrote: Hi, I like the idea of reducing write-bandwidth used by topology. I'd sum it into three possible levels though: 1) keep the (topology-connector) announcement's lastHeartbeat as a separate property and only update that (on receiving a connector-heartbeat) instead of updating the entire announcement-json as is now. 2) we might even be able to not having to store the announcement's lastHeartbeat when the logic is changed, such that the announcement is valid as long as the recipient of the announcement (ie the owner) is alive. This would increase the reaction time on crash of a remote instance longer though. 3) avoid repository (ie cluster-local) heartbeats entirely for the single-node case (in which case keeping the announcement in memory is feasible). I see level 1 as something we should do, level 2 to be further analyzed (verify the implications, but I think it's possible). But I have my reservations re level 3, as this would complicate the 'cluster first' goal: we'd have to detect situations where a single-node is 'suddenly' accompanied by another node to form a cluster, as this would have to be detected by discovery.impl. And I fear that this might in the end-effect again result in some sort of heartbeat (maybe for a limited time after startup only though). Question is, whether it's a problem to have cluster-heartbeats stored every say 30 sec and whether that justifies complicating the algorithm for this case. Cheers, Stefan On 2/7/14 2:44 PM, Jörg Hoh jhoh...@googlemail.com wrote: Hi, I am thinking if we reduce the amount of data persisted in the repository with every topology heartbeat. For example we could just update the timestamp of the of announcement hearbeat, if the topology hasn't changed at all (instead of writing the complete announcement). A more radical approach would be to avoid the persisting of topology information to repo completely, if this node isn't part of a cluster at all. All the state could be kept in memory, and in case of crash/restart the topology needs to gathered again. Of course this would require some more logic in case if a single node is being promoted to a member of an cluster, as then the current behaviour should be used. WDYT? Jörg -- http://cqdump.wordpress.com Twitter: @joerghoh -- Cheers, Jörg Hoh, http://cqdump.wordpress.com Twitter: @joerghoh
[discovery] test problems with discovery.impl
Hi, There are currently quite a few test runs (on [0] and [1]) failing due to discovery.impl - most likely due to timing changes in r1569389 (SLING-3382). I've turned redirectTestOutputToFile in discovery.impl/pom.xml back to false to be able to see better what's going on. This is causing the output of a build to be rather large. I'll put it back to true as soon as I managed to make those tests stable again. Unless someone knows how to access the surefire log output files on those two ci environments.. Cheers, Stefan -- [0] - http://ci.apache.org/builders/sling-trunk [1] - https://travis-ci.org/apache/sling/builds
[travis-ci] build failures
Hi, At the moment sling-trunk build is failing on travis ([0]) rather consistently with two kinds of problems: * the jdk7 build fails with: Cheers, Stefan -- [0] - https://travis-ci.org/apache/sling
Re: [travis-ci] build failures
That mail clearly left my outbox too early ;) again: Hi, At the moment sling-trunk build is failing on travis ([0]) rather consistently with two kinds of problems: 1. the jdk7 build fails with: [ERROR] Failed to execute goal org.apache.sling:maven-launchpad-plugin:2.2.0:prepare-package (prepare-package) on project org.apache.sling.launchpad.testing-war: Unable to copy configuration files: Source '/home/travis/build/apache/sling/launchpad/testing-war/src/main/config' does not exist - [Help 1] 2. the jdk8 build fails with: java.lang.OutOfMemoryError: PermGen space Any idea why they both run fine on [1] ? Re 2 I guess increasing memory might be an idea.. Cheers, Stefan -- [0] - https://travis-ci.org/apache/sling [1] - http://ci.apache.org/builders/sling-trunk From: Stefan Egli e...@adobe.commailto:e...@adobe.com Date: Saturday, March 1, 2014 7:15 PM To: dev@sling.apache.orgmailto:dev@sling.apache.org dev@sling.apache.orgmailto:dev@sling.apache.org Subject: [travis-ci] build failures Hi, At the moment sling-trunk build is failing on travis ([0]) rather consistently with two kinds of problems: * the jdk7 build fails with: Cheers, Stefan -- [0] - https://travis-ci.org/apache/sling
Re: [travis-ci] build failures
Hi Robert, On 3/1/14 10:22 PM, Robert Munteanu rob...@lmn.ro wrote: Hi Stefan, On Sat, Mar 1, 2014 at 8:19 PM, Stefan Egli e...@adobe.com wrote: That mail clearly left my outbox too early ;) again: Hi, At the moment sling-trunk build is failing on travis ([0]) rather consistently with two kinds of problems: 1. the jdk7 build fails with: [ERROR] Failed to execute goal org.apache.sling:maven-launchpad-plugin:2.2.0:prepare-package (prepare-package) on project org.apache.sling.launchpad.testing-war: Unable to copy configuration files: Source '/home/travis/build/apache/sling/launchpad/testing-war/src/main/config' does not exist - [Help 1] I _think_ that since the the travis build runs over git, it does not have an empty 'config' directory. But that's just a guess. Looks like as we're using maven-launchpad-plugin 2.2.0, the fix for SLING-2843 (which is exactly about the above) is not yet contained. So maybe we should release maven-launchpad-plugin 2.2.1 to get the war integration tests functioning again? (It fails also on my local box btw, I think buildbot [1] just doesn't run the -PwarIntegrationTests profile) 2. the jdk8 build fails with: java.lang.OutOfMemoryError: PermGen space JDK 8 removed the PermGen, which means that we need a larger heap. As to why the difference between buildbot and travis, perhaps they run on different architectures? Ok, how/who can configure more memory? btw: just realized, buildbot [1] runs jdk6 of course.. Cheers, Stefan Robert Any idea why they both run fine on [1] ? Re 2 I guess increasing memory might be an idea.. Cheers, Stefan -- [0] - https://travis-ci.org/apache/sling [1] - http://ci.apache.org/builders/sling-trunk From: Stefan Egli e...@adobe.commailto:e...@adobe.com Date: Saturday, March 1, 2014 7:15 PM To: dev@sling.apache.orgmailto:dev@sling.apache.org dev@sling.apache.orgmailto:dev@sling.apache.org Subject: [travis-ci] build failures Hi, At the moment sling-trunk build is failing on travis ([0]) rather consistently with two kinds of problems: * the jdk7 build fails with: Cheers, Stefan -- [0] - https://travis-ci.org/apache/sling -- Sent from my (old) computer
Re: [travis-ci] build failures
On 3/2/14 12:14 PM, Stefan Egli e...@adobe.com wrote: 1. the jdk7 build fails with: [ERROR] Failed to execute goal org.apache.sling:maven-launchpad-plugin:2.2.0:prepare-package (prepare-package) on project org.apache.sling.launchpad.testing-war: Unable to copy configuration files: Source '/home/travis/build/apache/sling/launchpad/testing-war/src/main/config' does not exist - [Help 1] I _think_ that since the the travis build runs over git, it does not have an empty 'config' directory. But that's just a guess. Looks like as we're using maven-launchpad-plugin 2.2.0, the fix for SLING-2843 (which is exactly about the above) is not yet contained. So maybe we should release maven-launchpad-plugin 2.2.1 to get the war integration tests functioning again? added an empty src/main/config - see https://issues.apache.org/jira/browse/SLING-3425 Cheers, Stefan
[buildbot] models.it.RemoteIT fails
Hi, Currently the builds are failing on buildbot with the following details: Tests run: 2, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 55.23 sec FAILURE! test(org.apache.sling.models.it.ViaTest)(org.apache.sling.models.it.RemoteIT) Time elapsed: 0.004 sec FAILURE! java.lang.AssertionError: test(org.apache.sling.models.it.ViaTest): org/apache/commons/beanutils/NestedNullException at org.apache.sling.junit.remote.testrunner.SlingRemoteTest.run(SlingRemoteTest.java:44) at org.apache.sling.junit.remote.testrunner.SlingRemoteTestRunner.runChild(SlingRemoteTestRunner.java:157) at org.apache.sling.junit.remote.testrunner.SlingRemoteTestRunner.runChild(SlingRemoteTestRunner.java:45) at org.junit.runners.ParentRunner$3.run(ParentRunner.java:238) at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:63) at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:236) at org.junit.runners.ParentRunner.access$000(ParentRunner.java:53) at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:229) at org.junit.runners.ParentRunner.run(ParentRunner.java:309) at org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:252) at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:141) at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:112) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:622) at org.apache.maven.surefire.util.ReflectionUtils.invokeMethodWithArray(ReflectionUtils.java:189) at org.apache.maven.surefire.booter.ProviderFactory$ProviderProxy.invoke(ProviderFactory.java:165) at org.apache.maven.surefire.booter.ProviderFactory.invokeProvider(ProviderFactory.java:85) at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:115) at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:75) http://ci.apache.org/builders/sling-trunk/builds/378/steps/compile/logs/stdio I'm not too familiar with this integrationtest, does it run with/require a particular profile? Cheers, Stefan
[travis-ci] failure due to snapshot dependency
Hi, Currently the travis build [0] fails due to a SNAPSHOT dependency on maven-launchpad-plugin:2.3.1-SNAPSHOT, which it doesn't seem to build/install on that box. Did that work earlier though I wonder - and how can we automatically get that snapshot built on travis? $ mvn -q clean install -DobrRepository=false -DHttpTestBase.readyTimeoutSeconds=300 -PwarIntegrationTests -PintegrationTests [ERROR] The build could not read 1 project - [Help 1] [ERROR] [ERROR] The project org.apache.sling:org.apache.sling.launchpad.testing:7-SNAPSHOT (/home/travis/build/apache/sling/launchpad/testing/pom.xml) has 1 error [ERROR] Unresolveable build extension: Plugin org.apache.sling:maven-launchpad-plugin:2.3.1-SNAPSHOT or one of its dependencies could not be resolved: Could not find artifact org.apache.sling:maven-launchpad-plugin:jar:2.3.1-SNAPSHOT in apache.snapshots (http://repository.apache.org/snapshots) - [Help 2] Cheers, Stefan -- [0] - https://travis-ci.org/apache/sling/jobs/20048065#L24
Re: [travis-ci] failure due to snapshot dependency
Hi, Yes, locally I can get that fixed. The problem is on travis-ci - which I don't have admin rights to fiddle with.. Cheers, Stefan On 3/4/14 7:38 PM, Stefan Scheidewig tha...@eknet.org wrote: Hi, I had this problem, too. I supposed that this plugin is not uploaded to the plugin repository (according to the repository mentioned in http://people.apache.org/repo/m2-incubating-repository). Maybe it is uploaded after a successful build and there weren't many in the last time :) . You can build the plugin under tooling/maven/maven-launchpad-plugin and the build will work/go on. Cheers, Stefan Am Dienstag, 4. März 2014 14:45:43 schrieb Stefan Egli: Hi, Currently the travis build [0] fails due to a SNAPSHOT dependency on maven-launchpad-plugin:2.3.1-SNAPSHOT, which it doesn't seem to build/install on that box. Did that work earlier though I wonder - and how can we automatically get that snapshot built on travis? $ mvn -q clean install -DobrRepository=false -DHttpTestBase.readyTimeoutSeconds=300 -PwarIntegrationTests -PintegrationTests [ERROR] The build could not read 1 project - [Help 1] [ERROR] [ERROR] The project org.apache.sling:org.apache.sling.launchpad.testing:7-SNAPSHOT (/home/travis/build/apache/sling/launchpad/testing/pom.xml) has 1 error [ERROR] Unresolveable build extension: Plugin org.apache.sling:maven-launchpad-plugin:2.3.1-SNAPSHOT or one of its dependencies could not be resolved: Could not find artifact org.apache.sling:maven-launchpad-plugin:jar:2.3.1-SNAPSHOT in apache.snapshots (http://repository.apache.org/snapshots) - [Help 2] Cheers, Stefan -- [0] - https://travis-ci.org/apache/sling/jobs/20048065#L24
[VOTE] Release Apache Sling discovery.impl 1.0.6
Hi, We solved 1 issue in this release: https://issues.apache.org/jira/browse/SLING/fixforversion/12326448 Staging repository: https://repository.apache.org/content/repositories/orgapachesling-1044/ 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 1044 /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. My (new) public key is on its way to https://people.apache.org/keys/group/sling.asc but can already be verified here: http://pgp.mit.edu/pks/lookup?op=vindexsearch=0x0C18A8201E60C54E Cheers, Stefan
Re: Status Sling IDE Tooling
Hi Konrad, On 3/31/14 12:14 PM, Robert Munteanu rob...@lmn.ro wrote: Hi Konrad, On Mon, Mar 31, 2014 at 12:59 PM, Konrad Windszus konra...@gmx.de wrote: Hi everyone, what is the status around the Sling IDE Tooling [0]? There was no commit for a pretty long time there [2]. At the adaptTo 2013 there was a roadmap presented [1], but nothing happened basically in the last 5 months. Could you give a short update on that? I hope to get more time in the coming weeks to stabilize the codebase and release a 1.0 version. Same here. Cheers, Stefan Robert Thanks, Konrad [0] - https://cwiki.apache.org/confluence/display/SLING/Sling+IDE+tooling+Roadm ap [1] - http://www.slideshare.net/rombertw/sling-ide-tooling-adaptto-2013 [2] - https://github.com/apache/sling/tree/trunk/tooling/ide -- Sent from my (old) computer
Re: [VOTE] Release Apache Sling discovery.impl 1.0.6
ping, 1 binding vote is missing here. Thanks, Cheers, Stefan On 3/27/14 4:33 PM, Stefan Egli e...@adobe.com wrote: Hi, We solved 1 issue in this release: https://issues.apache.org/jira/browse/SLING/fixforversion/12326448 Staging repository: https://repository.apache.org/content/repositories/orgapachesling-1044/ 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 1044 /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. My (new) public key is on its way to https://people.apache.org/keys/group/sling.asc but can already be verified here: http://pgp.mit.edu/pks/lookup?op=vindexsearch=0x0C18A8201E60C54E Cheers, Stefan
Re: [VOTE] Release Apache Sling discovery.impl 1.0.6
anyone? Cheers, Stefan On 3/31/14 9:37 PM, Stefan Egli stefane...@apache.org wrote: ping, 1 binding vote is missing here. Thanks, Cheers, Stefan On 3/27/14 4:33 PM, Stefan Egli e...@adobe.com wrote: Hi, We solved 1 issue in this release: https://issues.apache.org/jira/browse/SLING/fixforversion/12326448 Staging repository: https://repository.apache.org/content/repositories/orgapachesling-1044/ 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 1044 /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. My (new) public key is on its way to https://people.apache.org/keys/group/sling.asc but can already be verified here: http://pgp.mit.edu/pks/lookup?op=vindexsearch=0x0C18A8201E60C54E Cheers, Stefan
[VOTE RESULT] Release Apache Sling discovery.impl 1.0.6
The vote passed with three binding +1 votes from Carsten Ziegeler, Bertrand Delacretaz and Justin Edelson, and no other votes. Thanks for voting, Cheers, Stefan
Re: [VOTE RESULT] Release Apache Sling discovery.impl 1.0.6
thanks! Stefan On 4/4/14 11:08 AM, Carsten Ziegeler cziege...@apache.org wrote: I've pushed that version to the dist directory. Carsten 2014-04-04 11:01 GMT+02:00 Stefan Egli e...@adobe.com: The vote passed with three binding +1 votes from Carsten Ziegeler, Bertrand Delacretaz and Justin Edelson, and no other votes. Thanks for voting, Cheers, Stefan -- Carsten Ziegeler cziege...@apache.org
[VOTE] Release Apache Sling Event Support 3.3.8
Hi, We solved 1 ticketed issue: * https://issues.apache.org/jira/browse/SLING/fixforversion/12326345 plus 2 un-ticketed issues in this release: * updated to parent pom v19 http://svn.apache.org/viewvc/sling/trunk/bundles/extensions/event/pom.xml?r 1=1573922r2=1583337pathrev=1585871 * corrected annotation error because of spare commas http://svn.apache.org/viewvc/sling/trunk/bundles/extensions/event/src/main/ java/org/apache/sling/event/impl/jobs/JobManagerImpl.java?r1=1569737r2=157 8137pathrev=1585871 Staging repository: https://repository.apache.org/content/repositories/orgapachesling-1047/ 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 1047 /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
[CANCELL][VOTE] Release Apache Sling Event Support 3.3.8
Hi, This vote is cancelled. Reasons: * not enough +1 votes in time * new bugfix requiring release of 3.3.10 encountered * new vote re 3.3.10 will be sent out in a minute Cheers, Stefan On 4/10/14 10:17 AM, Stefan Egli e...@adobe.com wrote: Hi, We solved 1 ticketed issue: * https://issues.apache.org/jira/browse/SLING/fixforversion/12326345 plus 2 un-ticketed issues in this release: * updated to parent pom v19 http://svn.apache.org/viewvc/sling/trunk/bundles/extensions/event/pom.xml? r 1=1573922r2=1583337pathrev=1585871 * corrected annotation error because of spare commas http://svn.apache.org/viewvc/sling/trunk/bundles/extensions/event/src/main / java/org/apache/sling/event/impl/jobs/JobManagerImpl.java?r1=1569737r2=15 7 8137pathrev=1585871 Staging repository: https://repository.apache.org/content/repositories/orgapachesling-1047/ 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 1047 /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
[VOTE] Release Apache Sling Event Support 3.3.10
Hi, Since 3.3.8 was cancelled, this vote is about cumulative release 3.3.10, which includes the following changes: * 3.3.10: fix for https://issues.apache.org/jira/browse/SLING-3502 * 3.3.8: 1 issue: * https://issues.apache.org/jira/browse/SLING/fixforversion/12326345 * 3.3.8: plus 2 un-ticketed issues in this release: * updated to parent pom v19 http://svn.apache.org/viewvc/sling/trunk/bundles/extensions/event/pom.xml?r 1=1573922r2=1583337pathrev=1585871 * corrected annotation error because of spare commas http://svn.apache.org/viewvc/sling/trunk/bundles/extensions/event/src/main/ java/org/apache/sling/event/impl/jobs/JobManagerImpl.java?r1=1569737r2=157 8137pathrev=1585871 Staging repository: https://repository.apache.org/content/repositories/orgapachesling-1049/ 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 1049 /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
Re: [VOTE] Release Apache Sling Event Support 3.3.10
One more missing here.. Cheers, Stefan On 4/17/14 9:09 AM, Carsten Ziegeler cziege...@apache.org wrote: +1 2014-04-17 8:52 GMT+02:00 Carsten Ziegeler cziege...@apache.org: +1 2014-04-16 17:16 GMT+02:00 Justin Edelson jus...@justinedelson.com: +1 On Wed, Apr 16, 2014 at 10:40 AM, Stefan Egli e...@adobe.com wrote: Hi, Since 3.3.8 was cancelled, this vote is about cumulative release 3.3.10, which includes the following changes: * 3.3.10: fix for https://issues.apache.org/jira/browse/SLING-3502 * 3.3.8: 1 issue: * https://issues.apache.org/jira/browse/SLING/fixforversion/12326345 * 3.3.8: plus 2 un-ticketed issues in this release: * updated to parent pom v19 http://svn.apache.org/viewvc/sling/trunk/bundles/extensions/event/pom.xm l?r 1=1573922r2=1583337pathrev=1585871 * corrected annotation error because of spare commas http://svn.apache.org/viewvc/sling/trunk/bundles/extensions/event/src/ma in/ java/org/apache/sling/event/impl/jobs/JobManagerImpl.java?r1=1569737r2= 157 8137pathrev=1585871 Staging repository: https://repository.apache.org/content/repositories/orgapachesling-1049/ 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 1049 /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 -- Carsten Ziegeler cziege...@apache.org -- Carsten Ziegeler cziege...@apache.org
[VOTE] Release Apache Sling discovery.impl 1.0.8
Hi, We solved 1 issue in this release: https://issues.apache.org/jira/browse/SLING/fixforversion/12326702 Staging repository: https://repository.apache.org/content/repositories/orgapachesling-1050/ 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 1050 /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
[VOTE RESULT] Release Apache Sling Event Support 3.3.10
Vote passed with three binding +1 votes from Justin Edelson, Carsten Ziegeler and Bertrand Delacretaz. Cheers, Stefan
Re: [VOTE] Release Apache Sling discovery.impl 1.0.8
Hi, We'd need one more binding vote here. Thanks, Stefan On 4/22/14 12:19 PM, Stefan Egli e...@adobe.com wrote: Hi, We solved 1 issue in this release: https://issues.apache.org/jira/browse/SLING/fixforversion/12326702 Staging repository: https://repository.apache.org/content/repositories/orgapachesling-1050/ 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 1050 /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
[VOTE RESULT] Release Apache Sling discovery.impl 1.0.8
Vote passed with three binding +1 votes, from Carsten Ziegeler, Justin Edelson and Ian Boston. Thanks, Stefan
Re: Sling Discovery implementation on AWS S3
I'd agree with Chetan and Ian here in that S3 sounds feasible for persisting properties in a topology (rather than relying on the non-persistent nature of discovery-properties). The implementation of discovery itself I see as a separate discussion. Cheers, Stefan On 5/12/14 1:00 PM, Chetan Mehrotra chetan.mehro...@gmail.com wrote: If the usecase is only for Discovery it might be simpler to run Apache Zookeeper [1] and use Apache Curator [2] as noted in SLING-2939. While running on AWS one can possibly use Netflix Exhibitor [3] which manages the Zookeeper instances and backup there state in S3. The benefit of this approach is that Zookeeper abstract out all the complexities of leader election (which is hard!) and can also be used in on prem installation if required Chetan Mehrotra [1] http://zookeeper.apache.org/ [2] http://curator.apache.org/ [3] https://github.com/Netflix/exhibitor On Mon, May 12, 2014 at 2:54 PM, Timothée Maret timothee.ma...@gmail.com wrote: Hi, 2014-05-12 9:02 GMT+01:00 Ian Boston i...@tfd.co.uk: Hi, +1 for distribution of properties via S3, makes perfect sense. Perhaps abstracting behind an API so that any low latency globally distributed storage provider could be used. Yes, discussing this offline with Felix, an alternative could be to implement a ResourceProvider for S3. S3 is really low level (key-value pair) with objects being binaries + metadata. We could implement the path structure based on the prefix property in [3] and stick to storing binaries only so that other S3 consumers can access the data directly (without using a Sling API). Not sure about discovery. Although [0] described the AWS VM, it doesn't, without further validation describe if the Sling instance is running and available. Its perfectly possible for the VM to be in a running state, with no viable Sling instance running. I dont think that hard to achieve but it needs to be done to support the discovery use case. Exactly, ootb, the AWS API has no concept of Sling instance and we should implement it. According to [2] we could *not* leverage instance metadata since they can't be modified at runtime. Thus, we would need to have The Sling instances publish their state in S3. I think we are talking about instances running on independent repositories here, since if all instances share the same repository (ie are a Jackrabbit cluster), then the repository already has a mechanism of communicating running instances via the repository. +1 Best Regards Ian On 12 May 2014 07:06, Carsten Ziegeler cziege...@apache.org wrote: Hi Timotheé, yes I think this is valuable - the idea of the discovery API is to abstract the discovery and if we can benefit in certain scenarios from already available mechanism/information I think it makes totally sense to use that instead of adding the same on top of it. Right now, the topology is formed of clusters containing instances - where all instances in a cluster share the same repository, but instances in different clusters use a different one. Is this kind of topology somehow possible by using the AWS API? Or would all instances end up in a single cluster? Regards Carsten 2014-05-11 18:54 GMT+02:00 Timothée Maret timothee.ma...@gmail.com: Hi, I would like to discuss a potential implementation of the Sling Discovery APIs over an eventually consistent distributed storages such as AWS S3. Assuming the instances being part of the topology runs in AWS, then we could leverage AWS APIs and service in order to implement the Discovery mechanism. The discovery of instances could be implemented implicitely using EC2 REST API [0] without sending heartbeats, the properties for each instance could be stored in AWS S3 and distributed eventually, the leader election could be implemented with [1] or similar. The benefits (over Sling impl) would be * Arguably the highest availablity we can get from the environment * Reduced bandwith consumption (no hearthbeats) * Environment specific informations is implicitely distributed (local ip, external ip, hostname, region, etc.) Of course, it would bind the implementation to an environment (AWS in this case), however I believe we could apply the same mechanism to other eventually consistent storage. Wdyt ? Is this something that would be valuable for Sling ? Regards, Timothee [0] http://docs.aws.amazon.com/AWSEC2/latest/APIReference/ApiReference-query -DescribeInstances.html [1] http://gsyc.es/~anto/papers/2007-dsn.pdf -- Carsten Ziegeler cziege...@apache.org Regards Timothee [2] http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/AESDG-chapter-instance data.html [3] http://docs.aws.amazon.com/AmazonS3/latest/API/RESTBucketGET.html
[jira] jira (notifications) down?
Hi, It looks like jira notification mails are currently not sent or is this only for me? Cheers, Stefan
Re: [VOTE] Release Apache Sling IDE Tooling 1.0.0
+1 (verified md5 sha1 using the check_staged_release.sh) Cheers, Stefan On 7/1/14 8:34 AM, Carsten Ziegeler cziege...@apache.org wrote: Thanks for redoing, Robert. +1 Carsten 2014-07-01 2:01 GMT+02:00 Justin Edelson jus...@justinedelson.com: +1 On Mon, Jun 30, 2014 at 12:14 PM, Robert Munteanu rob...@lmn.ro wrote: I think I've gotten the right Maven/Tycho incantations set up and deployed the 1.0.0 artifacts to https://repository.apache.org/content/repositories/orgapachesling-1072/ The single compromise that I had to make is that the integration tests were not included in the reactor build and therefore not deployed to the nexus repo. Hopefully that's acceptable for the release. I can restart the release vote if needed ( third time's the charm? ) but it would be good to know that I got things right this time. Note: check_staged_release.sh took about 30 minutes to complete for me. Thanks, Robert On Mon, Jun 30, 2014 at 1:53 PM, Carsten Ziegeler cziege...@apache.org wrote: Thanks for the info, Robert - I'm not sure what the best approach is, however the zip now contains 1.0.0-SNAPSHOT as versions but I guess the final release should be 1.0.0. This would mean we're voting on something which is then not released. On the other hand, if we put up 1.0.0 in a globally available space everyone can simply download it from there and voting, especially withdrawing the release is way harder. Carsten 2014-06-30 10:06 GMT+02:00 Robert Munteanu romb...@apache.org: Hi Carsten, On Mon, Jun 30, 2014 at 8:57 AM, Carsten Ziegeler cziege...@apache.org wrote: Why is this release not following the normal release procedure and available via the staging maven repo? There are two main reasons. 1. While the build is driven by Maven, building Eclipse plug-ins with Tycho means that some of the regular Maven plugins don't work. For instance, the source and javadoc plugin, see [1],[2] . Since IIUC the release is based on the source code, and the binaries are just for convenience, I opted not to make the release run on the output of individual projects, but on the whole source zip. 2. If I were to deploy the plug-ins by themselves to the repo, it would not be trivial to assemble back an p2/Eclipse update which can be used to test the functionality of the release. That being said, I'd be more than happy to refine this process, so suggestions on how to do that are welcome :-) Thanks, Robert [1]: https://dev.eclipse.org/mhonarc/lists/tycho-user/msg05730.html [2]: https://bugs.eclipse.org/bugs/show_bug.cgi?id=398061 Carsten 2014-06-29 21:32 GMT+02:00 Robert Munteanu romb...@apache.org: Anyone? Robert On Thu, Jun 26, 2014 at 11:32 AM, Robert Munteanu romb...@apache.org wrote: Hi, We solved 144 issues in this release: https://issues.apache.org/jira/browse/SLING/fixforversion/12324873 There are still some outstanding issues: https://issues.apache.org/jira/browse/SLING/component/12320908 The release candidate has been uploaded at https://dist.apache.org/repos/dist/dev/sling, and can be built using mvn clean package The resulting binaries can be installed into an Eclipse instance by installing from the update site which is found at p2update/target/repository after building the project. 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. -- Carsten Ziegeler Adobe Research Switzerland cziege...@apache.org -- Carsten Ziegeler Adobe Research Switzerland cziege...@apache.org -- Sent from my (old) computer -- Carsten Ziegeler Adobe Research Switzerland cziege...@apache.org
Re: adaptTo and results ....
I like the idea too, but I guess it's merely a question of taste as to which of the following two options is nicer: * Foo f = someObject.adaptTo(RequireAdapterFoo.class)); * Foo f = someObject.adaptToUnchecked(Foo.class); Cheers, Stefan On 7/1/14 11:57 AM, Konrad Windszus konra...@gmx.de wrote: I like that approach. It is backwards-compatible and allows the developers to decide whether they want to check for null or to rely on exceptions. The AdapterManagerImpl indeed would need to deal with such a parametrisation and in addition the javadocs would need to be adjusted to make it clear that AdapterFactories may throw RuntimeExceptions. Those exceptions should be caught by the AdapterManagerImpl when the RequireAdapter was not requested and in the other case just passed along. On 01 Jul 2014, at 09:44, Bertrand Delacretaz bdelacre...@apache.org wrote: On Tue, Jul 1, 2014 at 9:41 AM, Bertrand Delacretaz bdelacre...@apache.org wrote: ...how about this: Foo f = someObject.adaptTo(RequireAdapter.for(Foo.class)); Actually, rereading SLING-3714, this can be made simpler with generics Foo f = someObject.adaptTo(RequireAdapterFoo.class)); where RequireAdapter causes AdapterManagerImpl to wrap the adapters to throw an exception if adaption returns null. -Bertrand
Re: [VOTE] Include ide tooling source bundle on dist.apache.org
+1 On 7/8/14 4:28 PM, Robert Munteanu romb...@apache.org wrote: Hi, As Bertrand has noticed [1], the Sling IDE Tooling 1.0.0 release does not include a source bundle on dist.apache.org . Following that discussion, I propose that we upload a source bundle at https://dist.apache.org/repos/dist/release/sling/eclipse/1.0.0/ . The source bundle is a plain SVN export from the tag used to generate the 1.0.0 release. The candidate source bundle is uploaded at [2] . It can be used to rebuild the IDE tooling with mvn clean package Please vote to approve this inclusion. Thanks, Robert [1]: http://markmail.org/thread/hgxbejjrmn4wrpsv [2]: https://people.apache.org/~rombert/sling/sling-ide-tooling-1.0.0/
[R4R] SLING-3760 / improvements for rerunning serverside tests
Hi, [Request for Review] I've just created SLING-3760 and attached a patch and would appreciate if someone could review this. Details in the ticket. Thanks! Cheers, Stefan -- https://issues.apache.org/jira/browse/SLING-3760
[VOTE] Release Apache Sling Test Tools 1.0.8
Hi, We solved 8 issues in this release: https://issues.apache.org/jira/browse/SLING/fixforversion/12324063 Staging repository: https://repository.apache.org/content/repositories/orgapachesling-1082/ 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 1082 /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
Re: [VOTE] Release Apache Sling Test Tools 1.0.8
Thx for pointing out. Moved the ticket. Cheers, Stefan On 7/15/14 11:36 AM, Robert Munteanu romb...@apache.org wrote: +1 BTW, https://issues.apache.org/jira/browse/SLING-3343 is targeted for the 1.0.8 release but not resolved. It should be moved to another target version I guess. Robert On Tue, Jul 15, 2014 at 11:23 AM, Stefan Egli stefane...@apache.org wrote: Hi, We solved 8 issues in this release: https://issues.apache.org/jira/browse/SLING/fixforversion/12324063 Staging repository: https://repository.apache.org/content/repositories/orgapachesling-1082/ 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 1082 /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
[Followup] Issue using PUT with maven-sling-plugin and non-existent path
Hi, [0] discusses the issue with the maven-sling-plugin not being able to deploy when the target path does not exist. Has that been fixed in some form in the meantime? I can't manage to find a fixed related ticket.. Cheers, Stefan -- [0] - http://markmail.org/thread/jkikgulxhl4e5uqo
Re: Proposal for Sling IDE Tooling release process
On 7/21/14 1:38 PM, Robert Munteanu romb...@apache.org wrote: ... On Sun, Jul 20, 2014 at 11:12 AM, Felix Meschberger fmesc...@adobe.com wrote: ... https://dist.apache.org/repos/dist/dev/sling/ which you already seem to have been using. I suggest to upload the full release candidate there and vote upon it. Once done it can be svn cp-ed over to the appropriate release/sling folder. To ease the process you might create a IDE-tooling-$VERSION folder in dev/sling to make it easy to find the artifacts to vote. This way, we have everything in one place and can also have people test the release binaries along with the sources. Also we don't have the hassle of creating and dropping a repo on repository.apache.org. WDYT ? Sounds good to me. I will to use this approach for the next release, unless someone thinks otherwise. +1 Cheers, Stefan
[RESULT] [VOTE] Release Apache Sling Test Tools 1.0.8
Hi, The vote has passed with the following result: +1 (binding) : Robert Munteanu, Bertrand Delacretaz, Daniel Klco, Carsten Ziegeler +1 (non-binding) : Davide Giannella I'll take care of the remaining steps Cheers, Stefan
obr/sling.xml
Hi, I just tried to follow the release process steps and noticed when updating the obr/sling.xml, that it hasn't been done so for quite a while (2.5 years). So I'm not sure what the idea with this is, but I guess we should update it. Also, when trying to do a 'svn up' on people.apache.org, I got the following: stefanegli@minotaur:/x1/www/sling.apache.org/content/obr$ svn up svn: E155004: Working copy '/x1/www/sling.apache.org/content' locked svn: E200031: sqlite: attempt to write a readonly database svn: E200031: sqlite: attempt to write a readonly database svn: run 'svn cleanup' to remove locks (type 'svn help cleanup' for details) I'm uncertain if doing a 'svn cleanup' there does not have any side-effects.. :S Anyone familiar with the setup there? Cheers, Stefan
Re: [VOTE] Release Apache Sling IDE Tooling 1.0.2
+1 (verified source.jar can be built via 'mvn clean install' - installed in local eclipse and smoke-tested) Cheers, Stefan On 7/22/14 3:16 PM, Robert Munteanu romb...@apache.org wrote: Hi, We solved 20 issues in this release: https://issues.apache.org/jira/browse/SLING/fixforversion/12327150 There are still some outstanding issues: https://issues.apache.org/jira/browse/SLING/component/12320908 The release candidate has been uploaded at https://dist.apache.org/repos/dist/dev/sling, The release artifact is the source bundle - sling-ide-tooling-1.0.2.jar - which can be used to build the project using mvn clean package The resulting binaries can be installed into an Eclipse instance from from the update site which is found at p2update/target/repository after building the project. For convenience, a pre-built update site - org.apache.sling.ide.p2update-1.0.2.zip - has also been uploaded. 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 Thanks, Robert
Re: [VOTE] Release Apache Sling IDE Tooling 1.0.2
I think what might me missing is an SVN tag for the release? Or am I just not finding it :S Cheers, Stefan On 7/22/14 5:31 PM, Stefan Egli stefane...@apache.org wrote: +1 (verified source.jar can be built via 'mvn clean install' - installed in local eclipse and smoke-tested) Cheers, Stefan On 7/22/14 3:16 PM, Robert Munteanu romb...@apache.org wrote: Hi, We solved 20 issues in this release: https://issues.apache.org/jira/browse/SLING/fixforversion/12327150 There are still some outstanding issues: https://issues.apache.org/jira/browse/SLING/component/12320908 The release candidate has been uploaded at https://dist.apache.org/repos/dist/dev/sling, The release artifact is the source bundle - sling-ide-tooling-1.0.2.jar - which can be used to build the project using mvn clean package The resulting binaries can be installed into an Eclipse instance from from the update site which is found at p2update/target/repository after building the project. For convenience, a pre-built update site - org.apache.sling.ide.p2update-1.0.2.zip - has also been uploaded. 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 Thanks, Robert
Re: [VOTE] Release Apache Sling IDE Tooling 1.0.2
okeee :) On 7/22/14 5:56 PM, Robert Munteanu rob...@lmn.ro wrote: On Tue, Jul 22, 2014 at 6:55 PM, Stefan Egli stefane...@apache.org wrote: I think what might me missing is an SVN tag for the release? Or am I just not finding it :S The release is tagged at https://svn.apache.org/repos/asf/sling/tags/sling-ide-tooling-1.0.2/ Robert Cheers, Stefan On 7/22/14 5:31 PM, Stefan Egli stefane...@apache.org wrote: +1 (verified source.jar can be built via 'mvn clean install' - installed in local eclipse and smoke-tested) Cheers, Stefan On 7/22/14 3:16 PM, Robert Munteanu romb...@apache.org wrote: Hi, We solved 20 issues in this release: https://issues.apache.org/jira/browse/SLING/fixforversion/12327150 There are still some outstanding issues: https://issues.apache.org/jira/browse/SLING/component/12320908 The release candidate has been uploaded at https://dist.apache.org/repos/dist/dev/sling, The release artifact is the source bundle - sling-ide-tooling-1.0.2.jar - which can be used to build the project using mvn clean package The resulting binaries can be installed into an Eclipse instance from from the update site which is found at p2update/target/repository after building the project. For convenience, a pre-built update site - org.apache.sling.ide.p2update-1.0.2.zip - has also been uploaded. 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 Thanks, Robert -- Sent from my (old) computer
Re: A better way to create commonly used Resources at startup?
It sounds like the core issue is that nodes are created before node types are known? Could we tackle that specifically too? (Maybe that resolves the situation) Cheers, Stefan On 7/23/14 10:58 AM, Bertrand Delacretaz bdelacre...@apache.org wrote: Hi, As SLING-3618 shows, there's some non-deterministic behavior in the Sling startup that potentially causes nodes such as /var to be created by different modules depending on startup timing. So potentially with different node types, as seen in that issue. Does someone have a better idea on how to manage the creation of those commonly used nodes? It's probably only about a handful of them such as /var /libs /apps. We might define a CommonResourcesCreator service on which components such as ClassLoaderWriterImpl depend. That service then makes sure the required node types are available, and provides them to its clients. -Bertrand
[RESULT] [VOTE] Release Apache Sling Resource-Based Discovery Service 1.0.10
Hi, The vote has passed with the following result: +1 (binding) : Carsten Ziegeler, Robert Munteanu, Daniel Klco, Chetan Mehrotra +1 (non-binding) : none I'll take care of the remaining steps Cheers, Stefan
Re: [VOTE] Release Apache Sling Tenants 1.0.2
+1 (checked md5/sha1) Cheers, Stefan On 8/17/14 11:11 AM, Carsten Ziegeler cziege...@apache.org wrote: Anyone else? 2014-08-12 9:30 GMT+02:00 Robert Munteanu romb...@apache.org: +1 Robert On Tue, Aug 12, 2014 at 10:06 AM, Carsten Ziegeler cziege...@apache.org wrote: +1 2014-08-12 8:38 GMT+02:00 Carsten Ziegeler cziege...@apache.org: Hi, We solved three issues. Please vote on releasing Tenant 1.0.2 https://issues.apache.org/jira/browse/SLING/fixforversion/12324350 https://issues.apache.org/jira/browse/SLING/fixforversion/12326055 Staging repository: https://repository.apache.org/content/repositories/orgapachesling-1091 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 1091 /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. Regards Carsten -- Carsten Ziegeler Adobe Research Switzerland cziege...@apache.org -- Carsten Ziegeler Adobe Research Switzerland cziege...@apache.org -- Carsten Ziegeler Adobe Research Switzerland cziege...@apache.org
Re: [VOTE] Release Apache Sling Event 3.4.4
+1 Cheers, Stefan On 11/4/14 5:14 PM, Carsten Ziegeler cziege...@apache.org wrote: Hi, we fixed three issues https://issues.apache.org/jira/browse/SLING/fixforversion/12328883 Staging repository: https://repository.apache.org/content/repositories/orgapachesling-1148/ 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 1148 /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. Regards Carsten -- Carsten Ziegeler Adobe Research Switzerland cziege...@apache.org
Re: Sling Replication renaming
On 11/5/14 10:09 AM, Carsten Ziegeler cziege...@apache.org wrote: Am 05.11.14 um 08:45 schrieb Tommaso Teofili: - Sling content synchronization module - Sling content mirroring module - Sling content distribution module and the first two seemed to us a bit too much related to bidirectional full instance sync while the latter seems to fit nicely with the module capabilities, therefore I'd propose to change Sling replication module name into Sling content distribution module. What do you think? Thanks for bringing this up Tommaso - replication is really a missleading term. +1 Other suggestion: content sync PS: Does 'Sling Replication' still also support dispatcher flushing? In which case the name would still be confusing.. Cheers, Stefan I'm fine with content distribution. Carsten -- Carsten Ziegeler Adobe Research Switzerland cziege...@apache.org
Re: Sling Replication renaming
On 11/5/14 10:49 AM, Stefan Egli stefane...@apache.org wrote: On 11/5/14 10:09 AM, Carsten Ziegeler cziege...@apache.org wrote: Am 05.11.14 um 08:45 schrieb Tommaso Teofili: - Sling content synchronization module Other suggestion: content sync Oh, you had that suggested already, forget my comment then :) 'sync' is indeed referring to bi-drectional.. Cheers, Stefan
Re: Sling integration with Etcd
Hi Timothée, As discussed yesterday privately I absolutely support the idea of having an additional, 3rd-party based implementation of discovery.api. Whether it be etcd or zookeeper (or even something else) is up to feature comparison/discussion/etc.. One thing I thought was mentioned is that we use ZooKeeper elsewhere already and there might thus be synergies. But I haven't done a direct comparison of etcd vs zookeeper so far, so don't know if there is a clear winner anyway.. One thing to remember when implementing: one feature of discovery.api is that it groups instances hooked to the same repository into the same ClusterView and provides it with a stable (cluster)Id. In discovery.impl that is achieved by chatting and voting via said repository. When using an external mechanism, the fact that an instance belongs to a certain cluster needs special treatment as well in one way or another: either by still storing the id in the repository for example or via some configuration mechanism maybe. (Just something to keep in mind..) Cheers, Stefan On 2/4/15 2:40 PM, Timothée Maret timothee.ma...@gmail.com wrote: Hi, I found some time to look closer to the Sling Discovery implementation on AWS S3 proposal in [0]. Doing so, I stumbled upon Etcd [1] based on Raft [2] which seems to covers exactly what I wanted to do. Indeed, Etcd provides both persistent and temporal keys a well as primitives to perform leader election. Therefor, the Sling discovery API could be implemented on top of Etcd with the notable addition of * multi-level leader election (e.g. at deploymen level, region level, or any arbitrary segmentation). * persistent properties Etcd would require to be deployed on dedicated HW (not embedded) but offers HTTP API for Sling instances to communicate with it. I have added this option in SLING-2939. Has someone already implemented it ? If not, I think it would make much more sense to implement this integration rather than the idea in [0] and I would give it a go. Regards, Timothee [0] http://apache-sling.73963.n3.nabble.com/Sling-Discovery-implementation-on- AWS-S3-td4033160.html [1] https://github.com/coreos/etcd [2] https://raftconsensus.github.io
Re: Please welcome Tomek Rękawek as a Sling committer!
+1, welcome! On 2/5/15 2:28 PM, Robert Munteanu romb...@apache.org wrote: Welcome, great to have you as part of the team! Robert On Thu, 2015-02-05 at 13:50 +0100, Tommaso Teofili wrote: Welcome on board Tomek, and well deserved :-) Regards, Tommaso 2015-02-05 13:46 GMT+01:00 Bertrand Delacretaz bdelacre...@apache.org: Hi Sling community, Based on his ongoing and valuable contributions to the project, including the Sling Query module (and not to mention implementing the Towers of Hanoi in Sightly ;-), the Sling PMC has elected Tomek Rękawek as a Sling committer, and he has accepted the invitation. Please join me in welcoming him! Tomek if you want to honor the old tradition of new committers briefly introducing themselves to the list, feel free. If needed the new committers info is at http://www.apache.org/dev/new-committers-guide.html and generally under http://www.apache.org/dev/ - and feel free to ask if you have any questions. Congrats and keep up the good work! -Bertrand, for the Sling PMC P.S. I have updated http://sling.apache.org/project-information/project-team.html but we'll need to add your username once your Apache ID is created. And you affiliation if you want to mention it.
Re: [VOTE] Release Apache Sling Resource Merger 1.2.6
+1 Cheers, Stefan On 2/12/15 9:33 AM, Robert Munteanu romb...@apache.org wrote: +1 Robert On Thu, 2015-02-12 at 08:09 +0100, Carsten Ziegeler wrote: +1 Carsten Am 12.02.15 um 03:23 schrieb Carsten Ziegeler: Hi, We solved 1 issue in this release: https://issues.apache.org/jira/browse/SLING-4398 Staging repository: https://repository.apache.org/content/repositories/orgapachesling-1182/ 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 1182 /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. Regards Carsten
Re: [VOTE] Release Apache Sling Resource Resolver 1.1.14
+1, Cheers, Stefan On 2/13/15 10:51 AM, Carsten Ziegeler cziege...@apache.org wrote: Hi, We solved 2 issues in this release, especially a potential memory leak https://issues.apache.org/jira/browse/SLING/fixforversion/12329349 Staging repository: https://repository.apache.org/content/repositories/orgapachesling-1184/ 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 1184 /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. Regards Carsten -- Carsten Ziegeler Adobe Research Switzerland cziege...@apache.org
Re: [VOTE] Release Apache Sling Event 3.5.2
+1, Cheers, Stefan On 2/13/15 10:50 AM, Carsten Ziegeler cziege...@apache.org wrote: Hi, We solved 1 regression in this release: https://issues.apache.org/jira/browse/SLING-4418 Staging repository: https://repository.apache.org/content/repositories/orgapachesling-1183/ 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 1183 /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. Regards Carsten -- Carsten Ziegeler Adobe Research Switzerland cziege...@apache.org
Re: Jenkins build became unstable: sling-trunk-1.6 #2986
It looks like the test-repository could not be created correctly (see stacktrace below) I've restarted another build on jenkins and will monitor and analyze further today. Cheers, Stefan -- Caused by: javax.jcr.ItemNotFoundException: failed to build path of 7eda2c79-8574-4fa2-8c28-d7091c065d51: cafebabe-cafe-babe-cafe-babecafebabe has no child entry for 7eda2c79-8574-4fa2-8c28-d7091c065d51 at org.apache.jackrabbit.core.HierarchyManagerImpl.buildPath(HierarchyManagerI mpl.java:291) at org.apache.jackrabbit.core.CachingHierarchyManager.buildPath(CachingHierarc hyManager.java:199) at org.apache.jackrabbit.core.HierarchyManagerImpl.buildPath(HierarchyManagerI mpl.java:280) at org.apache.jackrabbit.core.CachingHierarchyManager.buildPath(CachingHierarc hyManager.java:199) at org.apache.jackrabbit.core.HierarchyManagerImpl.buildPath(HierarchyManagerI mpl.java:280) at org.apache.jackrabbit.core.CachingHierarchyManager.buildPath(CachingHierarc hyManager.java:199) at org.apache.jackrabbit.core.HierarchyManagerImpl.buildPath(HierarchyManagerI mpl.java:280) at org.apache.jackrabbit.core.CachingHierarchyManager.buildPath(CachingHierarc hyManager.java:199) at org.apache.jackrabbit.core.HierarchyManagerImpl.buildPath(HierarchyManagerI mpl.java:280) at org.apache.jackrabbit.core.CachingHierarchyManager.buildPath(CachingHierarc hyManager.java:199) at org.apache.jackrabbit.core.HierarchyManagerImpl.getPath(HierarchyManagerImp l.java:395) at org.apache.jackrabbit.core.CachingHierarchyManager.getPath(CachingHierarchy Manager.java:233) at org.apache.jackrabbit.core.ItemImpl.getPrimaryPath(ItemImpl.java:188) at org.apache.jackrabbit.core.NodeImpl.getPrimaryPath(NodeImpl.java:2745) at org.apache.jackrabbit.core.ItemImpl$2.perform(ItemImpl.java:379) at org.apache.jackrabbit.core.ItemImpl$2.perform(ItemImpl.java:376) at org.apache.jackrabbit.core.session.SessionState.perform(SessionState.java:2 00) at org.apache.jackrabbit.core.ItemImpl.perform(ItemImpl.java:91) at org.apache.jackrabbit.core.ItemImpl.getPath(ItemImpl.java:376) at org.apache.sling.discovery.impl.setup.MockedResourceResolver$1.next(MockedR esourceResolver.java:171) On 1/28/15 12:26 AM, Robert Munteanu romb...@apache.org wrote: On Wed, Jan 28, 2015 at 1:22 AM, Apache Jenkins Server jenk...@builds.apache.org wrote: See https://builds.apache.org/job/sling-trunk-1.6/2986/changes Failed tests are org.apache.sling.discovery.impl.cluster.ClusterTest.testConnectorSwitching 4139 org.apache.sling.discovery.impl.cluster.ClusterTest.testClusterView org.apache.sling.discovery.impl.cluster.ClusterTest.testStableClusterId org.apache.sling.discovery.impl.cluster.ClusterTest.testPropertyProviders org.apache.sling.discovery.impl.cluster.ClusterTest.testStaleInstanceIn3Cl usters4139 org.apache.sling.discovery.impl.cluster.ClusterTest.testLeaderDesc org.apache.sling.discovery.impl.cluster.ClusterTest.testAdditionalInstance org.apache.sling.discovery.impl.cluster.ClusterTest.testDuplicateInstanceI n2Clusters4139 org.apache.sling.discovery.impl.cluster.ClusterTest.testDuplicateInstance3 726 org.apache.sling.discovery.impl.cluster.ClusterTest.testLeaderAsc org.apache.sling.discovery.impl.cluster.ClusterTest.testStaleAnnouncements VisibleToClusterPeers4139 org.apache.sling.discovery.impl.topology.LargeTopologyWithHubTest.testLarg eTopologyWithHub Stefan, any thoughts? Robert
Re: [VOTE] Release Apache Sling Testing JCR Mock 1.1.2, ResourceResolver Mock 1.1.2, Sling Mock 1.1.2, Sling Mock Jackrabbit 0.1.2
+1, (verified md5/sha1) Cheers, Stefan On 1/27/15 5:15 PM, Stefan Seifert sseif...@pro-vision.de wrote: one (binding) vote is missing... stefan -Original Message- From: Stefan Seifert [mailto:sseif...@pro-vision.de] Sent: Thursday, January 22, 2015 10:11 PM To: dev@sling.apache.org Subject: [VOTE] Release Apache Sling Testing JCR Mock 1.1.2, ResourceResolver Mock 1.1.2, Sling Mock 1.1.2, Sling Mock Jackrabbit 0.1.2 Hi, We solved 2 issues in JCR Mock 1.1.2: https://issues.apache.org/jira/browse/SLING/fixforversion/12329091 We solved 2 issues in ResourceResolver Mock 1.1.2: https://issues.apache.org/jira/browse/SLING/fixforversion/12329092 We solved 3 issues in Sling Mock 1.1.2: https://issues.apache.org/jira/browse/SLING/fixforversion/12329089 We solved 2 issues in Sling Mock Jackrabbit 0.1.2: https://issues.apache.org/jira/browse/SLING/fixforversion/12328858 Staging repository: https://repository.apache.org/content/repositories/orgapachesling-1175/ 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 1175 /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. stefan
[discovery] delayInitEventUntilVoted enabled
Hi, Small update from the discovery.impl side: besides some test instability which I'm (still) following up, there is now a slight change to the TOPOLOGY_INIT event introduced with SLING-3750: that INIT event is now delayed to only be sent once the first voting has succeeded. This avoids duplicate-leaders-on-startup. I've enabled this feature by default. Does anyone see any issue with this? Cheers, Stefan -- https://issues.apache.org/jira/browse/SLING-3750
Re: [VOTE] Release Apache Sling JCR Resource 2.4.4
+1, Cheers, Stefan On 1/26/15 8:04 AM, Carsten Ziegeler cziege...@apache.org wrote: Anyone? Am 23.01.15 um 22:20 schrieb Carsten Ziegeler: Hi, we solved one critical issue https://issues.apache.org/jira/browse/SLING-4343 Staging repository: https://repository.apache.org/content/repositories/orgapachesling-1177/ 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 1177 /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. Regards Carsten -- Carsten Ziegeler Adobe Research Switzerland cziege...@apache.org
Re: [VOTE] Release Apache Sling Launchpad Base 4.6.0-2.5.6
+1, Cheers, Stefan On 1/26/15 8:04 AM, Carsten Ziegeler cziege...@apache.org wrote: Anyone? Am 22.01.15 um 22:12 schrieb Carsten Ziegeler: Hi, we solved one major deadlock issue https://issues.apache.org/jira/browse/SLING/fixforversion/12329291 Staging repository: https://repository.apache.org/content/repositories/orgapachesling-1176/ 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 1176 /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. Regards Carsten -- Carsten Ziegeler Adobe Research Switzerland cziege...@apache.org
Re: Jenkins build became unstable: sling-trunk-1.7 #1317
This time the failure was 'java.lang.OutOfMemoryError: Java heap space' Looks like we should give the tests more memory.. Cheers, Stefan On 1/13/15 6:32 PM, Apache Jenkins Server jenk...@builds.apache.org wrote: See https://builds.apache.org/job/sling-trunk-1.7/1317/changes
[jenkins] more history on jenkin builds
Hi, Are there particular reasons against having a larger history (number) of jenkins builds (eg at [0])? Sometimes useful to go back more than 1-2 days.. If not, who could change this (I don't seem to have the karma)? Cheers, Stefan -- [0] - https://builds.apache.org/job/sling-trunk-1.6/
Re: [jenkins] more history on jenkin builds
Hi Robert, On 1/13/15 4:02 PM, Robert Munteanu romb...@apache.org wrote: I guess it's limited to not overload Jenkins ( both memory and disk space ) with history. Do we know how much a build needs in terms of disk space? I would have assumed that it keeps only the test/console results not the workspaces - in which case it should be rather small - but I'm not sure. I can make this change ( but can't grant you karma ) . Right now we keep the last 10 builds. How many builds do you think we should keep? Depends on the above I guess - and with the assumption that it uses only very little space, I would have suggested 50 :) Cheers, Stefan
Re: Please welcome Radu Costescu as a Sling committer
Welcome Radu! Cheers, Stefan On 2/9/15 9:20 AM, Felix Meschberger fmesc...@adobe.com wrote: Hi all Based on his sustained quality of work on various topics like the validation framework, XSS module, as well as Sightly recently, the Apache Sling PMC decided to invite Radu Cotescu as a committer to the Sling project. Please join me in welcoming Radu ! Radu, please feel free to introduce yourself to the community, if you like. Regards Felix PS: I have updated the http://sling.apache.org/project-information/project-team.html page.
Re: [VOTE] Release Apache Sling JCR Resource Security 1.0.0
+1 (verified md5/sha1) Cheers, Stefan On 1/8/15 4:10 PM, Carsten Ziegeler cziege...@apache.org wrote: Anyone? Thanks Carsten Am 05.01.15 um 16:57 schrieb Carsten Ziegeler: Hi, it's time to make a first release of this module: https://issues.apache.org/jira/browse/SLING-3438 Staging repository: https://repository.apache.org/content/repositories/orgapachesling-1158/ 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 1158 /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. Regards Carsten -- Carsten Ziegeler Adobe Research Switzerland cziege...@apache.org
Re: [VOTE] Release Apache Sling Eventing 3.5.0
+1 (verified md5/sha1) Cheers, Stefan On 1/7/15 1:53 PM, Carsten Ziegeler cziege...@apache.org wrote: Hi, we solved three issues https://issues.apache.org/jira/browse/SLING/fixforversion/12328927 Staging repository: https://repository.apache.org/content/repositories/orgapachesling-1160/ 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 1160 /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. Regards Carsten -- Carsten Ziegeler Adobe Research Switzerland cziege...@apache.org
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
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
Re: Sling leader / CRX master mapping
Hi Tim, Currently, unfortunately, only the inverse is configurable. 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. So this was an explicit goal of the current implementation. To achieve this, a repository descriptor is configurable (leaderElectionRepositoryDescriptor) which, when set, can enforce exactly this: that the crx-master is not the leader if there is any slave around. 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. But that might not suffice in your case I assume.. Cheers, Stefan On 3/16/15 12:15 PM, Timothée Maret timothee.ma...@gmail.com wrote: Hi, In a deployment, we use a CRX (TarPM) active/passive cluster composed of one master instance and one slave instance. We run background jobs on this deployment and we want to have them run on the CRX master only in order to guarantee no writes on the slave thus keeping the activate/passive scheme. The way we currently do it is by checking in our background code, that the instance is the Sling leader and only run the code if the instance is the leader. This works only if the following holds at any time Sling leader == CRX master We experienced some cases where this seemed not to be the case. Should we expect the above mentioned mapping to be valid or should be find another way to enforce background services to only execute on the master ? We could use some CRX specific code for that, but our code would not become portable to other MK. Regards, Timothee
Re: [VOTE] Release Apache Sling discovery.impl 1.1.0
This was about httpclient upgrade from 3 to 4 - I'll have a look: dependency groupIdorg.apache.httpcomponents/groupId artifactIdhttpclient-osgi/artifactId version4.3.5/version scopeprovided/scope /dependency Cheers, Stefan On 3/18/15 9:34 PM, Robert Munteanu romb...@apache.org wrote: 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
Re: [VOTE] Release Apache Sling discovery.impl 1.1.0
Included httpcore/httpclient 4.4 in launchpad. see SLING-4519 and separate email to dev. On 3/19/15 9:25 AM, Stefan Egli stefane...@apache.org wrote: This was about httpclient upgrade from 3 to 4 - I'll have a look: dependency groupIdorg.apache.httpcomponents/groupId artifactIdhttpclient-osgi/artifactId version4.3.5/version scopeprovided/scope /dependency Cheers, Stefan On 3/18/15 9:34 PM, Robert Munteanu romb...@apache.org wrote: 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
Re: [VOTE] Release Apache Sling XSS Protection Bundle 1.0.2
+1 (checked signatures, jira) Cheers, STefan On 3/24/15 4:35 PM, Radu Cotescu r...@apache.org wrote: Hi, We solved 1 issue in this release: https://issues.apache.org/jira/browse/SLING/fixforversion/12329667/ There are still some outstanding issues: https://issues.apache.org/jira/browse/SLING/fixforversion/12329844/ Staging repository: https://repository.apache.org/content/repositories/orgapachesling-1221 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 1221 /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. Thanks, Radu
[VOTE RESULT] Release Apache Sling discovery.impl 1.1.0
The vote passed with 3 +1 votes - thanks for voting! I'll do the rest next, Cheers, Stefan
