[jira] [Resolved] (SLING-5282) cancel sync upon handleDeactivating

[Stefan Egli (JIRA)]

 [ 
https://issues.apache.org/jira/browse/SLING-5282?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Stefan Egli resolved SLING-5282.

Resolution: Fixed

done: 1713434

> cancel sync upon handleDeactivating
> ---
>
> Key: SLING-5282
> URL: https://issues.apache.org/jira/browse/SLING-5282
> Project: Sling
>  Issue Type: Bug
>  Components: Extensions
>Affects Versions: Discovery Commons 1.0.2
>Reporter: Stefan Egli
>Assignee: Stefan Egli
>Priority: Minor
> Fix For: Discovery Commons 1.0.4
>
>
> In {{ViewStateManager.handleDeactivated}} a {{consistencyService.cancelSync}} 
> was missing - which lead to syncing being left running even though the 
> discovery service was already deactivated.
> Mostly affects tests only.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Re: [VOTE] Release Apache Sling Commons Testing 2.0.22, Commons JSON 2.0.16, Maven Sling Plugin 2.1.6

[Stefan Egli]

+1

Cheers,
Stefan

On 09/11/15 13:31, "Stefan Seifert"  wrote:

>Hi,
>
>Apache Sling Commons Testing 2.0.22  - 4 Issues  (skipped one version due
>to canceled vote)
>https://issues.apache.org/jira/browse/SLING/fixforversion/12331987
>
>Apache Sling Commons JSON 2.0.16  - 4 Issues  (skipped one version due to
>canceled vote)
>https://issues.apache.org/jira/browse/SLING/fixforversion/12333769
>
>Apache Sling Maven Sling Plugin 2.1.6  - 2 Issues  (skipped one version
>due to canceled vote)
>https://issues.apache.org/jira/browse/SLING/fixforversion/12334045
>
>Staging repository:
>https://repository.apache.org/content/repositories/orgapachesling-1366/
>
>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 1366 /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
>

[jira] [Updated] (SLING-5281) Allow execution of distribution requests using calling user session

[Marius Petria (JIRA)]

 [ 
https://issues.apache.org/jira/browse/SLING-5281?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Marius Petria updated SLING-5281:
-
Fix Version/s: Content Distribution Core 0.1.10

> Allow execution of distribution requests using calling user session
> ---
>
> Key: SLING-5281
> URL: https://issues.apache.org/jira/browse/SLING-5281
> Project: Sling
>  Issue Type: Improvement
>  Components: Distribution
>Reporter: Marius Petria
>Assignee: Marius Petria
> Fix For: Content Distribution Core 0.1.10
>
>
> If for an agent the serviceName is not provided then it should execute with a 
> defaultAgentService that will impersonate the calling user session for async 
> operations. 



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Resolved] (SLING-5283) Allow item copy between distribution queues

[Marius Petria (JIRA)]

 [ 
https://issues.apache.org/jira/browse/SLING-5283?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Marius Petria resolved SLING-5283.
--
Resolution: Fixed
  Assignee: Marius Petria

Committed revision 1713450.


> Allow item copy between distribution queues
> ---
>
> Key: SLING-5283
> URL: https://issues.apache.org/jira/browse/SLING-5283
> Project: Sling
>  Issue Type: Improvement
>  Components: Distribution
>Reporter: Marius Petria
>Assignee: Marius Petria
> Fix For: Content Distribution Core 0.1.10
>
>
> In order to retry items from an error queue we should be able to copy items 
> from an error queue to an original queue.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (SLING-5283) Allow item copy between distribution queues

[Marius Petria (JIRA)]

Marius Petria created SLING-5283:


 Summary: Allow item copy between distribution queues
 Key: SLING-5283
 URL: https://issues.apache.org/jira/browse/SLING-5283
 Project: Sling
  Issue Type: Improvement
  Components: Distribution
Reporter: Marius Petria
 Fix For: Content Distribution Core 0.1.10


In order to retry items from an error queue we should be able to copy items 
from an error queue to an original queue.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (SLING-5282) cancel sync upon handleDeactivating

[Stefan Egli (JIRA)]

Stefan Egli created SLING-5282:
--

 Summary: cancel sync upon handleDeactivating
 Key: SLING-5282
 URL: https://issues.apache.org/jira/browse/SLING-5282
 Project: Sling
  Issue Type: Bug
  Components: Extensions
Affects Versions: Discovery Commons 1.0.2
Reporter: Stefan Egli
Assignee: Stefan Egli
Priority: Minor
 Fix For: Discovery Commons 1.0.4


In {{ViewStateManager.handleDeactivated}} a {{consistencyService.cancelSync}} 
was missing - which lead to syncing being left running even though the 
discovery service was already deactivated.

Mostly affects tests only.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[VOTE] Release Apache Sling Commons Testing 2.0.22, Commons JSON 2.0.16, Maven Sling Plugin 2.1.6

[Stefan Seifert]

Hi,

Apache Sling Commons Testing 2.0.22  - 4 Issues  (skipped one version due to 
canceled vote)
https://issues.apache.org/jira/browse/SLING/fixforversion/12331987

Apache Sling Commons JSON 2.0.16  - 4 Issues  (skipped one version due to 
canceled vote)
https://issues.apache.org/jira/browse/SLING/fixforversion/12333769

Apache Sling Maven Sling Plugin 2.1.6  - 2 Issues  (skipped one version due to 
canceled vote)
https://issues.apache.org/jira/browse/SLING/fixforversion/12334045

Staging repository:
https://repository.apache.org/content/repositories/orgapachesling-1366/

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 1366 /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

Re: [VOTE] Release Apache Sling Commons Testing 2.0.22, Commons JSON 2.0.16, Maven Sling Plugin 2.1.6

[Stefan Seifert]

+1

[jira] [Commented] (SLING-3635) [Javascript] Optimization level for byte code generator in Rhino should be configurable

[Chetan Mehrotra (JIRA)]

[ 
https://issues.apache.org/jira/browse/SLING-3635?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14997978#comment-14997978
 ] 

Chetan Mehrotra commented on SLING-3635:


bq. This option should be configurable, and the default value for this 
configuration should be "-1" - meaning run scripts in interpreted mode. Since 
we are not caching script compilation artifacts, the interpreted mode gives the 
best performance for short-running scripts.

Given that with SLING-913 compiled scripts are cached should the default be 
changed?

> [Javascript] Optimization level for byte code generator in Rhino should be 
> configurable
> ---
>
> Key: SLING-3635
> URL: https://issues.apache.org/jira/browse/SLING-3635
> Project: Sling
>  Issue Type: Improvement
>  Components: Scripting
>Affects Versions: Scripting JavaScript 2.0.12
>Reporter: Marius-Andrei Danila
>Assignee: Bertrand Delacretaz
> Fix For: Scripting JavaScript 2.0.14
>
> Attachments: SLING-3635.diff
>
>
> The Rhino Javascript engine allows you to choose the level of optimization 
> for the generated byte code or it lets you select whether the scripts should 
> be run in interpreted mode [0].
> Currently, there is no way to configure this. By default, Rhino compiles 
> scripts into JVM classes using the optimization level 0.
> This option should be configurable, and the default value for this 
> configuration should be "-1" - meaning run scripts in interpreted mode. Since 
> we are not caching script compilation artifacts, the interpreted mode gives 
> the best performance for short-running scripts.
> The attached patch implements this improvement by exposing a configuration 
> entry in the Rhino Javascript engine factory component.
> [0] 
> https://developer.mozilla.org/en-US/docs/Mozilla/Projects/Rhino/Optimization



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (SLING-4937) Drop namespace mapping support

[Alexander Klimetschek (JIRA)]

[ 
https://issues.apache.org/jira/browse/SLING-4937?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14997921#comment-14997921
 ] 

Alexander Klimetschek commented on SLING-4937:
--

It also helps with performance A LOT. The call 
{{NamespaceMappingSupport#getNamespaceAwareSession}} tends to be comparatively 
slow under high traffic with lots of concurrency in my tests. E.g. the actual 
repo login takes way less than 0.5 ms (if optimized), but the 
getNamespaceAwareSession has a high variance up to 40 ms, being the largest 
part of the authentication phase in our sling app.

AFAICS, in commit 
https://github.com/apache/sling/commit/75594f9e2cd2c57ea8111935a41d1066dfe86813 
(not linked here) it has been removed from AbstractSlingRepository2 eventually.

> Drop namespace mapping support
> --
>
> Key: SLING-4937
> URL: https://issues.apache.org/jira/browse/SLING-4937
> Project: Sling
>  Issue Type: Improvement
>  Components: JCR
>Reporter: Carsten Ziegeler
>Assignee: Carsten Ziegeler
> Fix For: JCR Jackrabbit Server 2.3.0, JCR Base 2.3.0, JCR Oak 
> Server 1.0.0
>
>
> I think we should support the support for namespace mapping from our jcr
> base module (and therefore from the jcr server implementations).
> The namespace support parses the Sling-Namespaces header of bundles and
> ensures that every session has namespace prefix mapping based on these
> headers ensuring a stable mapping. The main reason why we added this in
> the first place is, is that in theory one could map e.g. the sling
> namespace prefix to some own non Sling url. Which obviously would break
> all applications. Of course, no one really does this and even with this
> mapping behavuíour in place, I'm pretty sure apps would break if someone
> does crazy mappings as we only cover the part where the Sling API is
> used. Defaulting to the JCR API will probably use the wrong mapping.
> As implementing this mapping creates proxy objects for the session which
> is kind of heavy and I really think that this feature was never really
> useful, I think we should drop it.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Comment Edited] (SLING-5284) use dedicate thread instead of scheduler

[Stefan Egli (JIRA)]

[ 
https://issues.apache.org/jira/browse/SLING-5284?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14996864#comment-14996864
 ] 

Stefan Egli edited comment on SLING-5284 at 11/9/15 5:34 PM:
-

implemented in rev 1713477 and rev 1713480 (version upping of discovery.base to 
1.1.0) and 1713484 (version upping of discovery.oak to 1.1.0)


was (Author: egli):
implemented in rev 1713477 and rev 1713480 (version upping of discovery.base to 
1.1.0)

> use dedicate thread instead of scheduler
> 
>
> Key: SLING-5284
> URL: https://issues.apache.org/jira/browse/SLING-5284
> Project: Sling
>  Issue Type: Improvement
>  Components: Extensions
>Affects Versions: Discovery Impl 1.2.0, Discovery Oak 1.0.2, Discovery 
> Base 1.0.2
>Reporter: Stefan Egli
>Assignee: Stefan Egli
> Fix For: Discovery Impl 1.2.2, Discovery Base 1.1.0, Discovery 
> Oak 1.0.4
>
>
> Currently discovery (base/oak/impl) use the sling scheduler for scheduling 
> the background jobs that periodically issue heartbeats, ping the topology 
> connectors and check if the view is current. It's very important that these 
> jobs run at the exact defined periods - delays of a few minutes can break 
> their usefullness and in the end cause an instability in the topology. Sling 
> scheduler uses a thread-pool which is by definition limited. And if, for some 
> reason, this pool is busy doing other stuff, then the job is not executed for 
> a certain amount of time. Consider the situation when all the jobs are busy 
> with other things (non discovery stuff) when discovery wants to store a 
> heartbeat or monitor the view - that's then not possible and gets delayed. If 
> the delay is big enough to let the heartbeats time out (or changes to get 
> unnoticed), then the topology can break.
> Thus to avoid this, instead of relying on the size-bound-scheduler, use a 
> dedicated thread for these high priority tasks.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (SLING-5284) use dedicate thread instead of scheduler

[Stefan Egli (JIRA)]

Stefan Egli created SLING-5284:
--

 Summary: use dedicate thread instead of scheduler
 Key: SLING-5284
 URL: https://issues.apache.org/jira/browse/SLING-5284
 Project: Sling
  Issue Type: Improvement
  Components: Extensions
Affects Versions: Discovery Base 1.0.2, Discovery Oak 1.0.2, Discovery Impl 
1.2.0
Reporter: Stefan Egli
Assignee: Stefan Egli
 Fix For: Discovery Impl 1.2.2, Discovery Base 1.0.4, Discovery Oak 
1.0.4


Currently discovery (base/oak/impl) use the sling scheduler for scheduling the 
background jobs that periodically issue heartbeats, ping the topology 
connectors and check if the view is current. It's very important that these 
jobs run at the exact defined periods - delays of a few minutes can break their 
usefullness and in the end cause an instability in the topology. Sling 
scheduler uses a thread-pool which is by definition limited. And if, for some 
reason, this pool is busy doing other stuff, then the job is not executed for a 
certain amount of time. Consider the situation when all the jobs are busy with 
other things (non discovery stuff) when discovery wants to store a heartbeat or 
monitor the view - that's then not possible and gets delayed. If the delay is 
big enough to let the heartbeats time out (or changes to get unnoticed), then 
the topology can break.

Thus to avoid this, instead of relying on the size-bound-scheduler, use a 
dedicated thread for these high priority tasks.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Resolved] (SLING-5284) use dedicate thread instead of scheduler

[Stefan Egli (JIRA)]

 [ 
https://issues.apache.org/jira/browse/SLING-5284?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Stefan Egli resolved SLING-5284.

Resolution: Fixed

implemented in rev 1713477

> use dedicate thread instead of scheduler
> 
>
> Key: SLING-5284
> URL: https://issues.apache.org/jira/browse/SLING-5284
> Project: Sling
>  Issue Type: Improvement
>  Components: Extensions
>Affects Versions: Discovery Impl 1.2.0, Discovery Oak 1.0.2, Discovery 
> Base 1.0.2
>Reporter: Stefan Egli
>Assignee: Stefan Egli
> Fix For: Discovery Impl 1.2.2, Discovery Base 1.1.0, Discovery 
> Oak 1.0.4
>
>
> Currently discovery (base/oak/impl) use the sling scheduler for scheduling 
> the background jobs that periodically issue heartbeats, ping the topology 
> connectors and check if the view is current. It's very important that these 
> jobs run at the exact defined periods - delays of a few minutes can break 
> their usefullness and in the end cause an instability in the topology. Sling 
> scheduler uses a thread-pool which is by definition limited. And if, for some 
> reason, this pool is busy doing other stuff, then the job is not executed for 
> a certain amount of time. Consider the situation when all the jobs are busy 
> with other things (non discovery stuff) when discovery wants to store a 
> heartbeat or monitor the view - that's then not possible and gets delayed. If 
> the delay is big enough to let the heartbeats time out (or changes to get 
> unnoticed), then the topology can break.
> Thus to avoid this, instead of relying on the size-bound-scheduler, use a 
> dedicated thread for these high priority tasks.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Comment Edited] (SLING-5284) use dedicate thread instead of scheduler

[Stefan Egli (JIRA)]

[ 
https://issues.apache.org/jira/browse/SLING-5284?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14996864#comment-14996864
 ] 

Stefan Egli edited comment on SLING-5284 at 11/9/15 5:11 PM:
-

implemented in rev 1713477 and rev 1713480 (version upping of discovery.base to 
1.1.0)


was (Author: egli):
implemented in rev 1713477

> use dedicate thread instead of scheduler
> 
>
> Key: SLING-5284
> URL: https://issues.apache.org/jira/browse/SLING-5284
> Project: Sling
>  Issue Type: Improvement
>  Components: Extensions
>Affects Versions: Discovery Impl 1.2.0, Discovery Oak 1.0.2, Discovery 
> Base 1.0.2
>Reporter: Stefan Egli
>Assignee: Stefan Egli
> Fix For: Discovery Impl 1.2.2, Discovery Base 1.1.0, Discovery 
> Oak 1.0.4
>
>
> Currently discovery (base/oak/impl) use the sling scheduler for scheduling 
> the background jobs that periodically issue heartbeats, ping the topology 
> connectors and check if the view is current. It's very important that these 
> jobs run at the exact defined periods - delays of a few minutes can break 
> their usefullness and in the end cause an instability in the topology. Sling 
> scheduler uses a thread-pool which is by definition limited. And if, for some 
> reason, this pool is busy doing other stuff, then the job is not executed for 
> a certain amount of time. Consider the situation when all the jobs are busy 
> with other things (non discovery stuff) when discovery wants to store a 
> heartbeat or monitor the view - that's then not possible and gets delayed. If 
> the delay is big enough to let the heartbeats time out (or changes to get 
> unnoticed), then the topology can break.
> Thus to avoid this, instead of relying on the size-bound-scheduler, use a 
> dedicated thread for these high priority tasks.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Resolved] (SLING-5280) HeartbeatHandler can also be blocked while holding AnnouncementRegistry lock

[Stefan Egli (JIRA)]

 [ 
https://issues.apache.org/jira/browse/SLING-5280?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Stefan Egli resolved SLING-5280.

Resolution: Fixed

done in rev 1713491

> HeartbeatHandler can also be blocked while holding AnnouncementRegistry lock
> 
>
> Key: SLING-5280
> URL: https://issues.apache.org/jira/browse/SLING-5280
> Project: Sling
>  Issue Type: Bug
>  Components: Extensions
>Affects Versions: Discovery Impl 1.2.0
>Reporter: Stefan Egli
>Assignee: Stefan Egli
>Priority: Critical
> Fix For: Discovery Impl 1.2.2
>
> Attachments: testSlowSessionSaves.fail.txt
>
>
> SLING-5195 introduces a separate thread that periodically checks if the local 
> HeartbeatHandler is properly functional and has written a heartbeat 'recently 
> enough'. If not, it marks the local topology as TOPOLOGY_CHANGING and 
> listeners are thus stepping back correctly (as the local instance is likely 
> to be treated as dead by other instances in the local cluster soon).
> Now this works fine as long as the new, separate thread can operate 
> uninterruptively. But besides the necessity that it is properly scheduled 
> regularly (which it might not, thus we should probably rather use a dedicated 
> thread than rely on the scheduler's pool to be available) it also requires 
> that the check can go ahead without running into a locked monitor.
> https://builds.apache.org/job/sling-trunk-1.8/org.apache.sling$org.apache.sling.discovery.impl/1960/testReport/org.apache.sling.discovery.impl.cluster/RepositoryDelaysTest/testSlowSessionSaves/
>  however reports a situation where the blocked commit was not in 
> {{HeartbeatHandler.issueClusterLocalHeartbeat}} - but was in 
> {{AnnouncementRegistry.checkExpiredAnnouncements}} - and that one does a 
> {{synchronized(this)}} - which in turn blocks precisely this 2nd 
> HeartbeatHandler's monitoring thread - yielding it useless..
> The following log excerpt (grepping thread-3/-4/main) proofs the above 
> described scenario:
> {code}
> 06.11.2015 23:35:22.864 *INFO * [main] RepositoryDelaysTest:  both 
> instances marked as delaying 1min - but with new background checks we should 
> go changing within 3sec
> 06.11.2015 23:35:22.870 *DEBUG* [pool-1-thread-4] HeartbeatHandler: 
> issueConnectorPings: not issuing remote heartbeat yet, startup not yet 
> finished
> 06.11.2015 23:35:22.870 *INFO * [pool-1-thread-4] ArtificialDelay: delay: 
> delaying [secondInstance] 'pre.commit' for 6ms...
> 06.11.2015 23:35:22.870 *INFO * [pool-1-thread-4] ArtificialDelay: delay: 
> delaying [secondInstance] 'pre.commit' now for 6ms...
> 06.11.2015 23:35:22.909 *INFO * [Test-ViewCheckerRunner [firstInstance]] 
> ArtificialDelay: delay: delaying [firstInstance] 'pre.commit' for 59876ms...
> 06.11.2015 23:35:22.909 *INFO * [Test-ViewCheckerRunner [firstInstance]] 
> ArtificialDelay: delay: delaying [firstInstance] 'pre.commit' now for 
> 59876ms...
> 06.11.2015 23:35:23.613 *DEBUG* [pool-1-thread-3] ViewHelper: 
> getEstablishedView: no established view found: 
> /var/discovery/clusterC/establishedView
> 06.11.2015 23:35:23.613 *DEBUG* [pool-1-thread-3] ClusterViewServiceImpl: 
> getClusterView: no view established at the moment. isolated mode
> 06.11.2015 23:35:23.613 *INFO * [pool-1-thread-3] BaseDiscoveryService: 
> getTopology: undefined cluster view: NO_ESTABLISHED_VIEW] 
> org.apache.sling.discovery.base.commons.UndefinedClusterViewException: no 
> established view at the moment
> 06.11.2015 23:35:23.613 *INFO * [pool-1-thread-3] MinEventDelayHandler: 
> asyncDelay.run: done delaying. new view (still/again) not current, delaying 
> again
> 06.11.2015 23:35:23.613 *TRACE* [pool-1-thread-3] MinEventDelayHandler: 
> runAfter: trying with scheduler.fireJob
> 06.11.2015 23:35:23.613 *INFO * [pool-1-thread-3] MinEventDelayHandler: 
> triggerAsyncDelaying: asynch delaying of 1 triggered: true
> 06.11.2015 23:35:23.705 *INFO * [pool-1-thread-3] ClusterViewServiceImpl: 
> getClusterView: the local instance (1b6e7530-0d41-46e7-8471-6ea7f5d3c2bc) is 
> currently not included in the existing established view! This is normal at 
> startup. At other times is pseudo-network-partitioning is an indicator for 
> repository/network-delays or clocks-out-of-sync (SLING-3432). (increasing the 
> heartbeatTimeout can help as a workaround too) The local instance will stay 
> in TOPOLOGY_CHANGING or pre _INIT mode until a new vote was successful.
> 06.11.2015 23:35:23.705 *INFO * [pool-1-thread-3] BaseDiscoveryService: 
> getTopology: undefined cluster view: ISOLATED_FROM_TOPOLOGY] 
> org.apache.sling.discovery.base.commons.UndefinedClusterViewException: 
> established view does not include local instance - isolated
> 06.11.2015 23:35:23.705 *INFO * [pool-1-thread-3] 

[jira] [Comment Edited] (SLING-5269) Sling Pipes IP clearance

[Nicolas Peltier (JIRA)]

[ 
https://issues.apache.org/jira/browse/SLING-5269?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14996741#comment-14996741
 ] 

Nicolas Peltier edited comment on SLING-5269 at 11/9/15 3:45 PM:
-

fyi [~bdelacretaz][~olli], software grant scan is sent at secret...@apache.org


was (Author: npeltier):
fyi [~bdelacretaz][~olli], software grant scan is sent

> Sling Pipes IP clearance
> 
>
> Key: SLING-5269
> URL: https://issues.apache.org/jira/browse/SLING-5269
> Project: Sling
>  Issue Type: Task
>  Components: Extensions
>Reporter: Oliver Lietz
>Assignee: Oliver Lietz
>
> This issue tracks the IP clearance for the donation of Sling Pipes 
> (SLING-5134).



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Re: Sling Tooling IDE & IDE Independence

[Andreas Schaefer Sr.]

That is fine with me. The only thing is that IntelliJ will not resolve 
commons-io and so I had to add it manually to the API pom.xml in order to 
develop.

- Andy

> On Nov 8, 2015, at 3:05 PM, Robert Munteanu  wrote:
> 
> Hi Andy,
> 
> On Sun, 2015-11-08 at 12:09 -0800, Andreas Schaefer Sr. wrote:
>> Hi
>> 
>> When investigating how to design the separation of the “Sling
>> Connector” code from the Eclipse plugin to create an IDE independent
>> code base I saw that most of the Maven dependencies are drawn from
>> the p2.eclipse-plugin repository.
>> 
>> This might create problems when adding the code to other IDE but for
>> sure it messes up my IntelliJ IDE as it does not find and resolves
>> these dependencies correctly.
>> 
>> Shouldn’t we create our own set of dependencies in order to support
>> multiple IDEs?
> 
> At this moment I don't know enough about how to build other plugins to
> be able to tell what is best.
> 
> I would suggest that we first aim to make the various plugins usable
> for other IDEs, and then set our sights on the next target :-)
> 
> Thanks,
> 
> Robert
> 

