[RESULT] [VOTE] Release Apache Sling IDE Tooling version 1.0.10
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
Re: [VOTE] Release Apache Sling Commons Testing 2.0.20, Commons JSON 2.0.14, Maven Sling Plugin 2.1.4
+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 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
[ 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] [Commented] (SLING-4565) Override equals/hashcode for JSON entities
[ https://issues.apache.org/jira/browse/SLING-4565?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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] [Resolved] (SLING-4565) Override equals/hashcode for JSON entities
[ 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
[ 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)
[jira] [Commented] (SLING-5276) Validator.validate throws StackOverflowError
[ https://issues.apache.org/jira/browse/SLING-5276?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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
[ 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)
[VOTE CANCELED] Release Apache Sling Commons Testing 2.0.20, Commons JSON 2.0.14, Maven Sling Plugin 2.1.4
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 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)
[jira] [Resolved] (SLING-5279) VotingHandlerTest.setup/teardown failure on jenkins
[ 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-5276) Validator.validate throws StackOverflowError
[ 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)
[jira] [Updated] (SLING-5276) Validator.validate throws StackOverflowError
[ 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)
[VOTE] Release Apache Sling Commons Testing 2.0.20, Commons JSON 2.0.14, Maven Sling Plugin 2.1.4 (2nd)
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
AW: [VOTE] Release Apache Sling Commons Testing 2.0.20, Commons JSON 2.0.14, Maven Sling Plugin 2.1.4 (2nd)
+1
[RESULT] [VOTE] Release Apache Sling Testing OSGi Mock 1.7.0
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
[ 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
[ 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 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
[ https://issues.apache.org/jira/browse/SLING-5280?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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] > org.apach
[jira] [Updated] (SLING-5280) HeartbeatHandler can also be blocked while holding AnnouncementRegistry lock
[ 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 no
Re: [VOTE] Release Apache Sling Commons Testing 2.0.20, Commons JSON 2.0.14, Maven Sling Plugin 2.1.4 (2nd)
-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-5266) Adding org.mozilla.javascript.ast package in org.apache.sling.scripting.javascript bundle
[ 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)
[GitHub] sling pull request: SLING-5266 Export org.mozilla.javascript.ast p...
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] [Commented] (SLING-5266) Adding org.mozilla.javascript.ast package in org.apache.sling.scripting.javascript bundle
[ https://issues.apache.org/jira/browse/SLING-5266?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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)
[jira] [Updated] (SLING-5266) Exporting org.mozilla.javascript.ast package in org.apache.sling.scripting.javascript bundle
[ 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)
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)
forgot policy about not reusing version numbers - makes sense of course. will do again... stefan
[VOTE] Release Apache Sling Commons Testing 2.0.22, Commons JSON 2.0.16, Maven Sling Plugin 2.1.6
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
+1
Re: [VOTE] Release Apache Sling Commons Testing 2.0.22, Commons JSON 2.0.16, Maven Sling Plugin 2.1.6
+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] [Created] (SLING-5281) Allow execution of distribution requests using calling user session
Marius Petria created SLING-5281: Summary: 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 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-5281) Allow execution of distribution requests using calling user session
[ https://issues.apache.org/jira/browse/SLING-5281?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marius Petria resolved SLING-5281. -- Resolution: Fixed Committed revision 1713432. > 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 > > 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] [Updated] (SLING-5281) Allow execution of distribution requests using calling user session
[ 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] [Created] (SLING-5282) cancel sync upon handleDeactivating
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)
[jira] [Resolved] (SLING-5282) cancel sync upon handleDeactivating
[ 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)
[jira] [Created] (SLING-5283) Allow item copy between distribution queues
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] [Resolved] (SLING-5283) Allow item copy between distribution queues
[ 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] [Commented] (SLING-5269) Sling Pipes IP clearance
[ https://issues.apache.org/jira/browse/SLING-5269?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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] [Comment Edited] (SLING-5269) Sling Pipes IP clearance
[ https://issues.apache.org/jira/browse/SLING-5269?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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)
[jira] [Created] (SLING-5284) use dedicate thread instead of scheduler
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] [Created] (SLING-5285) more aggressive self-check for heartbeat timeout
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)
Re: SIGSEGV on jenkins for sling-trunk-1.7
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 >>> >>> >> > >
[jira] [Created] (SLING-5286) re-activate fast topology change propagation
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)
[jira] [Resolved] (SLING-5284) use dedicate thread instead of scheduler
[ 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)
Re: Sling Tooling IDE & IDE Independence
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
[ 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] [Comment Edited] (SLING-5284) use dedicate thread instead of scheduler
[ https://issues.apache.org/jira/browse/SLING-5284?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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-5285) more aggressive self-check for heartbeat timeout
[ https://issues.apache.org/jira/browse/SLING-5285?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Egli resolved SLING-5285. Resolution: Fixed fixed in http://svn.apache.org/viewvc?rev=1713477&view=rev (which was also about SLING-5284) > 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] [Comment Edited] (SLING-5284) use dedicate thread instead of scheduler
[ https://issues.apache.org/jira/browse/SLING-5284?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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] [Resolved] (SLING-5280) HeartbeatHandler can also be blocked while holding AnnouncementRegistry lock
[ 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]
Re: what happend to maven-sling-plugin 2.1.2?
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] [Updated] (SLING-5277) Performance: per thread script resolver (admin session) is always created even if cache is hit
[ 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)
[jira] [Updated] (SLING-5277) Performance: per thread script resolver (admin session) is always created even if cache is hit
[ 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
[ 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-5274) Include authentication in RequestProgressTracker
[ 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] [Commented] (SLING-4937) Drop namespace mapping support
[ https://issues.apache.org/jira/browse/SLING-4937?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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] [Commented] (SLING-3635) [Javascript] Optimization level for byte code generator in Rhino should be configurable
[ https://issues.apache.org/jira/browse/SLING-3635?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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)