Re: [VOTE] Release Apache Sling Commons Metrics 1.0.0
+1 Approve the release Chetan Mehrotra On Tue, Jan 12, 2016 at 10:47 AM, Chetan Mehrotra wrote: > Hi, > > This is the first release (second attempt) of the new Sling Commons > Metrics component with 1 issue fixed > > https://issues.apache.org/jira/browse/SLING/fixforversion/12334625 > > Documents are updated: > https://sling.apache.org/documentation/bundles/metrics.html > > Staging repository: > https://repository.apache.org/content/repositories/orgapachesling-1406 > > 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 1406 /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. > Chetan Mehrotra
[VOTE] Release Apache Sling Commons Metrics 1.0.0
Hi, This is the first release (second attempt) of the new Sling Commons Metrics component with 1 issue fixed https://issues.apache.org/jira/browse/SLING/fixforversion/12334625 Documents are updated: https://sling.apache.org/documentation/bundles/metrics.html Staging repository: https://repository.apache.org/content/repositories/orgapachesling-1406 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 1406 /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. Chetan Mehrotra
Re: Identify areas in Sling where important metrics can be captured (SLING-5410)
Thanks for the feedback. Updated the SLING-5410 with suggestions above. Would followup with linked task and patches Chetan Mehrotra On Fri, Jan 8, 2016 at 12:37 AM, Michael Marth wrote: > With the same caveat (“just an ad hoc dream list”): > > - event creation/consumption count/duration > - Sling (servlet) filter processing duration > > In a nutshell any useful information that can help to debug issues like “my > system/my request is slow” or like “my system seems overloaded”. > > Michael > > > > > On 07/01/16 12:08, "Bertrand Delacretaz" wrote: > >>Hi Chetan, >> >>On Thu, Jan 7, 2016 at 11:56 AM, Chetan Mehrotra >> wrote: >>> ...Do share your thoughts here or at SLING-5410!.. >> >>Here's a rough list off the top of my head. Some might belong in Oak >>or Felix, and I have not thought about difficulty of implementation. >>Just a dream list ;-) >> >>-Requests count and duration, per HTTP method? >>-Resource and servlet/script resolution counts and durations >>-Servlet/script execution duration >>-JCR Session acquisition count and duration >>-Bundle startup count and duration >>-adaptTo() call count and duration >>-Authentication handler calls count and duration >> >>-Bertrand
[jira] [Commented] (SLING-5410) Identify component where important Metrics can be collected
[
https://issues.apache.org/jira/browse/SLING-5410?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15093266#comment-15093266
]
Chetan Mehrotra commented on SLING-5410:
Discussion thread - http://markmail.org/thread/aihmus2ztiaygfp3
[~bdelacretaz] dream list
{quote}
# Requests count and duration, per HTTP method?
# Resource and servlet/script resolution counts and durations
# Servlet/script execution duration
# JCR Session acquisition count and duration
# Bundle startup count and duration
# adaptTo() call count and duration
# Authentication handler calls count and duration
{quote}
[~mmarth] “just an ad hoc dream list”
{quote}
# event creation/consumption count/duration
# Sling (servlet) filter processing duration
{quote}
> Identify component where important Metrics can be collected
> ---
>
> Key: SLING-5410
> URL: https://issues.apache.org/jira/browse/SLING-5410
> Project: Sling
> Issue Type: Task
> Components: Engine
>Reporter: Chetan Mehrotra
>Assignee: Chetan Mehrotra
>
> With SLING-4080 we now have support for collecting various kinds of metrics
> in performant way.
> As a next step we would need to identify those parts of Sling engine and
> request processing logic where we can collect important metrics. Such metric
> should help
> # Sling system administrator to monitor key aspects of Sling
> # Allow us as developers to get insight into critical parts and help in doing
> further optimization
> Once identified we can then add required metric collection logic to those
> parts
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (SLING-5420) Add support for MetricOptions to better control certain optional features
[
https://issues.apache.org/jira/browse/SLING-5420?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Chetan Mehrotra resolved SLING-5420.
Resolution: Won't Fix
Fix Version/s: (was: Commons Metrics 1.0.0)
Marking as Wont Fix based on discussion on thread referred above
> Add support for MetricOptions to better control certain optional features
> -
>
> Key: SLING-5420
> URL: https://issues.apache.org/jira/browse/SLING-5420
> Project: Sling
> Issue Type: Task
> Components: Commons
>Reporter: Chetan Mehrotra
>Assignee: Chetan Mehrotra
> Attachments: SLING-5420-v1.patch
>
>
> For certain usecases (SLING-5418, SLING-5419) we need to configure some more
> options as part of creating a given metric instance.
> To allow for such features (and other possible extension in future) it would
> be better to also accept a {{MetricOption}} as part of create call. This can
> be used to capture info like description, time series requirement etc
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (SLING-5423) embedded raft based discovery mechanism
[ https://issues.apache.org/jira/browse/SLING-5423?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15092209#comment-15092209 ] Bertrand Delacretaz commented on SLING-5423: I have assigned it, maybe you cannot do it yourself in your "contributor" role. Looking forward to this! > embedded raft based discovery mechanism > --- > > Key: SLING-5423 > URL: https://issues.apache.org/jira/browse/SLING-5423 > Project: Sling > Issue Type: New Feature > Components: Extensions >Affects Versions: Discovery Standalone 1.0.2 >Reporter: Timothee Maret >Assignee: Timothee Maret > > The Raft consensus algorithm [0] is a good pick for implenting the discovery > API or more generally clustering solutions. > Indeed, Raft algorithm design aims at being "easy" to understand and thus > "easy" to be implemented/debugged maybe by mere mortals. > One of the major implementation of Raft is etcd [1] which Sling can already > leverage (SLING-4842). > However, etcd requires an extra piece of infrastructure to be deployed (the > etcd servers) which can't be shipped as part of the Sling quickstart (Go vs > Java techs). > Using an embedded Raft based discovery and clustering mechanism would bring > an easy to deploy solution (OOTB) and based on proven algorithm. > As Raft is designed to be easy to implement, many implementations already > exists [0]. > Ideally an existing implementation could be reused instead of reimplementing > it though. > An interesting one is Copycat [2] which is now released and Apache 2 licensed. > [0] https://raft.github.io > [1] https://github.com/coreos/etcd > [2] https://github.com/atomix/copycat -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (SLING-5423) embedded raft based discovery mechanism
[ https://issues.apache.org/jira/browse/SLING-5423?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bertrand Delacretaz updated SLING-5423: --- Assignee: Timothee Maret > embedded raft based discovery mechanism > --- > > Key: SLING-5423 > URL: https://issues.apache.org/jira/browse/SLING-5423 > Project: Sling > Issue Type: New Feature > Components: Extensions >Affects Versions: Discovery Standalone 1.0.2 >Reporter: Timothee Maret >Assignee: Timothee Maret > > The Raft consensus algorithm [0] is a good pick for implenting the discovery > API or more generally clustering solutions. > Indeed, Raft algorithm design aims at being "easy" to understand and thus > "easy" to be implemented/debugged maybe by mere mortals. > One of the major implementation of Raft is etcd [1] which Sling can already > leverage (SLING-4842). > However, etcd requires an extra piece of infrastructure to be deployed (the > etcd servers) which can't be shipped as part of the Sling quickstart (Go vs > Java techs). > Using an embedded Raft based discovery and clustering mechanism would bring > an easy to deploy solution (OOTB) and based on proven algorithm. > As Raft is designed to be easy to implement, many implementations already > exists [0]. > Ideally an existing implementation could be reused instead of reimplementing > it though. > An interesting one is Copycat [2] which is now released and Apache 2 licensed. > [0] https://raft.github.io > [1] https://github.com/coreos/etcd > [2] https://github.com/atomix/copycat -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (SLING-5423) embedded raft based discovery mechanism
[ https://issues.apache.org/jira/browse/SLING-5423?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15092195#comment-15092195 ] Timothee Maret commented on SLING-5423: --- [~bdelacretaz] how could I assign this to me ? > embedded raft based discovery mechanism > --- > > Key: SLING-5423 > URL: https://issues.apache.org/jira/browse/SLING-5423 > Project: Sling > Issue Type: New Feature > Components: Extensions >Affects Versions: Discovery Standalone 1.0.2 >Reporter: Timothee Maret > > The Raft consensus algorithm [0] is a good pick for implenting the discovery > API or more generally clustering solutions. > Indeed, Raft algorithm design aims at being "easy" to understand and thus > "easy" to be implemented/debugged maybe by mere mortals. > One of the major implementation of Raft is etcd [1] which Sling can already > leverage (SLING-4842). > However, etcd requires an extra piece of infrastructure to be deployed (the > etcd servers) which can't be shipped as part of the Sling quickstart (Go vs > Java techs). > Using an embedded Raft based discovery and clustering mechanism would bring > an easy to deploy solution (OOTB) and based on proven algorithm. > As Raft is designed to be easy to implement, many implementations already > exists [0]. > Ideally an existing implementation could be reused instead of reimplementing > it though. > An interesting one is Copycat [2] which is now released and Apache 2 licensed. > [0] https://raft.github.io > [1] https://github.com/coreos/etcd > [2] https://github.com/atomix/copycat -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (SLING-5423) embedded raft based discovery mechanism
Timothee Maret created SLING-5423: - Summary: embedded raft based discovery mechanism Key: SLING-5423 URL: https://issues.apache.org/jira/browse/SLING-5423 Project: Sling Issue Type: New Feature Components: Extensions Affects Versions: Discovery Standalone 1.0.2 Reporter: Timothee Maret The Raft consensus algorithm [0] is a good pick for implenting the discovery API or more generally clustering solutions. Indeed, Raft algorithm design aims at being "easy" to understand and thus "easy" to be implemented/debugged maybe by mere mortals. One of the major implementation of Raft is etcd [1] which Sling can already leverage (SLING-4842). However, etcd requires an extra piece of infrastructure to be deployed (the etcd servers) which can't be shipped as part of the Sling quickstart (Go vs Java techs). Using an embedded Raft based discovery and clustering mechanism would bring an easy to deploy solution (OOTB) and based on proven algorithm. As Raft is designed to be easy to implement, many implementations already exists [0]. Ideally an existing implementation could be reused instead of reimplementing it though. An interesting one is Copycat [2] which is now released and Apache 2 licensed. [0] https://raft.github.io [1] https://github.com/coreos/etcd [2] https://github.com/atomix/copycat -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (SLING-5422) Sling Event - HistoryCleanUpTask removes Jobs younger than configured
Christoph Nagel created SLING-5422:
--
Summary: Sling Event - HistoryCleanUpTask removes Jobs younger
than configured
Key: SLING-5422
URL: https://issues.apache.org/jira/browse/SLING-5422
Project: Sling
Issue Type: Bug
Components: Extensions
Reporter: Christoph Nagel
Priority: Minor
The HistoryCleanUpTask has to remove all Jobs stored in the JCR older than the
given parameter {{age}} (a number of minutes).
The current implementation traverses the _/var/eventing/jobs_ tree where parts
of the path define the date of a job. Problem: the comparison of the job- and
{{removeDate}} is wrong. First it compares the years, than months, weeks and
days but this doesn't work.
I've forked the project on github and wrote a test and fix. Further I added a
test dependency for sling-mock in the pom.xml: [Fixes HistoryCleanUpTask date
comparison|https://github.com/cnagel/sling/commit/165a8a04a129a4669599c6b15f48f67060e6c83c].
Please have a look and if you like I can create a pull request on GitHub.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
Re: Feedback required for providing a new MetricOptions in MetricService API (SLING-5420)
Hi Chetan, On Mon, Jan 11, 2016 at 12:04 PM, Chetan Mehrotra wrote: > ...if no other suggestion > would withdraw this issue and cut the first release of the bundle > tomorrow morning.. I agree with Ian's points, having a first release with less features sounds better to me, in order to get feedback and add just what's really needed later, if anything. -Bertrand
Re: Feedback required for providing a new MetricOptions in MetricService API (SLING-5420)
On Mon, Jan 11, 2016 at 3:32 PM, Ian Boston wrote: > I think you should keep it simple and not add this functionality into the > Metrics API involved in instrumentation. okie makes sense now. If required we can capture such "meta" information via OSGi config as its not the concern of the instrumented code and is more of deployment concern. The MetricService API is just meant for collection and hence should be precise and stable. Would wait for today for thoughts from other. if no other suggestion would withdraw this issue and cut the first release of the bundle tomorrow morning Chetan Mehrotra
Re: Feedback required for providing a new MetricOptions in MetricService API (SLING-5420)
Hi, I think you should keep it simple and not add this functionality into the Metrics API involved in instrumentation. If you need control over metadata associated with metrics or the behaviour of an implementation of a metrics that should (imo) be done in a separate API, optionally implemented by the metrics provider. That API would allow a consumer to set properties of metrics by name if required, and it could be versioned more frequently as new use cases emerged without destabilizing all instrumentation. Talking of use cases. I have not seen a situation where it has been proven to be helpful to have a customised histogram or reservoir. Although there are lots of arguments from a developer point of view for doing so, it damages consistency and requires that the special case is communicated to deployers who then need to find some way of accommodating that special case in the monitoring tools where consistency is vital to perform statistical analysis and correlations. Again, descriptions may help but are rarely output in reporting mechanisms and so the documentation use case is better covered by documentation of each metric. Sometimes this can be achieved by using a readable metric ID. "request" gives no context, but "org.apache.sling.engine.impl.SlingHttpContext.handleSecurity_m" is quiet an effective pointer. Best Regards Ian On 11 January 2016 at 09:42, Chetan Mehrotra wrote: > Hi Team, > > Given that 1.0 release is not yet cut I was thinking about some future > requirements and how they might impact the API. Based on that I have > opened SLING-5420 where a new MetricOptions class is proposed to > control how certain aspect of Metric collection/reporting are > controlled. > > Kindly have a look at that and provide your feedback. This would > ensure that API remains useful and stable! > > Chetan Mehrotra >
[jira] [Commented] (SLING-5420) Add support for MetricOptions to better control certain optional features
[
https://issues.apache.org/jira/browse/SLING-5420?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15091684#comment-15091684
]
Chetan Mehrotra commented on SLING-5420:
Good point. Started a thread with http://markmail.org/thread/3jkan2r4svivutfy
> Add support for MetricOptions to better control certain optional features
> -
>
> Key: SLING-5420
> URL: https://issues.apache.org/jira/browse/SLING-5420
> Project: Sling
> Issue Type: Task
> Components: Commons
>Reporter: Chetan Mehrotra
>Assignee: Chetan Mehrotra
> Fix For: Commons Metrics 1.0.0
>
> Attachments: SLING-5420-v1.patch
>
>
> For certain usecases (SLING-5418, SLING-5419) we need to configure some more
> options as part of creating a given metric instance.
> To allow for such features (and other possible extension in future) it would
> be better to also accept a {{MetricOption}} as part of create call. This can
> be used to capture info like description, time series requirement etc
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
Feedback required for providing a new MetricOptions in MetricService API (SLING-5420)
Hi Team, Given that 1.0 release is not yet cut I was thinking about some future requirements and how they might impact the API. Based on that I have opened SLING-5420 where a new MetricOptions class is proposed to control how certain aspect of Metric collection/reporting are controlled. Kindly have a look at that and provide your feedback. This would ensure that API remains useful and stable! Chetan Mehrotra
Re: [VOTE] Release Apache Sling Scripting Groovy 1.0.2
On Sat, 2016-01-09 at 14:48 +0100, Oliver Lietz wrote: > Please vote to approve this release: +1 Robert signature.asc Description: This is a digitally signed message part
[jira] [Commented] (SLING-5414) Make the contents of the provisioning model available at runtime
[ https://issues.apache.org/jira/browse/SLING-5414?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15091645#comment-15091645 ] Bertrand Delacretaz commented on SLING-5414: Thanks [~olli] for fixing this, I'll think about a more universal way of providing the model at runtime. > Make the contents of the provisioning model available at runtime > > > Key: SLING-5414 > URL: https://issues.apache.org/jira/browse/SLING-5414 > Project: Sling > Issue Type: New Feature > Components: Maven Plugins and Archetypes >Affects Versions: Slingstart Maven Plugin 1.4.0 >Reporter: Bertrand Delacretaz >Assignee: Bertrand Delacretaz >Priority: Minor > Fix For: Slingstart Maven Plugin 1.4.2 > > Attachments: SLING-5414.patch > > > For SLING-5355 we need to make additional sections from the provisioning > model available at runtime, so that ACLs can be set at startup, and also to > be able to reuse their definitions later for auditing/verification purposes. > A simple way to do that is to copy those sections in the sling_bootstrap.txt > file. I have created a patch that does that, will attach it here for review. > _edit: as discussed below, we'll make the full text of the model available at > runtime_ -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (SLING-5420) Add support for MetricOptions to better control certain optional features
[
https://issues.apache.org/jira/browse/SLING-5420?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15091643#comment-15091643
]
Bertrand Delacretaz commented on SLING-5420:
I suggest discussing these API options on our dev list, others might have good
ideas as well.
> Add support for MetricOptions to better control certain optional features
> -
>
> Key: SLING-5420
> URL: https://issues.apache.org/jira/browse/SLING-5420
> Project: Sling
> Issue Type: Task
> Components: Commons
>Reporter: Chetan Mehrotra
>Assignee: Chetan Mehrotra
> Fix For: Commons Metrics 1.0.0
>
> Attachments: SLING-5420-v1.patch
>
>
> For certain usecases (SLING-5418, SLING-5419) we need to configure some more
> options as part of creating a given metric instance.
> To allow for such features (and other possible extension in future) it would
> be better to also accept a {{MetricOption}} as part of create call. This can
> be used to capture info like description, time series requirement etc
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (SLING-5421) Handle timeout cause when JCR installer is paused
[ https://issues.apache.org/jira/browse/SLING-5421?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chetan Mehrotra updated SLING-5421: --- Priority: Minor (was: Major) > Handle timeout cause when JCR installer is paused > - > > Key: SLING-5421 > URL: https://issues.apache.org/jira/browse/SLING-5421 > Project: Sling > Issue Type: Improvement > Components: Installer >Affects Versions: JCR Installer 3.1.8 >Reporter: Chetan Mehrotra >Assignee: Chetan Mehrotra >Priority: Minor > Fix For: JCR Installer 3.1.18 > > > With SLING-3747 the JCR installer provided a mechanism for pausing the > installer to support cases where installation can result in restart of > installer bundle itself. > However it may happen that once this flag is set the process gets abruptly > killed and the flag remain set. In such a case the installer would remain > paused and a user would have to remove the flag for it to work again. To > support such cases there should be some kind of timeout such that installer > does not remain in pause state for ever -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (SLING-5421) Handle timeout cause when JCR installer is paused
Chetan Mehrotra created SLING-5421: -- Summary: Handle timeout cause when JCR installer is paused Key: SLING-5421 URL: https://issues.apache.org/jira/browse/SLING-5421 Project: Sling Issue Type: Improvement Components: Installer Affects Versions: JCR Installer 3.1.8 Reporter: Chetan Mehrotra Assignee: Chetan Mehrotra Fix For: JCR Installer 3.1.18 With SLING-3747 the JCR installer provided a mechanism for pausing the installer to support cases where installation can result in restart of installer bundle itself. However it may happen that once this flag is set the process gets abruptly killed and the flag remain set. In such a case the installer would remain paused and a user would have to remove the flag for it to work again. To support such cases there should be some kind of timeout such that installer does not remain in pause state for ever -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (SLING-5226) Remove loginAdministrative() usage from org.apache.sling.servlets.post
[
https://issues.apache.org/jira/browse/SLING-5226?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15091571#comment-15091571
]
Antonio Sanso commented on SLING-5226:
--
There is one occurrence of {{loginAdministrative}} in ChunkCleanUpTask#cleanup
.
It is used to query {{sling:chunks}} for clean up.
> Remove loginAdministrative() usage from org.apache.sling.servlets.post
> ---
>
> Key: SLING-5226
> URL: https://issues.apache.org/jira/browse/SLING-5226
> Project: Sling
> Issue Type: Improvement
> Components: Servlets
>Reporter: Antonio Sanso
>
> Counted 1 occurrence
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