[jira] [Resolved] (SLING-5286) re-activate fast topology change propagation

[Stefan Egli (JIRA)]

 [ 
https://issues.apache.org/jira/browse/SLING-5286?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Stefan Egli resolved SLING-5286.

Resolution: Fixed

done in rev 1713478

> re-activate fast topology change propagation
> 
>
> Key: SLING-5286
> URL: https://issues.apache.org/jira/browse/SLING-5286
> Project: Sling
>  Issue Type: Improvement
>  Components: Extensions
>Affects Versions: Discovery Impl 1.2.0, Discovery Oak 1.0.2
>Reporter: Stefan Egli
>Assignee: Stefan Egli
> Fix For: Discovery Impl 1.2.2, Discovery Oak 1.0.4
>
>
> With the discovery.base refactoring one functionality got lost: 
> discovery.impl used to immediately ping the topology connectors upon any 
> change in the local cluster. This speeds up change propagation 'from leafs to 
> root' at least - while vice-versa this of course is impossible. This feature 
> should be re-added.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (SLING-5269) Sling Pipes IP clearance

[Nicolas Peltier (JIRA)]

[ 
https://issues.apache.org/jira/browse/SLING-5269?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14996741#comment-14996741
 ] 

Nicolas Peltier commented on SLING-5269:


fyi [~bdelacretaz][~olli], software grant scan is sent

> Sling Pipes IP clearance
> 
>
> Key: SLING-5269
> URL: https://issues.apache.org/jira/browse/SLING-5269
> Project: Sling
>  Issue Type: Task
>  Components: Extensions
>Reporter: Oliver Lietz
>Assignee: Oliver Lietz
>
> This issue tracks the IP clearance for the donation of Sling Pipes 
> (SLING-5134).



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (SLING-5285) more aggressive self-check for heartbeat timeout

[Stefan Egli (JIRA)]

Stefan Egli created SLING-5285:
--

 Summary: more aggressive self-check for heartbeat timeout
 Key: SLING-5285
 URL: https://issues.apache.org/jira/browse/SLING-5285
 Project: Sling
  Issue Type: Improvement
  Components: Extensions
Affects Versions: Discovery Impl 1.2.0
Reporter: Stefan Egli
Assignee: Stefan Egli
 Fix For: Discovery Impl 1.2.2


SLING-5195 introduced a self-check that was monitoring if the HeartbeatHandler 
was properly storing the heartbeats regularly. This is done because there are 
different reasons why that might not be the case, eg: the HeartbeatHandler 
could be blocked because of another long-running-commit happening locally - or 
it might be blocked due to thread-pool-exhaustion - or perhaps something yet 
different.

The check was setting off an alarm when the time-since-last-heartbeat was 
bigger than a *heartbeatTimeout*. This however is not sufficient. The 
comparison should be much more aggressive. It should compare against a 
*heartbeatTimeout minus 2 times heartbeatInterval* to have enough safety 
margin. _2 times_ because 1 time is actually the very minimum: this background 
check only _runs_ every heartbeatInterval, so in the worst case it could run 
just _heartbeatInterval_ many seconds before the timeout hits - and still be 
too late by a fraction. So 1 is the very minimum. The _2_ is actually adding a 
safety margin of 1 _heartbeatInterval_ only.

*Note:* this also means that you should configure the heartbeatTimeout at least 
4-5 times the heartbeatInterval.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (SLING-5286) re-activate fast topology change propagation

[Stefan Egli (JIRA)]

Stefan Egli created SLING-5286:
--

 Summary: re-activate fast topology change propagation
 Key: SLING-5286
 URL: https://issues.apache.org/jira/browse/SLING-5286
 Project: Sling
  Issue Type: Improvement
  Components: Extensions
Affects Versions: Discovery Oak 1.0.2, Discovery Impl 1.2.0
Reporter: Stefan Egli
Assignee: Stefan Egli
 Fix For: Discovery Impl 1.2.2, Discovery Oak 1.0.4


With the discovery.base refactoring one functionality got lost: discovery.impl 
used to immediately ping the topology connectors upon any change in the local 
cluster. This speeds up change propagation 'from leafs to root' at least - 
while vice-versa this of course is impossible. This feature should be re-added.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Re: SIGSEGV on jenkins for sling-trunk-1.7

[Stefan Egli]

Hi,

Coming back to this thread. There was another occurrence of OOME in a
recent run [2]. What about increasing the memory (via MAVEN_OPTS?) on this
jenkins job? I'd volunteer to do this but don't seem to have enough
jenkins-karma. Anyone?

Cheers,
Stefan
--
[2] https://builds.apache.org/job/sling-trunk-1.8/1977/console

On 05/11/15 18:32, "Stefan Egli"  wrote:

>On 05/11/15 18:22, "Robert Munteanu"  wrote:
>
>>On Thu, 2015-11-05 at 17:57 +0100, Stefan Egli wrote:
>>> Hi,
>>> 
>>> There was this SIGSEGV happening in the previous run for sling-trunk-
>>> 1.7
>>> [0].
>>> 
>>> Just a wild guess if it would be similar to [1]: perhaps the process
>>> doesn't have enough java heap too?
>>
>>That would be https://issues.apache.org/jira/browse/INFRA-10557 . It
>>has no solution though, just complatins :-)
>>
>>I am not sure that adding more memory will help - I don't think it
>>fails on the first GC. Perhaps we can use a more recent Java version?
>>
>>I see that on Jenkins we have 'JDK 1.7 ( latest )', but 7u25 is
>>definitely not latest :-) I have switched to 'OpenJDK 1.7 ( Ubuntu only
>>)', let's see if that helps.
>
>Ok cool, let's see.
>
>Cheers,
>Stefan
>
>>
>>Robert
>>
>>
>>
>>> 
>>> How can we increase that? (I've seen OOME on jenkins earlier
>>> actually, so
>>> I think it would be good anyway)
>>> 
>>> #
>>> # A fatal error has been detected by the Java Runtime Environment:
>>> #
>>> #  SIGSEGV (0xb) at pc=0xf6814654, pid=1179, tid=2711087936
>>> #
>>> # JRE version: 7.0_25-b15
>>> # Java VM: Java HotSpot(TM) Server VM (23.25-b01 mixed mode linux-x86
>>> )
>>> # Problematic frame:
>>> # C  [libnet.so+0x14654]  _fini+0x1d0c
>>> #
>>> # Failed to write core dump. Core dumps have been disabled. To enable
>>> core
>>> dumping, try "ulimit -c unlimited" before starting Java again
>>> #
>>> # An error report file with more information is saved as:
>>> # 
>>> /home/jenkins/jenkins-slave/workspace/sling-trunk-
>>> 1.7/trunk/bundles/scripti
>>> ng/sightly/testing/target/oak-35596/hs_err_pid1179.log
>>> #
>>> # If you would like to submit a bug report, please visit:
>>> #   http://bugreport.sun.com/bugreport/crash.jsp
>>> # The crash happened outside the Java Virtual Machine in native code.
>>> # See problematic frame for where to report the bug.
>>> #
>>> 
>>> Cheers,
>>> Stefan
>>> --
>>> [0] - https://builds.apache.org/job/sling-trunk-1.7/2667/console
>>> [1] - http://stackoverflow.com/questions/21964620/java-7-update-25-cr
>>> ash
>>> 
>>> 
>>
>
>

AW: [VOTE] Release Apache Sling Commons Testing 2.0.20, Commons JSON 2.0.14, Maven Sling Plugin 2.1.4 (2nd)

[Stefan Seifert]

+1

[VOTE] Release Apache Sling Commons Testing 2.0.20, Commons JSON 2.0.14, Maven Sling Plugin 2.1.4 (2nd)

[Stefan Seifert]

Hi,

Apache Sling Commons Testing 2.0.20  - 4 Issues
https://issues.apache.org/jira/browse/SLING/fixforversion/12331987

Apache Sling Commons JSON 2.0.14  - 4 Issues
https://issues.apache.org/jira/browse/SLING/fixforversion/12333769

Apache Sling Maven Sling Plugin 2.1.4  - 2 Issues
https://issues.apache.org/jira/browse/SLING/fixforversion/12334045

Staging repository:
https://repository.apache.org/content/repositories/orgapachesling-1365/

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 1365 /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

[RESULT] [VOTE] Release Apache Sling Testing OSGi Mock 1.7.0

[Stefan Seifert]

Hi,

The vote has passed with the following result :

+1 (binding): Stefan Seifert, Carsten Ziegeler, Stefan Egli, Daniel Klco

I will copy this release to the Sling dist directory and
promote the artifacts to the central Maven repository.


stefan

[jira] [Closed] (SLING-5198) osgi-mock: Add basic ConfigurationAdmin support

[Stefan Seifert (JIRA)]

 [ 
https://issues.apache.org/jira/browse/SLING-5198?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Stefan Seifert closed SLING-5198.
-

> osgi-mock: Add basic ConfigurationAdmin support
> ---
>
> Key: SLING-5198
> URL: https://issues.apache.org/jira/browse/SLING-5198
> Project: Sling
>  Issue Type: New Feature
>  Components: Testing
>Reporter: Stefan Seifert
>Assignee: Stefan Seifert
>  Labels: mocks
> Fix For: Testing OSGi Mock 1.7.0
>
>
> we need basic ConfigurationAdmin support to be able to provide a 
> configuration for an OSGi service registered in the mock environment where 
> the registration code is not under control of the test code.
> example: set different properties for ResourceResolverFactoryActivator which 
> is registered internally by sling-mock when getting a resource resolver.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Closed] (SLING-5143) osgi-mock: MockBundleContext is not thread-safe when using iterators

[Stefan Seifert (JIRA)]

 [ 
https://issues.apache.org/jira/browse/SLING-5143?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Stefan Seifert closed SLING-5143.
-

> osgi-mock: MockBundleContext is not thread-safe when using iterators
> 
>
> Key: SLING-5143
> URL: https://issues.apache.org/jira/browse/SLING-5143
> Project: Sling
>  Issue Type: Bug
>  Components: Testing
>Affects Versions: Testing OSGi Mock 1.6.0
>Reporter: Stefan Seifert
>Assignee: Stefan Seifert
>Priority: Minor
>  Labels: mocks
> Fix For: Testing OSGi Mock 1.7.0
>
>
> SLING-4845 introduced synchronized wrappers for the sets, maps and a list 
> used internally by MockBundleContext to make it thread-safe.
> this does not cover all cases e.g. when iterating over the set oder map, 
> sometimes errors like this still occur:
> {noformat}
> [Apache Sling JCR Resource Event Queue Processor for path '/'] WARN 
> org.apache.sling.jcr.resource.internal.JcrResourceListener - 
> processOsgiEventQueue: Unexpected problem processing event 
> {event.topics=org/apache/sling/api/resource/Resource/ADDED, userid=admin, 
> resourceAddedAttributes=[Ljava.lang.String;@68fbe319, path=/content}
> java.util.ConcurrentModificationException
>   at java.util.TreeMap$PrivateEntryIterator.nextEntry(TreeMap.java:1207)
>   at java.util.TreeMap$KeyIterator.next(TreeMap.java:1261)
>   at 
> org.apache.sling.testing.mock.osgi.MockBundleContext.getServiceReferences(MockBundleContext.java:188)
>   at 
> org.apache.sling.testing.mock.osgi.MockBundleContext.getServiceReference(MockBundleContext.java:169)
>   at 
> org.apache.sling.jcr.resource.internal.JcrResourceListener.getResourceResolver(JcrResourceListener.java:353)
>   at 
> org.apache.sling.jcr.resource.internal.JcrResourceListener.processOsgiEventQueue(JcrResourceListener.java:392)
>   at 
> org.apache.sling.jcr.resource.internal.JcrResourceListener$1.run(JcrResourceListener.java:131)
>   at java.lang.Thread.run(Thread.java:745)
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (SLING-5280) HeartbeatHandler can also be blocked while holding AnnouncementRegistry lock

[Stefan Egli (JIRA)]

Stefan Egli created SLING-5280:
--

 Summary: HeartbeatHandler can also be blocked while holding 
AnnouncementRegistry lock
 Key: SLING-5280
 URL: https://issues.apache.org/jira/browse/SLING-5280
 Project: Sling
  Issue Type: Bug
  Components: Extensions
Affects Versions: Discovery Impl 1.2.0
Reporter: Stefan Egli
Assignee: Stefan Egli
Priority: Critical
 Fix For: Discovery Impl 1.2.2


SLING-5195 introduces a separate thread that periodically checks if the local 
HeartbeatHandler is properly functional and has written a heartbeat 'recently 
enough'. If not, it marks the local topology as TOPOLOGY_CHANGING and listeners 
are thus stepping back correctly (as the local instance is likely to be treated 
as dead by other instances in the local cluster soon).

Now this works fine as long as the new, separate thread can operate 
uninterruptively. But besides the necessity that it is properly scheduled 
regularly (which it might not, thus we should probably rather use a dedicated 
thread than rely on the scheduler's pool to be available) it also requires that 
the check can go ahead without running into a locked monitor.

https://builds.apache.org/job/sling-trunk-1.8/org.apache.sling$org.apache.sling.discovery.impl/1960/testReport/org.apache.sling.discovery.impl.cluster/RepositoryDelaysTest/testSlowSessionSaves/
 however reports a situation where the blocked commit was not in 
{{HeartbeatHandler.issueClusterLocalHeartbeat}} - but was in 
{{AnnouncementRegistry.checkExpiredAnnouncements}} - and that one does a 
{{synchronized(this)}} - which in turn blocks precisely this 2nd 
HeartbeatHandler's monitoring thread - yielding it useless..

The following log excerpt (grepping thread-3/-4/main) proofs the above 
described scenario:
{code}
06.11.2015 23:35:22.864 *INFO * [main] RepositoryDelaysTest:  both 
instances marked as delaying 1min - but with new background checks we should go 
changing within 3sec
06.11.2015 23:35:22.870 *DEBUG* [pool-1-thread-4] HeartbeatHandler: 
issueConnectorPings: not issuing remote heartbeat yet, startup not yet finished
06.11.2015 23:35:22.870 *INFO * [pool-1-thread-4] ArtificialDelay: delay: 
delaying [secondInstance] 'pre.commit' for 6ms...
06.11.2015 23:35:22.870 *INFO * [pool-1-thread-4] ArtificialDelay: delay: 
delaying [secondInstance] 'pre.commit' now for 6ms...
06.11.2015 23:35:22.909 *INFO * [Test-ViewCheckerRunner [firstInstance]] 
ArtificialDelay: delay: delaying [firstInstance] 'pre.commit' for 59876ms...
06.11.2015 23:35:22.909 *INFO * [Test-ViewCheckerRunner [firstInstance]] 
ArtificialDelay: delay: delaying [firstInstance] 'pre.commit' now for 59876ms...
06.11.2015 23:35:23.613 *DEBUG* [pool-1-thread-3] ViewHelper: 
getEstablishedView: no established view found: 
/var/discovery/clusterC/establishedView
06.11.2015 23:35:23.613 *DEBUG* [pool-1-thread-3] ClusterViewServiceImpl: 
getClusterView: no view established at the moment. isolated mode
06.11.2015 23:35:23.613 *INFO * [pool-1-thread-3] BaseDiscoveryService: 
getTopology: undefined cluster view: NO_ESTABLISHED_VIEW] 
org.apache.sling.discovery.base.commons.UndefinedClusterViewException: no 
established view at the moment
06.11.2015 23:35:23.613 *INFO * [pool-1-thread-3] MinEventDelayHandler: 
asyncDelay.run: done delaying. new view (still/again) not current, delaying 
again
06.11.2015 23:35:23.613 *TRACE* [pool-1-thread-3] MinEventDelayHandler: 
runAfter: trying with scheduler.fireJob
06.11.2015 23:35:23.613 *INFO * [pool-1-thread-3] MinEventDelayHandler: 
triggerAsyncDelaying: asynch delaying of 1 triggered: true
06.11.2015 23:35:23.705 *INFO * [pool-1-thread-3] ClusterViewServiceImpl: 
getClusterView: the local instance (1b6e7530-0d41-46e7-8471-6ea7f5d3c2bc) is 
currently not included in the existing established view! This is normal at 
startup. At other times is pseudo-network-partitioning is an indicator for 
repository/network-delays or clocks-out-of-sync (SLING-3432). (increasing the 
heartbeatTimeout can help as a workaround too) The local instance will stay in 
TOPOLOGY_CHANGING or pre _INIT mode until a new vote was successful.
06.11.2015 23:35:23.705 *INFO * [pool-1-thread-3] BaseDiscoveryService: 
getTopology: undefined cluster view: ISOLATED_FROM_TOPOLOGY] 
org.apache.sling.discovery.base.commons.UndefinedClusterViewException: 
established view does not include local instance - isolated
06.11.2015 23:35:23.705 *INFO * [pool-1-thread-3] MinEventDelayHandler: 
asyncDelay.run: done delaying. new view (still/again) not current, delaying 
again
06.11.2015 23:35:23.705 *TRACE* [pool-1-thread-3] MinEventDelayHandler: 
runAfter: trying with scheduler.fireJob
06.11.2015 23:35:23.705 *INFO * [pool-1-thread-3] MinEventDelayHandler: 
triggerAsyncDelaying: asynch delaying of 1 triggered: true
06.11.2015 23:35:23.840 *DEBUG* [pool-1-thread-3] HeartbeatHandler: 

[jira] [Commented] (SLING-5280) HeartbeatHandler can also be blocked while holding AnnouncementRegistry lock

[Stefan Egli (JIRA)]

[ 
https://issues.apache.org/jira/browse/SLING-5280?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14996391#comment-14996391
 ] 

Stefan Egli commented on SLING-5280:


So it seems the only solution to this very problem is to make this 
2nd-HeartbeatHandler-self-monitor-check non-blocking at all times - which means 
it must not go into the AnnouncementRegistry as that might be blocked

> HeartbeatHandler can also be blocked while holding AnnouncementRegistry lock
> 
>
> Key: SLING-5280
> URL: https://issues.apache.org/jira/browse/SLING-5280
> Project: Sling
>  Issue Type: Bug
>  Components: Extensions
>Affects Versions: Discovery Impl 1.2.0
>Reporter: Stefan Egli
>Assignee: Stefan Egli
>Priority: Critical
> Fix For: Discovery Impl 1.2.2
>
>
> SLING-5195 introduces a separate thread that periodically checks if the local 
> HeartbeatHandler is properly functional and has written a heartbeat 'recently 
> enough'. If not, it marks the local topology as TOPOLOGY_CHANGING and 
> listeners are thus stepping back correctly (as the local instance is likely 
> to be treated as dead by other instances in the local cluster soon).
> Now this works fine as long as the new, separate thread can operate 
> uninterruptively. But besides the necessity that it is properly scheduled 
> regularly (which it might not, thus we should probably rather use a dedicated 
> thread than rely on the scheduler's pool to be available) it also requires 
> that the check can go ahead without running into a locked monitor.
> https://builds.apache.org/job/sling-trunk-1.8/org.apache.sling$org.apache.sling.discovery.impl/1960/testReport/org.apache.sling.discovery.impl.cluster/RepositoryDelaysTest/testSlowSessionSaves/
>  however reports a situation where the blocked commit was not in 
> {{HeartbeatHandler.issueClusterLocalHeartbeat}} - but was in 
> {{AnnouncementRegistry.checkExpiredAnnouncements}} - and that one does a 
> {{synchronized(this)}} - which in turn blocks precisely this 2nd 
> HeartbeatHandler's monitoring thread - yielding it useless..
> The following log excerpt (grepping thread-3/-4/main) proofs the above 
> described scenario:
> {code}
> 06.11.2015 23:35:22.864 *INFO * [main] RepositoryDelaysTest:  both 
> instances marked as delaying 1min - but with new background checks we should 
> go changing within 3sec
> 06.11.2015 23:35:22.870 *DEBUG* [pool-1-thread-4] HeartbeatHandler: 
> issueConnectorPings: not issuing remote heartbeat yet, startup not yet 
> finished
> 06.11.2015 23:35:22.870 *INFO * [pool-1-thread-4] ArtificialDelay: delay: 
> delaying [secondInstance] 'pre.commit' for 6ms...
> 06.11.2015 23:35:22.870 *INFO * [pool-1-thread-4] ArtificialDelay: delay: 
> delaying [secondInstance] 'pre.commit' now for 6ms...
> 06.11.2015 23:35:22.909 *INFO * [Test-ViewCheckerRunner [firstInstance]] 
> ArtificialDelay: delay: delaying [firstInstance] 'pre.commit' for 59876ms...
> 06.11.2015 23:35:22.909 *INFO * [Test-ViewCheckerRunner [firstInstance]] 
> ArtificialDelay: delay: delaying [firstInstance] 'pre.commit' now for 
> 59876ms...
> 06.11.2015 23:35:23.613 *DEBUG* [pool-1-thread-3] ViewHelper: 
> getEstablishedView: no established view found: 
> /var/discovery/clusterC/establishedView
> 06.11.2015 23:35:23.613 *DEBUG* [pool-1-thread-3] ClusterViewServiceImpl: 
> getClusterView: no view established at the moment. isolated mode
> 06.11.2015 23:35:23.613 *INFO * [pool-1-thread-3] BaseDiscoveryService: 
> getTopology: undefined cluster view: NO_ESTABLISHED_VIEW] 
> org.apache.sling.discovery.base.commons.UndefinedClusterViewException: no 
> established view at the moment
> 06.11.2015 23:35:23.613 *INFO * [pool-1-thread-3] MinEventDelayHandler: 
> asyncDelay.run: done delaying. new view (still/again) not current, delaying 
> again
> 06.11.2015 23:35:23.613 *TRACE* [pool-1-thread-3] MinEventDelayHandler: 
> runAfter: trying with scheduler.fireJob
> 06.11.2015 23:35:23.613 *INFO * [pool-1-thread-3] MinEventDelayHandler: 
> triggerAsyncDelaying: asynch delaying of 1 triggered: true
> 06.11.2015 23:35:23.705 *INFO * [pool-1-thread-3] ClusterViewServiceImpl: 
> getClusterView: the local instance (1b6e7530-0d41-46e7-8471-6ea7f5d3c2bc) is 
> currently not included in the existing established view! This is normal at 
> startup. At other times is pseudo-network-partitioning is an indicator for 
> repository/network-delays or clocks-out-of-sync (SLING-3432). (increasing the 
> heartbeatTimeout can help as a workaround too) The local instance will stay 
> in TOPOLOGY_CHANGING or pre _INIT mode until a new vote was successful.
> 06.11.2015 23:35:23.705 *INFO * [pool-1-thread-3] BaseDiscoveryService: 
> getTopology: undefined cluster view: ISOLATED_FROM_TOPOLOGY] 
> 

[jira] [Updated] (SLING-5280) HeartbeatHandler can also be blocked while holding AnnouncementRegistry lock

[Stefan Egli (JIRA)]

 [ 
https://issues.apache.org/jira/browse/SLING-5280?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Stefan Egli updated SLING-5280:
---
Attachment: testSlowSessionSaves.fail.txt

Attaching [^testSlowSessionSaves.fail.txt] with the full console output from 
jenkins

> HeartbeatHandler can also be blocked while holding AnnouncementRegistry lock
> 
>
> Key: SLING-5280
> URL: https://issues.apache.org/jira/browse/SLING-5280
> Project: Sling
>  Issue Type: Bug
>  Components: Extensions
>Affects Versions: Discovery Impl 1.2.0
>Reporter: Stefan Egli
>Assignee: Stefan Egli
>Priority: Critical
> Fix For: Discovery Impl 1.2.2
>
> Attachments: testSlowSessionSaves.fail.txt
>
>
> SLING-5195 introduces a separate thread that periodically checks if the local 
> HeartbeatHandler is properly functional and has written a heartbeat 'recently 
> enough'. If not, it marks the local topology as TOPOLOGY_CHANGING and 
> listeners are thus stepping back correctly (as the local instance is likely 
> to be treated as dead by other instances in the local cluster soon).
> Now this works fine as long as the new, separate thread can operate 
> uninterruptively. But besides the necessity that it is properly scheduled 
> regularly (which it might not, thus we should probably rather use a dedicated 
> thread than rely on the scheduler's pool to be available) it also requires 
> that the check can go ahead without running into a locked monitor.
> https://builds.apache.org/job/sling-trunk-1.8/org.apache.sling$org.apache.sling.discovery.impl/1960/testReport/org.apache.sling.discovery.impl.cluster/RepositoryDelaysTest/testSlowSessionSaves/
>  however reports a situation where the blocked commit was not in 
> {{HeartbeatHandler.issueClusterLocalHeartbeat}} - but was in 
> {{AnnouncementRegistry.checkExpiredAnnouncements}} - and that one does a 
> {{synchronized(this)}} - which in turn blocks precisely this 2nd 
> HeartbeatHandler's monitoring thread - yielding it useless..
> The following log excerpt (grepping thread-3/-4/main) proofs the above 
> described scenario:
> {code}
> 06.11.2015 23:35:22.864 *INFO * [main] RepositoryDelaysTest:  both 
> instances marked as delaying 1min - but with new background checks we should 
> go changing within 3sec
> 06.11.2015 23:35:22.870 *DEBUG* [pool-1-thread-4] HeartbeatHandler: 
> issueConnectorPings: not issuing remote heartbeat yet, startup not yet 
> finished
> 06.11.2015 23:35:22.870 *INFO * [pool-1-thread-4] ArtificialDelay: delay: 
> delaying [secondInstance] 'pre.commit' for 6ms...
> 06.11.2015 23:35:22.870 *INFO * [pool-1-thread-4] ArtificialDelay: delay: 
> delaying [secondInstance] 'pre.commit' now for 6ms...
> 06.11.2015 23:35:22.909 *INFO * [Test-ViewCheckerRunner [firstInstance]] 
> ArtificialDelay: delay: delaying [firstInstance] 'pre.commit' for 59876ms...
> 06.11.2015 23:35:22.909 *INFO * [Test-ViewCheckerRunner [firstInstance]] 
> ArtificialDelay: delay: delaying [firstInstance] 'pre.commit' now for 
> 59876ms...
> 06.11.2015 23:35:23.613 *DEBUG* [pool-1-thread-3] ViewHelper: 
> getEstablishedView: no established view found: 
> /var/discovery/clusterC/establishedView
> 06.11.2015 23:35:23.613 *DEBUG* [pool-1-thread-3] ClusterViewServiceImpl: 
> getClusterView: no view established at the moment. isolated mode
> 06.11.2015 23:35:23.613 *INFO * [pool-1-thread-3] BaseDiscoveryService: 
> getTopology: undefined cluster view: NO_ESTABLISHED_VIEW] 
> org.apache.sling.discovery.base.commons.UndefinedClusterViewException: no 
> established view at the moment
> 06.11.2015 23:35:23.613 *INFO * [pool-1-thread-3] MinEventDelayHandler: 
> asyncDelay.run: done delaying. new view (still/again) not current, delaying 
> again
> 06.11.2015 23:35:23.613 *TRACE* [pool-1-thread-3] MinEventDelayHandler: 
> runAfter: trying with scheduler.fireJob
> 06.11.2015 23:35:23.613 *INFO * [pool-1-thread-3] MinEventDelayHandler: 
> triggerAsyncDelaying: asynch delaying of 1 triggered: true
> 06.11.2015 23:35:23.705 *INFO * [pool-1-thread-3] ClusterViewServiceImpl: 
> getClusterView: the local instance (1b6e7530-0d41-46e7-8471-6ea7f5d3c2bc) is 
> currently not included in the existing established view! This is normal at 
> startup. At other times is pseudo-network-partitioning is an indicator for 
> repository/network-delays or clocks-out-of-sync (SLING-3432). (increasing the 
> heartbeatTimeout can help as a workaround too) The local instance will stay 
> in TOPOLOGY_CHANGING or pre _INIT mode until a new vote was successful.
> 06.11.2015 23:35:23.705 *INFO * [pool-1-thread-3] BaseDiscoveryService: 
> getTopology: undefined cluster view: ISOLATED_FROM_TOPOLOGY] 
> org.apache.sling.discovery.base.commons.UndefinedClusterViewException: 
> established view does 

Re: [VOTE] Release Apache Sling Commons Testing 2.0.20, Commons JSON 2.0.14, Maven Sling Plugin 2.1.4 (2nd)

[Stefan Egli]

-0

not sure if we should reuse version numbers for which a vote already
started. sure, SVN tags can be moved, but at least for those that voted
they have already 'seen' this version in a different state and thus the
new vote is prone to be inaccurate if this is not carefully done by the
votee.

I'd rather suggest to skip cancelled versions and bump them instead.

Cheers,
Stefan

On 09/11/15 12:06, "Stefan Seifert"  wrote:

>Hi,
>
>Apache Sling Commons Testing 2.0.20  - 4 Issues
>https://issues.apache.org/jira/browse/SLING/fixforversion/12331987
>
>Apache Sling Commons JSON 2.0.14  - 4 Issues
>https://issues.apache.org/jira/browse/SLING/fixforversion/12333769
>
>Apache Sling Maven Sling Plugin 2.1.4  - 2 Issues
>https://issues.apache.org/jira/browse/SLING/fixforversion/12334045
>
>Staging repository:
>https://repository.apache.org/content/repositories/orgapachesling-1365/
>
>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 1365 /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
>

[jira] [Updated] (SLING-5274) Include authentication in RequestProgressTracker

[Alexander Klimetschek (JIRA)]

 [ 
https://issues.apache.org/jira/browse/SLING-5274?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Alexander Klimetschek updated SLING-5274:
-
Flags: Patch

> Include authentication in RequestProgressTracker
> 
>
> Key: SLING-5274
> URL: https://issues.apache.org/jira/browse/SLING-5274
> Project: Sling
>  Issue Type: Improvement
>  Components: Engine
>Reporter: Alexander Klimetschek
> Attachments: SLING-5274.patch
>
>
> The request progress tracker only starts with the sling filters, after the 
> sling authentication ran through. Since authentication steps can be complex 
> with multiple handlers (just like filters) and can have a major performance 
> impact (custom auth handlers, slow resource resolver login) it would be very 
> useful to include it with detailed information.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (SLING-5277) Performance: per thread script resolver (admin session) is always created even if cache is hit

[Alexander Klimetschek (JIRA)]

 [ 
https://issues.apache.org/jira/browse/SLING-5277?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Alexander Klimetschek updated SLING-5277:
-
Attachment: SLING-5277.patch

Here is a patch: [^SLING-5277.patch]

This makes use of ThreadLocal.initialValue() to create the per thread resolver 
on demand. Quick testing improves performance (as the session is no longer 
cloned immediately and upon hitting the cache is never cloned apparently). 
Should be properly tested though, also in line of SLING-3441.

> Performance: per thread script resolver (admin session) is always created 
> even if cache is hit
> --
>
> Key: SLING-5277
> URL: https://issues.apache.org/jira/browse/SLING-5277
> Project: Sling
>  Issue Type: Bug
>  Components: Servlets
>Reporter: Alexander Klimetschek
> Attachments: SLING-5277.patch
>
>
> Since SLING-3441, for every request, a new admin / privileged session is 
> [created in the 
> SlingServletResolver|https://github.com/apache/sling/blob/trunk/bundles/servlets/resolver/src/main/java/org/apache/sling/servlets/resolver/internal/SlingServletResolver.java#L532].
>  It is created before the script/servlet cache is checked, so in most cases 
> when the cache is hit it is never used, but the cost of creating an extra 
> session (which can vary, especially with concurrent traffic) is incurred.
> The per thread script resolver can be created lazily instead of directly in 
> the event to avoid this.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (SLING-5275) RequestProgressTracker should log microseconds

[Alexander Klimetschek (JIRA)]

 [ 
https://issues.apache.org/jira/browse/SLING-5275?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Alexander Klimetschek updated SLING-5275:
-
Flags: Patch

> RequestProgressTracker should log microseconds
> --
>
> Key: SLING-5275
> URL: https://issues.apache.org/jira/browse/SLING-5275
> Project: Sling
>  Issue Type: Improvement
>  Components: Engine
>Reporter: Alexander Klimetschek
> Attachments: SLING-5275.patch
>
>
> The RequestProgressTracker logs timings as milliseconds. If requests are very 
> fast and in the milliseconds range, more resolution is required for fine 
> tuning.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (SLING-5277) Performance: per thread script resolver (admin session) is always created even if cache is hit

[Alexander Klimetschek (JIRA)]

 [ 
https://issues.apache.org/jira/browse/SLING-5277?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Alexander Klimetschek updated SLING-5277:
-
Flags: Patch

> Performance: per thread script resolver (admin session) is always created 
> even if cache is hit
> --
>
> Key: SLING-5277
> URL: https://issues.apache.org/jira/browse/SLING-5277
> Project: Sling
>  Issue Type: Bug
>  Components: Servlets
>Reporter: Alexander Klimetschek
> Attachments: SLING-5277.patch
>
>
> Since SLING-3441, for every request, a new admin / privileged session is 
> [created in the 
> SlingServletResolver|https://github.com/apache/sling/blob/trunk/bundles/servlets/resolver/src/main/java/org/apache/sling/servlets/resolver/internal/SlingServletResolver.java#L532].
>  It is created before the script/servlet cache is checked, so in most cases 
> when the cache is hit it is never used, but the cost of creating an extra 
> session (which can vary, especially with concurrent traffic) is incurred.
> The per thread script resolver can be created lazily instead of directly in 
> the event to avoid this.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Re: [VOTE] Release Apache Sling Commons Testing 2.0.20, Commons JSON 2.0.14, Maven Sling Plugin 2.1.4

[Stefan Egli]

+1

Cheers,
Stefan

On 06/11/15 22:09, "Stefan Seifert"  wrote:

>Hi,
>
>Apache Sling Commons Testing 2.0.20  - 4 Issues
>https://issues.apache.org/jira/browse/SLING/fixforversion/12331987
>
>Apache Sling Commons JSON 2.0.14  - 3 Issues
>https://issues.apache.org/jira/browse/SLING/fixforversion/12333769
>
>Apache Sling Maven Sling Plugin 2.1.4  - 2 Issues
>https://issues.apache.org/jira/browse/SLING/fixforversion/12334045
>
>Staging repository:
>https://repository.apache.org/content/repositories/orgapachesling-1364/
>
>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 1364 /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
>

[jira] [Created] (SLING-5278) discovery.oak.OakDiscoveryServiceTest.testDescriptorSeqNumChange failed on jenkins

[Stefan Egli (JIRA)]

Stefan Egli created SLING-5278:
--

 Summary: 
discovery.oak.OakDiscoveryServiceTest.testDescriptorSeqNumChange failed on 
jenkins
 Key: SLING-5278
 URL: https://issues.apache.org/jira/browse/SLING-5278
 Project: Sling
  Issue Type: Bug
  Components: Extensions
Affects Versions: Discovery Oak 1.0.2
Reporter: Stefan Egli
Assignee: Stefan Egli
Priority: Minor
 Fix For: Discovery Oak 1.0.4


There were failures for 
discovery.oak.OakDiscoveryServiceTest.testDescriptorSeqNumChange on jenkins:

https://builds.apache.org/job/sling-trunk-1.8/org.apache.sling$org.apache.sling.discovery.oak/1960/testReport/org.apache.sling.discovery.oak/OakDiscoveryServiceTest/testDescriptorSeqNumChange/
https://builds.apache.org/job/sling-trunk-1.8/org.apache.sling$org.apache.sling.discovery.oak/1961/testReport/org.apache.sling.discovery.oak/OakDiscoveryServiceTest/testDescriptorSeqNumChange/
https://builds.apache.org/job/sling-trunk-1.8/org.apache.sling$org.apache.sling.discovery.oak/1967/testReport/org.apache.sling.discovery.oak/OakDiscoveryServiceTest/testDescriptorSeqNumChange/

always with the same pattern:

{code}
Error Message

expected:<3> but was:<2>

Stacktrace

java.lang.AssertionError: expected:<3> but was:<2>
at org.junit.Assert.fail(Assert.java:88)
at org.junit.Assert.failNotEquals(Assert.java:743)
at org.junit.Assert.assertEquals(Assert.java:118)
at org.junit.Assert.assertEquals(Assert.java:555)
at org.junit.Assert.assertEquals(Assert.java:542)
at 
org.apache.sling.discovery.oak.OakDiscoveryServiceTest.testDescriptorSeqNumChange(OakDiscoveryServiceTest.java:167)
{code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Resolved] (SLING-5278) discovery.oak.OakDiscoveryServiceTest.testDescriptorSeqNumChange failed on jenkins

[Stefan Egli (JIRA)]

 [ 
https://issues.apache.org/jira/browse/SLING-5278?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Stefan Egli resolved SLING-5278.

Resolution: Fixed

rev 1713352:
bq. adding a 2sec safety sleep to avoid failing test on jenkins - plus more 
logging in case it reoccurs

> discovery.oak.OakDiscoveryServiceTest.testDescriptorSeqNumChange failed on 
> jenkins
> --
>
> Key: SLING-5278
> URL: https://issues.apache.org/jira/browse/SLING-5278
> Project: Sling
>  Issue Type: Bug
>  Components: Extensions
>Affects Versions: Discovery Oak 1.0.2
>Reporter: Stefan Egli
>Assignee: Stefan Egli
>Priority: Minor
> Fix For: Discovery Oak 1.0.4
>
>
> There were failures for 
> discovery.oak.OakDiscoveryServiceTest.testDescriptorSeqNumChange on jenkins:
> https://builds.apache.org/job/sling-trunk-1.8/org.apache.sling$org.apache.sling.discovery.oak/1960/testReport/org.apache.sling.discovery.oak/OakDiscoveryServiceTest/testDescriptorSeqNumChange/
> https://builds.apache.org/job/sling-trunk-1.8/org.apache.sling$org.apache.sling.discovery.oak/1961/testReport/org.apache.sling.discovery.oak/OakDiscoveryServiceTest/testDescriptorSeqNumChange/
> https://builds.apache.org/job/sling-trunk-1.8/org.apache.sling$org.apache.sling.discovery.oak/1967/testReport/org.apache.sling.discovery.oak/OakDiscoveryServiceTest/testDescriptorSeqNumChange/
> always with the same pattern:
> {code}
> Error Message
> expected:<3> but was:<2>
> Stacktrace
> java.lang.AssertionError: expected:<3> but was:<2>
>   at org.junit.Assert.fail(Assert.java:88)
>   at org.junit.Assert.failNotEquals(Assert.java:743)
>   at org.junit.Assert.assertEquals(Assert.java:118)
>   at org.junit.Assert.assertEquals(Assert.java:555)
>   at org.junit.Assert.assertEquals(Assert.java:542)
>   at 
> org.apache.sling.discovery.oak.OakDiscoveryServiceTest.testDescriptorSeqNumChange(OakDiscoveryServiceTest.java:167)
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (SLING-5276) Validator.validate throws StackOverflowError

[Stefan Seifert (JIRA)]

 [ 
https://issues.apache.org/jira/browse/SLING-5276?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Stefan Seifert updated SLING-5276:
--
Affects Version/s: (was: Commons JSON 2.0.14)
   Commons JSON 2.0.12
Fix Version/s: (was: Commons JSON 2.0.16)
   Commons JSON 2.0.14

> Validator.validate throws StackOverflowError
> 
>
> Key: SLING-5276
> URL: https://issues.apache.org/jira/browse/SLING-5276
> Project: Sling
>  Issue Type: Bug
>  Components: Commons
>Affects Versions: Commons JSON 2.0.12
> Environment: Linux
>Reporter: Krzysztof Otrebski
>Assignee: Stefan Seifert
>Priority: Critical
> Fix For: Commons JSON 2.0.14
>
>
> If I pass string "[" to org.apache.sling.commons.json.util.Validator.validate 
> I will get  StackOverflowError



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Resolved] (SLING-5276) Validator.validate throws StackOverflowError

[Stefan Seifert (JIRA)]

 [ 
https://issues.apache.org/jira/browse/SLING-5276?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Stefan Seifert resolved SLING-5276.
---
Resolution: Fixed

Completed: At revision: 1713371  


> Validator.validate throws StackOverflowError
> 
>
> Key: SLING-5276
> URL: https://issues.apache.org/jira/browse/SLING-5276
> Project: Sling
>  Issue Type: Bug
>  Components: Commons
>Affects Versions: Commons JSON 2.0.12
> Environment: Linux
>Reporter: Krzysztof Otrebski
>Assignee: Stefan Seifert
>Priority: Critical
> Fix For: Commons JSON 2.0.14
>
>
> If I pass string "[" to org.apache.sling.commons.json.util.Validator.validate 
> I will get  StackOverflowError



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Re: what happend to maven-sling-plugin 2.1.2?

[Robert Munteanu]

On Fri, 2015-11-06 at 13:50 +0100, Robert Munteanu wrote:
> Filed INFRA-10729  [3] asking for help finding out the root cause.

Infra fixed it, plugin is now available at 

  http://search.maven.org/#artifactdetails|org.apache.sling|maven-sling
-plugin|2.1.2|maven-plugin

Robert

[jira] [Resolved] (SLING-5279) VotingHandlerTest.setup/teardown failure on jenkins

[Stefan Egli (JIRA)]

 [ 
https://issues.apache.org/jira/browse/SLING-5279?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Stefan Egli resolved SLING-5279.

Resolution: Fixed

made VirtualInstance.stop more reliable in 1713364 - as it looks like a 
VirtualInstance from a former test-run was not yet finished stopping down and 
interfered with a subsequent test.
Plus made tearDown do a NPE check

> VotingHandlerTest.setup/teardown failure on jenkins
> ---
>
> Key: SLING-5279
> URL: https://issues.apache.org/jira/browse/SLING-5279
> Project: Sling
>  Issue Type: Bug
>  Components: Extensions
>Affects Versions: Discovery Impl 1.2.0, Discovery Base 1.0.2
>Reporter: Stefan Egli
>Assignee: Stefan Egli
>Priority: Minor
> Fix For: Discovery Impl 1.2.2, Discovery Base 1.0.4
>
>
> There are several failures on jenkins with the very same pattern: 
> VotingHandlerTest.setup and teardown fail with the following message:
> setup:
> {code}
> javax.jcr.InvalidItemStateException: Unable to update a stale item: 
> item.save()
>   at 
> org.apache.jackrabbit.core.state.SharedItemStateManager$Update.begin(SharedItemStateManager.java:680)
>   at 
> org.apache.jackrabbit.core.state.SharedItemStateManager.beginUpdate(SharedItemStateManager.java:1468)
>   at 
> org.apache.jackrabbit.core.state.SharedItemStateManager.update(SharedItemStateManager.java:1498)
>   at 
> org.apache.jackrabbit.core.state.LocalItemStateManager.update(LocalItemStateManager.java:398)
>   at 
> org.apache.jackrabbit.core.state.XAItemStateManager.update(XAItemStateManager.java:354)
>   at 
> org.apache.jackrabbit.core.state.LocalItemStateManager.update(LocalItemStateManager.java:373)
>   at 
> org.apache.jackrabbit.core.state.SessionItemStateManager.update(SessionItemStateManager.java:274)
>   at 
> org.apache.jackrabbit.core.ItemSaveOperation.perform(ItemSaveOperation.java:258)
>   at 
> org.apache.jackrabbit.core.session.SessionState.perform(SessionState.java:200)
>   at org.apache.jackrabbit.core.ItemImpl.perform(ItemImpl.java:91)
>   at org.apache.jackrabbit.core.ItemImpl.save(ItemImpl.java:329)
>   at 
> org.apache.jackrabbit.core.session.SessionSaveOperation.perform(SessionSaveOperation.java:42)
>   at 
> org.apache.jackrabbit.core.session.SessionState.perform(SessionState.java:200)
>   at org.apache.jackrabbit.core.SessionImpl.perform(SessionImpl.java:355)
>   at org.apache.jackrabbit.core.SessionImpl.save(SessionImpl.java:758)
>   at 
> org.apache.sling.discovery.impl.cluster.voting.VotingHandlerTest.resetRepo(VotingHandlerTest.java:95)
>   at 
> org.apache.sling.discovery.impl.cluster.voting.VotingHandlerTest.setUp(VotingHandlerTest.java:108)
> {code}
> tearDown:
> {code}
> java.lang.NullPointerException: null
>   at 
> org.apache.sling.discovery.impl.cluster.voting.VotingHandlerTest.tearDown(VotingHandlerTest.java:129)
> {code}
> https://builds.apache.org/job/sling-trunk-1.7/org.apache.sling$org.apache.sling.discovery.impl/2686/testReport/org.apache.sling.discovery.impl.cluster.voting/VotingHandlerTest/testVotingYesTwoNodes/
> https://builds.apache.org/job/sling-trunk-1.7/org.apache.sling$org.apache.sling.discovery.impl/2682/testReport/org.apache.sling.discovery.impl.cluster.voting/VotingHandlerTest/testConcurrentVotesFourNodes/
> https://builds.apache.org/job/sling-trunk-1.7/org.apache.sling$org.apache.sling.discovery.impl/2690/testReport/org.apache.sling.discovery.impl.cluster.voting/VotingHandlerTest/testConcurrentVotesFourNodes_2/
> etc



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Resolved] (SLING-4565) Override equals/hashcode for JSON entities

[Timothee Maret (JIRA)]

 [ 
https://issues.apache.org/jira/browse/SLING-4565?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Timothee Maret resolved SLING-4565.
---
   Resolution: Won't Fix
Fix Version/s: Commons JSON 2.0.16

> Override equals/hashcode for JSON entities
> --
>
> Key: SLING-4565
> URL: https://issues.apache.org/jira/browse/SLING-4565
> Project: Sling
>  Issue Type: Improvement
>  Components: Commons
>Affects Versions: Commons JSON 2.0.10
>Reporter: Timothee Maret
> Fix For: Commons JSON 2.0.16
>
>
> JSON entities in the package 
> {code}
> org.apache.sling.commons.json
> {code}
> do not yet override the equals and hashCode methods, leaving the equals to 
> compare references rather than the actual content of the entity.
> This issue is about implementing equals/hashCode on those entities in order 
> to allow meaningful comparisons.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Assigned] (SLING-5276) Validator.validate throws StackOverflowError

[Stefan Seifert (JIRA)]

 [ 
https://issues.apache.org/jira/browse/SLING-5276?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Stefan Seifert reassigned SLING-5276:
-

Assignee: Stefan Seifert

> Validator.validate throws StackOverflowError
> 
>
> Key: SLING-5276
> URL: https://issues.apache.org/jira/browse/SLING-5276
> Project: Sling
>  Issue Type: Bug
>  Components: Commons
>Affects Versions: Commons JSON 2.0.14
> Environment: Linux
>Reporter: Krzysztof Otrebski
>Assignee: Stefan Seifert
>Priority: Critical
>
> If I pass string "[" to org.apache.sling.commons.json.util.Validator.validate 
> I will get  StackOverflowError



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[VOTE CANCELED] Release Apache Sling Commons Testing 2.0.20, Commons JSON 2.0.14, Maven Sling Plugin 2.1.4

[Stefan Seifert]

a bug was found in sling commons validator (SLING-5276).
i'll fix it and do a release of all three libraries again.

stefan


-Ursprüngliche Nachricht-
Von: Stefan Seifert [mailto:sseif...@pro-vision.de] 
Gesendet: Freitag, 6. November 2015 22:09
An: dev@sling.apache.org
Betreff: [VOTE] Release Apache Sling Commons Testing 2.0.20, Commons JSON 
2.0.14, Maven Sling Plugin 2.1.4

Hi,

Apache Sling Commons Testing 2.0.20  - 4 Issues
https://issues.apache.org/jira/browse/SLING/fixforversion/12331987

Apache Sling Commons JSON 2.0.14  - 3 Issues
https://issues.apache.org/jira/browse/SLING/fixforversion/12333769

Apache Sling Maven Sling Plugin 2.1.4  - 2 Issues
https://issues.apache.org/jira/browse/SLING/fixforversion/12334045

Staging repository:
https://repository.apache.org/content/repositories/orgapachesling-1364/

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 1364 /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

[jira] [Created] (SLING-5279) VotingHandlerTest.setup/teardown failure on jenkins

[Stefan Egli (JIRA)]

Stefan Egli created SLING-5279:
--

 Summary: VotingHandlerTest.setup/teardown failure on jenkins
 Key: SLING-5279
 URL: https://issues.apache.org/jira/browse/SLING-5279
 Project: Sling
  Issue Type: Bug
  Components: Extensions
Affects Versions: Discovery Impl 1.2.0, Discovery Base 1.0.2
Reporter: Stefan Egli
Assignee: Stefan Egli
Priority: Minor
 Fix For: Discovery Impl 1.2.2, Discovery Base 1.0.4


There are several failures on jenkins with the very same pattern: 
VotingHandlerTest.setup and teardown fail with the following message:

setup:
{code}
javax.jcr.InvalidItemStateException: Unable to update a stale item: item.save()
at 
org.apache.jackrabbit.core.state.SharedItemStateManager$Update.begin(SharedItemStateManager.java:680)
at 
org.apache.jackrabbit.core.state.SharedItemStateManager.beginUpdate(SharedItemStateManager.java:1468)
at 
org.apache.jackrabbit.core.state.SharedItemStateManager.update(SharedItemStateManager.java:1498)
at 
org.apache.jackrabbit.core.state.LocalItemStateManager.update(LocalItemStateManager.java:398)
at 
org.apache.jackrabbit.core.state.XAItemStateManager.update(XAItemStateManager.java:354)
at 
org.apache.jackrabbit.core.state.LocalItemStateManager.update(LocalItemStateManager.java:373)
at 
org.apache.jackrabbit.core.state.SessionItemStateManager.update(SessionItemStateManager.java:274)
at 
org.apache.jackrabbit.core.ItemSaveOperation.perform(ItemSaveOperation.java:258)
at 
org.apache.jackrabbit.core.session.SessionState.perform(SessionState.java:200)
at org.apache.jackrabbit.core.ItemImpl.perform(ItemImpl.java:91)
at org.apache.jackrabbit.core.ItemImpl.save(ItemImpl.java:329)
at 
org.apache.jackrabbit.core.session.SessionSaveOperation.perform(SessionSaveOperation.java:42)
at 
org.apache.jackrabbit.core.session.SessionState.perform(SessionState.java:200)
at org.apache.jackrabbit.core.SessionImpl.perform(SessionImpl.java:355)
at org.apache.jackrabbit.core.SessionImpl.save(SessionImpl.java:758)
at 
org.apache.sling.discovery.impl.cluster.voting.VotingHandlerTest.resetRepo(VotingHandlerTest.java:95)
at 
org.apache.sling.discovery.impl.cluster.voting.VotingHandlerTest.setUp(VotingHandlerTest.java:108)
{code}

tearDown:
{code}
java.lang.NullPointerException: null
at 
org.apache.sling.discovery.impl.cluster.voting.VotingHandlerTest.tearDown(VotingHandlerTest.java:129)
{code}

https://builds.apache.org/job/sling-trunk-1.7/org.apache.sling$org.apache.sling.discovery.impl/2686/testReport/org.apache.sling.discovery.impl.cluster.voting/VotingHandlerTest/testVotingYesTwoNodes/
https://builds.apache.org/job/sling-trunk-1.7/org.apache.sling$org.apache.sling.discovery.impl/2682/testReport/org.apache.sling.discovery.impl.cluster.voting/VotingHandlerTest/testConcurrentVotesFourNodes/
https://builds.apache.org/job/sling-trunk-1.7/org.apache.sling$org.apache.sling.discovery.impl/2690/testReport/org.apache.sling.discovery.impl.cluster.voting/VotingHandlerTest/testConcurrentVotesFourNodes_2/
etc



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[RESULT] [VOTE] Release Apache Sling IDE Tooling version 1.0.10

[Robert Munteanu]

Hi,

The vote has passed with the following result :

+1 (binding): Robert Munteanu, Stefan Egli, Stefan Seifert, Daniel Klco

I will copy this release to the Sling dist directory.

Thanks,

Robert

[jira] [Commented] (SLING-4565) Override equals/hashcode for JSON entities

[Timothee Maret (JIRA)]

[ 
https://issues.apache.org/jira/browse/SLING-4565?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14996234#comment-14996234
 ] 

Timothee Maret commented on SLING-4565:
---

[~sseif...@pro-vision.de] I think you are right wrt to the performance penalty. 
It makes sense to avoid deep comparison by default. Deep comparison may be 
provided as an util or extra method. But that's outside the initial scope of 
this issue. Closing.

> Override equals/hashcode for JSON entities
> --
>
> Key: SLING-4565
> URL: https://issues.apache.org/jira/browse/SLING-4565
> Project: Sling
>  Issue Type: Improvement
>  Components: Commons
>Affects Versions: Commons JSON 2.0.10
>Reporter: Timothee Maret
>
> JSON entities in the package 
> {code}
> org.apache.sling.commons.json
> {code}
> do not yet override the equals and hashCode methods, leaving the equals to 
> compare references rather than the actual content of the entity.
> This issue is about implementing equals/hashCode on those entities in order 
> to allow meaningful comparisons.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (SLING-5276) Validator.validate throws StackOverflowError

[Stefan Seifert (JIRA)]

[ 
https://issues.apache.org/jira/browse/SLING-5276?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14996282#comment-14996282
 ] 

Stefan Seifert commented on SLING-5276:
---

good catch - this error seemed to be present for a long time as well.
we will fix it before the release.

> Validator.validate throws StackOverflowError
> 
>
> Key: SLING-5276
> URL: https://issues.apache.org/jira/browse/SLING-5276
> Project: Sling
>  Issue Type: Bug
>  Components: Commons
>Affects Versions: Commons JSON 2.0.14
> Environment: Linux
>Reporter: Krzysztof Otrebski
>Assignee: Stefan Seifert
>Priority: Critical
> Fix For: Commons JSON 2.0.16
>
>
> If I pass string "[" to org.apache.sling.commons.json.util.Validator.validate 
> I will get  StackOverflowError



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (SLING-5276) Validator.validate throws StackOverflowError

[Stefan Seifert (JIRA)]

 [ 
https://issues.apache.org/jira/browse/SLING-5276?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Stefan Seifert updated SLING-5276:
--
Fix Version/s: Commons JSON 2.0.16

> Validator.validate throws StackOverflowError
> 
>
> Key: SLING-5276
> URL: https://issues.apache.org/jira/browse/SLING-5276
> Project: Sling
>  Issue Type: Bug
>  Components: Commons
>Affects Versions: Commons JSON 2.0.14
> Environment: Linux
>Reporter: Krzysztof Otrebski
>Assignee: Stefan Seifert
>Priority: Critical
> Fix For: Commons JSON 2.0.16
>
>
> If I pass string "[" to org.apache.sling.commons.json.util.Validator.validate 
> I will get  StackOverflowError



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (SLING-5266) Adding org.mozilla.javascript.ast package in org.apache.sling.scripting.javascript bundle

[Mandeep Gandhi (JIRA)]

 [ 
https://issues.apache.org/jira/browse/SLING-5266?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Mandeep Gandhi updated SLING-5266:
--
Component/s: (was: General)
 Scripting

> Adding org.mozilla.javascript.ast package in 
> org.apache.sling.scripting.javascript  bundle 
> ---
>
> Key: SLING-5266
> URL: https://issues.apache.org/jira/browse/SLING-5266
> Project: Sling
>  Issue Type: Task
>  Components: Scripting
>Reporter: Mandeep Gandhi
>Priority: Critical
> Attachments: SLING-5266.patch
>
>
> There is a need of parsing javascript expression. For achieving this, there 
> is a requirement of adding org.mozilla.javascript.ast package to the existing 
>  bundle (org.apache.sling.scripting.javascript ) and exporting it. 



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (SLING-5266) Adding org.mozilla.javascript.ast package in org.apache.sling.scripting.javascript bundle

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/SLING-5266?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14996400#comment-14996400
 ] 

ASF GitHub Bot commented on SLING-5266:
---

GitHub user welcomemandeep opened a pull request:

https://github.com/apache/sling/pull/110

SLING-5266  Export  org.mozilla.javascript.ast  package

Currently Sling Scripting Javascript Support only exports 
org.mozilla.javascript package which is sufficient for evaluating javascript 
using Rhino but to convert expressions to  parsed AST we need 
org.mozilla.javascript.ast

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/welcomemandeep/sling trunk

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/sling/pull/110.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #110


commit cff28fe9978a07a567d2a302a2aecbe95380b5df
Author: Mandeep Gandhi 
Date:   2015-11-09T11:42:44Z

SLING-5266  Export  org.mozilla.javascript.ast  package
Currently Sling Scripting Javascript Support only exports 
org.mozilla.javascript package which is sufficient for evaluating javascript 
using Rhino but to convert expressions to  parsed AST we need 
org.mozilla.javascript.ast




> Adding org.mozilla.javascript.ast package in 
> org.apache.sling.scripting.javascript  bundle 
> ---
>
> Key: SLING-5266
> URL: https://issues.apache.org/jira/browse/SLING-5266
> Project: Sling
>  Issue Type: Task
>  Components: Scripting
>Reporter: Mandeep Gandhi
>Priority: Critical
> Attachments: SLING-5266.patch
>
>
> There is a need of parsing javascript expression. For achieving this, there 
> is a requirement of adding org.mozilla.javascript.ast package to the existing 
>  bundle (org.apache.sling.scripting.javascript ) and exporting it. 



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[GitHub] sling pull request: SLING-5266 Export org.mozilla.javascript.ast p...

[welcomemandeep]

GitHub user welcomemandeep opened a pull request:

https://github.com/apache/sling/pull/110

SLING-5266  Export  org.mozilla.javascript.ast  package

Currently Sling Scripting Javascript Support only exports 
org.mozilla.javascript package which is sufficient for evaluating javascript 
using Rhino but to convert expressions to  parsed AST we need 
org.mozilla.javascript.ast

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/welcomemandeep/sling trunk

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/sling/pull/110.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #110


commit cff28fe9978a07a567d2a302a2aecbe95380b5df
Author: Mandeep Gandhi 
Date:   2015-11-09T11:42:44Z

SLING-5266  Export  org.mozilla.javascript.ast  package
Currently Sling Scripting Javascript Support only exports 
org.mozilla.javascript package which is sufficient for evaluating javascript 
using Rhino but to convert expressions to  parsed AST we need 
org.mozilla.javascript.ast




---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[jira] [Updated] (SLING-5266) Exporting org.mozilla.javascript.ast package in org.apache.sling.scripting.javascript bundle

[Mandeep Gandhi (JIRA)]

 [ 
https://issues.apache.org/jira/browse/SLING-5266?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Mandeep Gandhi updated SLING-5266:
--
Summary: Exporting org.mozilla.javascript.ast package in 
org.apache.sling.scripting.javascript  bundle   (was: Adding 
org.mozilla.javascript.ast package in org.apache.sling.scripting.javascript  
bundle )

> Exporting org.mozilla.javascript.ast package in 
> org.apache.sling.scripting.javascript  bundle 
> --
>
> Key: SLING-5266
> URL: https://issues.apache.org/jira/browse/SLING-5266
> Project: Sling
>  Issue Type: Task
>  Components: Scripting
>Reporter: Mandeep Gandhi
>Priority: Critical
> Attachments: SLING-5266.patch
>
>
> There is a need of parsing javascript expression. For achieving this, there 
> is a requirement of adding org.mozilla.javascript.ast package to the existing 
>  bundle (org.apache.sling.scripting.javascript ) and exporting it. 



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Re: [VOTE] Release Apache Sling Commons Testing 2.0.20, Commons JSON 2.0.14, Maven Sling Plugin 2.1.4 (2nd)

[Robert Munteanu]

On Mon, 2015-11-09 at 12:30 +0100, Stefan Egli wrote:
> -0
> 
> not sure if we should reuse version numbers for which a vote already
> started. sure, SVN tags can be moved, but at least for those that
> voted
> they have already 'seen' this version in a different state and thus
> the
> new vote is prone to be inaccurate if this is not carefully done by
> the
> votee.
> 
> I'd rather suggest to skip cancelled versions and bump them instead.

-1 from me as well. Not reusing versions is documented at [1]

Note that any changes to the artifacts under vote require a restart
of the process, no matter how trivial. When restarting a vote
version numbers must not be reused, since binaries might have
already been copied around.

That being said, it's pretty easy to miss, suggestions on how to
improve it are welcome.

Robert

[1]: http://sling.apache.org/documentation/development/release-manageme
nt.html#wait-for-the-results

> 
> Cheers,
> Stefan
> 
> On 09/11/15 12:06, "Stefan Seifert"  wrote:
> 
> > Hi,
> > 
> > Apache Sling Commons Testing 2.0.20  - 4 Issues
> > https://issues.apache.org/jira/browse/SLING/fixforversion/12331987
> > 
> > Apache Sling Commons JSON 2.0.14  - 4 Issues
> > https://issues.apache.org/jira/browse/SLING/fixforversion/12333769
> > 
> > Apache Sling Maven Sling Plugin 2.1.4  - 2 Issues
> > https://issues.apache.org/jira/browse/SLING/fixforversion/12334045
> > 
> > Staging repository:
> > https://repository.apache.org/content/repositories/orgapachesling-1
> > 365/
> > 
> > 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 1365 /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
> > 
> 
> 

[VOTE CANCELED] Release Apache Sling Commons Testing 2.0.20, Commons JSON 2.0.14, Maven Sling Plugin 2.1.4 (2nd)

[Stefan Seifert]

forgot policy about not reusing version numbers - makes sense of course.
will do again...

stefan