[jira] [Comment Edited] (SLING-4216) Limit the number of vanityPath MapEntry

2015-07-15 Thread Alexander Klimetschek (JIRA) 

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

Alexander Klimetschek edited comment on SLING-4216 at 7/15/15 10:08 PM:


[~cziegeler]: {quote} the "cache" contains only a fraction of the paths and 
therefore a fallback to the repository (with a search?) sounds expensive and 
might happen a lot{quote}

FWIW, That's what we are seeing in one case (SLING-4882 is related), with a 
bloom filter size of 1000 and a large repo with 25K vanity paths. The queries 
done on bloom filter misses take 1 to 2 seconds each and run on almost every or 
at least many requests, and their result seems to be never cached.

It seems weird to me to have a cache for something that can be dynamic and 
where you naturally want a LRU type caching, but the cache (the bloom filter) 
is only generated on restarts.


was (Author: alexander.klimetschek):
[~cziegeler]: {quote} the "cache" contains only a fraction of the paths and 
therefore a fallback to the repository (with a search?) sounds expensive and 
might happen a lot{quote}

FWIW, That's what we are seeing in one case, with a bloom filter size of 1000 
and a large repo with 25K vanity paths. The queries done on bloom filter misses 
take 1 to 2 seconds each and run on almost every or at least many requests, and 
their result seems to be never cached.

It seems weird to me to have a cache for something that can be dynamic and 
where you naturally want a LRU type caching, but the cache (the bloom filter) 
is only generated on restarts.

> Limit the number of vanityPath MapEntry 
> 
>
> Key: SLING-4216
> URL: https://issues.apache.org/jira/browse/SLING-4216
> Project: Sling
>  Issue Type: Improvement
>  Components: ResourceResolver
>Reporter: Antonio Sanso
>Assignee: Antonio Sanso
> Fix For: Resource Resolver 1.1.10
>
> Attachments: SLING-4216-patch.txt, SLING-4216-patch.txt, 
> SLING-4216-patch.txt
>
>
> At the moment there isn't any limit to the number of MapEntry that are cached 
> in memory.
> If the number of vanityPaths/alias is extremely high this can cause OOM.
> It would be good to have a way to limit the amount of memory used by the 
> MapEntry cache.



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

[jira] [Commented] (SLING-4216) Limit the number of vanityPath MapEntry

2015-07-15 Thread Alexander Klimetschek (JIRA) 

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

Alexander Klimetschek commented on SLING-4216:
--

[~cziegeler]: {quote} the "cache" contains only a fraction of the paths and 
therefore a fallback to the repository (with a search?) sounds expensive and 
might happen a lot{quote}

FWIW, That's what we are seeing in one case, with a bloom filter size of 1000 
and a large repo with 25K vanity paths. The queries done on bloom filter misses 
take 1 to 2 seconds each and run on almost every or at least many requests, and 
their result seems to be never cached.

It seems weird to me to have a cache for something that can be dynamic and 
where you naturally want a LRU type caching, but the cache (the bloom filter) 
is only generated on restarts.

> Limit the number of vanityPath MapEntry 
> 
>
> Key: SLING-4216
> URL: https://issues.apache.org/jira/browse/SLING-4216
> Project: Sling
>  Issue Type: Improvement
>  Components: ResourceResolver
>Reporter: Antonio Sanso
>Assignee: Antonio Sanso
> Fix For: Resource Resolver 1.1.10
>
> Attachments: SLING-4216-patch.txt, SLING-4216-patch.txt, 
> SLING-4216-patch.txt
>
>
> At the moment there isn't any limit to the number of MapEntry that are cached 
> in memory.
> If the number of vanityPaths/alias is extremely high this can cause OOM.
> It would be good to have a way to limit the amount of memory used by the 
> MapEntry cache.



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

[jira] [Commented] (SLING-4882) Shared session usage in Sling MapEntries causes contention

2015-07-15 Thread Antonio Sanso (JIRA) 

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

Antonio Sanso commented on SLING-4882:
--

bq. It seems unnecessary to do a vanity path search for a request that does not 
have a vanity path.

true. the reason is a false positive on the bloom filter. Increasing the bloom 
filter size (and this is configurable) would lower the false positive rate

> Shared session usage in Sling MapEntries causes contention
> --
>
> Key: SLING-4882
> URL: https://issues.apache.org/jira/browse/SLING-4882
> Project: Sling
>  Issue Type: Bug
>  Components: ResourceResolver
>Reporter: Antonio Sanso
>Assignee: Antonio Sanso
> Fix For: Resource Resolver 1.2.8
>
> Attachments: SLING-4882-patch.txt, SLING-4882-patchv2.txt
>
>
> {code:none}
> "pool-7-thread-103" prio=10 tid=0x7fede006c000 nid=0x6db8 waiting on 
> condition [0x7fecdbb7a000]
>java.lang.Thread.State: WAITING (parking)
>   at sun.misc.Unsafe.park(Native Method)
>   - parking to wait for  <0x0005063f5b00> (a 
> java.util.concurrent.locks.ReentrantLock$NonfairSync)
>   at java.util.concurrent.locks.LockSupport.park(LockSupport.java:186)
>   at 
> java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:834)
>   at 
> java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireQueued(AbstractQueuedSynchronizer.java:867)
>   at 
> java.util.concurrent.locks.AbstractQueuedSynchronizer.acquire(AbstractQueuedSynchronizer.java:1197)
>   at 
> java.util.concurrent.locks.ReentrantLock$NonfairSync.lock(ReentrantLock.java:214)
>   at java.util.concurrent.locks.ReentrantLock.lock(ReentrantLock.java:290)
>   at 
> org.apache.jackrabbit.oak.jcr.delegate.SessionDelegate$WarningLock.lock(SessionDelegate.java:744)
>   at 
> org.apache.jackrabbit.oak.jcr.delegate.SessionDelegate$WarningLock.lock(SessionDelegate.java:775)
>   at 
> org.apache.jackrabbit.oak.jcr.delegate.SessionDelegate.perform(SessionDelegate.java:271)
>   at 
> org.apache.jackrabbit.oak.jcr.session.SessionImpl.perform(SessionImpl.java:127)
>   at 
> org.apache.jackrabbit.oak.jcr.session.SessionImpl.refresh(SessionImpl.java:430)
>   at sun.reflect.GeneratedMethodAccessor46.invoke(Unknown Source)
>   at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>   at java.lang.reflect.Method.invoke(Method.java:606)
>   at 
> org.apache.sling.jcr.base.SessionProxyHandler$SessionProxyInvocationHandler.invoke(SessionProxyHandler.java:113)
>   at com.sun.proxy.$Proxy7.refresh(Unknown Source)
>   at 
> org.apache.sling.jcr.resource.internal.helper.jcr.JcrResourceProvider.refresh(JcrResourceProvider.java:545)
>   at 
> org.apache.sling.resourceresolver.impl.helper.ResourceResolverContext.refresh(ResourceResolverContext.java:192)
>   at 
> org.apache.sling.resourceresolver.impl.ResourceResolverImpl.refresh(ResourceResolverImpl.java:1186)
>   at 
> org.apache.sling.resourceresolver.impl.mapping.MapEntries.doAddAttributes(MapEntries.java:321)
>   at 
> org.apache.sling.resourceresolver.impl.mapping.MapEntries.handleEvent(MapEntries.java:776)
>   at 
> org.apache.felix.eventadmin.impl.handler.EventHandlerProxy.sendEvent(EventHandlerProxy.java:412)
>   at 
> org.apache.felix.eventadmin.impl.tasks.SyncDeliverTasks.execute(SyncDeliverTasks.java:118)
>   at 
> org.apache.felix.eventadmin.impl.handler.EventAdminImpl.sendEvent(EventAdminImpl.java:114)
>   at 
> org.apache.felix.eventadmin.impl.security.EventAdminSecurityDecorator.sendEvent(EventAdminSecurityDecorator.java:96)
>   at 
> org.apache.sling.jcr.resource.internal.OakResourceListener.sendOsgiEvent(OakResourceListener.java:243)
>   at 
> org.apache.sling.jcr.resource.internal.OakResourceListener.added(OakResourceListener.java:109)
>   at 
> org.apache.jackrabbit.oak.plugins.observation.NodeObserver$NodeEventHandler.leave(NodeObserver.java:209)
>   at 
> org.apache.jackrabbit.oak.plugins.observation.FilteredHandler.leave(FilteredHandler.java:51)
>   at 
> org.apache.jackrabbit.oak.plugins.observation.EventGenerator$Continuation.run(EventGenerator.java:182)
>   at 
> org.apache.jackrabbit.oak.plugins.observation.EventGenerator.generate(EventGenerator.java:124)
>   at 
> org.apache.jackrabbit.oak.plugins.observation.NodeObserver.contentChanged(NodeObserver.java:163)
>   at 
> org.apache.jackrabbit.oak.spi.commit.BackgroundObserver$1$1.call(BackgroundObserver.java:124)
>   at 
> org.apache.jackrabbit.oak.spi.commit.BackgroundObserver$1$1.call(BackgroundObserver.java:118)
>   at java.util.concurrent.FutureTask.run(FutureTask.j

[jira] [Commented] (SLING-4882) Shared session usage in Sling MapEntries causes contention

2015-07-15 Thread Antonio Sanso (JIRA) 

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

Antonio Sanso commented on SLING-4882:
--

bq. BTW, it's using an admin session, not a service user.

[~alexander.klimetschek] same as the original resolver. We still did not 
migrate this module to service user

> Shared session usage in Sling MapEntries causes contention
> --
>
> Key: SLING-4882
> URL: https://issues.apache.org/jira/browse/SLING-4882
> Project: Sling
>  Issue Type: Bug
>  Components: ResourceResolver
>Reporter: Antonio Sanso
>Assignee: Antonio Sanso
> Fix For: Resource Resolver 1.2.8
>
> Attachments: SLING-4882-patch.txt, SLING-4882-patchv2.txt
>
>
> {code:none}
> "pool-7-thread-103" prio=10 tid=0x7fede006c000 nid=0x6db8 waiting on 
> condition [0x7fecdbb7a000]
>java.lang.Thread.State: WAITING (parking)
>   at sun.misc.Unsafe.park(Native Method)
>   - parking to wait for  <0x0005063f5b00> (a 
> java.util.concurrent.locks.ReentrantLock$NonfairSync)
>   at java.util.concurrent.locks.LockSupport.park(LockSupport.java:186)
>   at 
> java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:834)
>   at 
> java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireQueued(AbstractQueuedSynchronizer.java:867)
>   at 
> java.util.concurrent.locks.AbstractQueuedSynchronizer.acquire(AbstractQueuedSynchronizer.java:1197)
>   at 
> java.util.concurrent.locks.ReentrantLock$NonfairSync.lock(ReentrantLock.java:214)
>   at java.util.concurrent.locks.ReentrantLock.lock(ReentrantLock.java:290)
>   at 
> org.apache.jackrabbit.oak.jcr.delegate.SessionDelegate$WarningLock.lock(SessionDelegate.java:744)
>   at 
> org.apache.jackrabbit.oak.jcr.delegate.SessionDelegate$WarningLock.lock(SessionDelegate.java:775)
>   at 
> org.apache.jackrabbit.oak.jcr.delegate.SessionDelegate.perform(SessionDelegate.java:271)
>   at 
> org.apache.jackrabbit.oak.jcr.session.SessionImpl.perform(SessionImpl.java:127)
>   at 
> org.apache.jackrabbit.oak.jcr.session.SessionImpl.refresh(SessionImpl.java:430)
>   at sun.reflect.GeneratedMethodAccessor46.invoke(Unknown Source)
>   at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>   at java.lang.reflect.Method.invoke(Method.java:606)
>   at 
> org.apache.sling.jcr.base.SessionProxyHandler$SessionProxyInvocationHandler.invoke(SessionProxyHandler.java:113)
>   at com.sun.proxy.$Proxy7.refresh(Unknown Source)
>   at 
> org.apache.sling.jcr.resource.internal.helper.jcr.JcrResourceProvider.refresh(JcrResourceProvider.java:545)
>   at 
> org.apache.sling.resourceresolver.impl.helper.ResourceResolverContext.refresh(ResourceResolverContext.java:192)
>   at 
> org.apache.sling.resourceresolver.impl.ResourceResolverImpl.refresh(ResourceResolverImpl.java:1186)
>   at 
> org.apache.sling.resourceresolver.impl.mapping.MapEntries.doAddAttributes(MapEntries.java:321)
>   at 
> org.apache.sling.resourceresolver.impl.mapping.MapEntries.handleEvent(MapEntries.java:776)
>   at 
> org.apache.felix.eventadmin.impl.handler.EventHandlerProxy.sendEvent(EventHandlerProxy.java:412)
>   at 
> org.apache.felix.eventadmin.impl.tasks.SyncDeliverTasks.execute(SyncDeliverTasks.java:118)
>   at 
> org.apache.felix.eventadmin.impl.handler.EventAdminImpl.sendEvent(EventAdminImpl.java:114)
>   at 
> org.apache.felix.eventadmin.impl.security.EventAdminSecurityDecorator.sendEvent(EventAdminSecurityDecorator.java:96)
>   at 
> org.apache.sling.jcr.resource.internal.OakResourceListener.sendOsgiEvent(OakResourceListener.java:243)
>   at 
> org.apache.sling.jcr.resource.internal.OakResourceListener.added(OakResourceListener.java:109)
>   at 
> org.apache.jackrabbit.oak.plugins.observation.NodeObserver$NodeEventHandler.leave(NodeObserver.java:209)
>   at 
> org.apache.jackrabbit.oak.plugins.observation.FilteredHandler.leave(FilteredHandler.java:51)
>   at 
> org.apache.jackrabbit.oak.plugins.observation.EventGenerator$Continuation.run(EventGenerator.java:182)
>   at 
> org.apache.jackrabbit.oak.plugins.observation.EventGenerator.generate(EventGenerator.java:124)
>   at 
> org.apache.jackrabbit.oak.plugins.observation.NodeObserver.contentChanged(NodeObserver.java:163)
>   at 
> org.apache.jackrabbit.oak.spi.commit.BackgroundObserver$1$1.call(BackgroundObserver.java:124)
>   at 
> org.apache.jackrabbit.oak.spi.commit.BackgroundObserver$1$1.call(BackgroundObserver.java:118)
>   at java.util.concurrent.FutureTask.run(FutureTask.java:262)
>   at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecu

[jira] [Comment Edited] (SLING-4882) Shared session usage in Sling MapEntries causes contention

2015-07-15 Thread Alexander Klimetschek (JIRA) 

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

Alexander Klimetschek edited comment on SLING-4882 at 7/15/15 6:09 PM:
---

For reference, here is another stacktrace originating in a custom filter doing 
an extra resolve(). We have seen multiple concurrent threads executing a vanity 
path search with the same trace.

It seems unnecessary to do a vanity path search for a request that does not 
have a vanity path. I agree that having separate sessions is better, but the 
actual problem is that you need to run queries during requests.

{noformat}
"192.168.193.1 [1436890270925] GET 
/libs/cq/gui/components/siteadmin/admin/actions/reorder/clientlibs/reorder.min.js
 HTTP/1.1": awaiting notification on [0x0005063f5b00]
at sun.misc.Unsafe.park(Native Method)
at java.util.concurrent.locks.LockSupport.park(LockSupport.java:186)
at 
java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:834)
at 
java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireQueued(AbstractQueuedSynchronizer.java:867)
at 
java.util.concurrent.locks.AbstractQueuedSynchronizer.acquire(AbstractQueuedSynchronizer.java:1197)
at 
java.util.concurrent.locks.ReentrantLock$NonfairSync.lock(ReentrantLock.java:214)
at java.util.concurrent.locks.ReentrantLock.lock(ReentrantLock.java:290)
at 
org.apache.jackrabbit.oak.jcr.delegate.SessionDelegate$WarningLock.lock(SessionDelegate.java:744)
at 
org.apache.jackrabbit.oak.jcr.delegate.SessionDelegate$SynchronizedIterator.hasNext(SessionDelegate.java:693)
at 
org.apache.jackrabbit.oak.jcr.query.PrefetchIterator.hasNext(PrefetchIterator.java:81)
at 
org.apache.jackrabbit.commons.iterator.RangeIteratorAdapter.hasNext(RangeIteratorAdapter.java:132)
at 
org.apache.jackrabbit.commons.iterator.RangeIteratorDecorator.hasNext(RangeIteratorDecorator.java:82)
at 
org.apache.sling.jcr.resource.internal.helper.jcr.JcrNodeResourceIterator.seek(JcrNodeResourceIterator.java:90)
at 
org.apache.sling.jcr.resource.internal.helper.jcr.JcrNodeResourceIterator.(JcrNodeResourceIterator.java:64)
at 
org.apache.sling.jcr.resource.internal.helper.jcr.JcrResourceProvider.findResources(JcrResourceProvider.java:265)
at 
org.apache.sling.resourceresolver.impl.tree.RootResourceProviderEntry$2.seek(RootResourceProviderEntry.java:148)
at 
org.apache.sling.resourceresolver.impl.tree.RootResourceProviderEntry$2.(RootResourceProviderEntry.java:134)
at 
org.apache.sling.resourceresolver.impl.tree.RootResourceProviderEntry.findResources(RootResourceProviderEntry.java:132)
at 
org.apache.sling.resourceresolver.impl.ResourceResolverImpl.findResources(ResourceResolverImpl.java:668)
at 
org.apache.sling.resourceresolver.impl.mapping.MapEntries.getVanityPaths(MapEntries.java:860)
at 
org.apache.sling.resourceresolver.impl.mapping.MapEntries.getMapEntryList(MapEntries.java:714)
at 
org.apache.sling.resourceresolver.impl.mapping.MapEntries.access$100(MapEntries.java:69)
at 
org.apache.sling.resourceresolver.impl.mapping.MapEntries$MapEntryIterator.seek(MapEntries.java:1456)
at 
org.apache.sling.resourceresolver.impl.mapping.MapEntries$MapEntryIterator.(MapEntries.java:1407)
at 
org.apache.sling.resourceresolver.impl.mapping.MapEntries.getResolveMapsIterator(MapEntries.java:694)
at 
org.apache.sling.resourceresolver.impl.ResourceResolverImpl.resolveInternal(ResourceResolverImpl.java:249)
at 
org.apache.sling.resourceresolver.impl.ResourceResolverImpl.resolve(ResourceResolverImpl.java:192)
at 
com.day.cq.wcm.core.impl.AuthoringUIModeServiceImpl.isEditor(AuthoringUIModeServiceImpl.java:385)
at 
com.day.cq.wcm.core.impl.AuthoringUIModeServiceImpl.doFilter(AuthoringUIModeServiceImpl.java:300)
at 
org.apache.sling.engine.impl.filter.AbstractSlingFilterChain.doFilter(AbstractSlingFilterChain.java:60)
{noformat}


was (Author: alexander.klimetschek):
For reference, here is another stacktrace originating in a custom filter doing 
an extra resolve(). We have seen multiple concurrent threads executing a vanity 
path search.

It seems unnecessary to do a vanity path search for a request that does not 
have a vanity path. I agree that having separate sessions is better, but the 
actual problem is that you need to run queries during requests.

{noformat}
"192.168.193.1 [1436890270925] GET 
/libs/cq/gui/components/siteadmin/admin/actions/reorder/clientlibs/reorder.min.js
 HTTP/1.1": awaiting notification on [0x0005063f5b00]
at sun.misc.Unsafe.park(Native Method)
at java.util.concurrent.locks.LockSupport.park(LockSupport.java:186)
at 
java.util.concurre

[jira] [Commented] (SLING-4882) Shared session usage in Sling MapEntries causes contention

2015-07-15 Thread Alexander Klimetschek (JIRA) 

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

Alexander Klimetschek commented on SLING-4882:
--

For reference, here is another stacktrace originating in a custom filter doing 
an extra resolve(). We have seen multiple concurrent threads executing a vanity 
path search.

It seems unnecessary to do a vanity path search for a request that does not 
have a vanity path. I agree that having separate sessions is better, but the 
actual problem is that you need to run queries during requests.

{noformat}
"192.168.193.1 [1436890270925] GET 
/libs/cq/gui/components/siteadmin/admin/actions/reorder/clientlibs/reorder.min.js
 HTTP/1.1": awaiting notification on [0x0005063f5b00]
at sun.misc.Unsafe.park(Native Method)
at java.util.concurrent.locks.LockSupport.park(LockSupport.java:186)
at 
java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:834)
at 
java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireQueued(AbstractQueuedSynchronizer.java:867)
at 
java.util.concurrent.locks.AbstractQueuedSynchronizer.acquire(AbstractQueuedSynchronizer.java:1197)
at 
java.util.concurrent.locks.ReentrantLock$NonfairSync.lock(ReentrantLock.java:214)
at java.util.concurrent.locks.ReentrantLock.lock(ReentrantLock.java:290)
at 
org.apache.jackrabbit.oak.jcr.delegate.SessionDelegate$WarningLock.lock(SessionDelegate.java:744)
at 
org.apache.jackrabbit.oak.jcr.delegate.SessionDelegate$SynchronizedIterator.hasNext(SessionDelegate.java:693)
at 
org.apache.jackrabbit.oak.jcr.query.PrefetchIterator.hasNext(PrefetchIterator.java:81)
at 
org.apache.jackrabbit.commons.iterator.RangeIteratorAdapter.hasNext(RangeIteratorAdapter.java:132)
at 
org.apache.jackrabbit.commons.iterator.RangeIteratorDecorator.hasNext(RangeIteratorDecorator.java:82)
at 
org.apache.sling.jcr.resource.internal.helper.jcr.JcrNodeResourceIterator.seek(JcrNodeResourceIterator.java:90)
at 
org.apache.sling.jcr.resource.internal.helper.jcr.JcrNodeResourceIterator.(JcrNodeResourceIterator.java:64)
at 
org.apache.sling.jcr.resource.internal.helper.jcr.JcrResourceProvider.findResources(JcrResourceProvider.java:265)
at 
org.apache.sling.resourceresolver.impl.tree.RootResourceProviderEntry$2.seek(RootResourceProviderEntry.java:148)
at 
org.apache.sling.resourceresolver.impl.tree.RootResourceProviderEntry$2.(RootResourceProviderEntry.java:134)
at 
org.apache.sling.resourceresolver.impl.tree.RootResourceProviderEntry.findResources(RootResourceProviderEntry.java:132)
at 
org.apache.sling.resourceresolver.impl.ResourceResolverImpl.findResources(ResourceResolverImpl.java:668)
at 
org.apache.sling.resourceresolver.impl.mapping.MapEntries.getVanityPaths(MapEntries.java:860)
at 
org.apache.sling.resourceresolver.impl.mapping.MapEntries.getMapEntryList(MapEntries.java:714)
at 
org.apache.sling.resourceresolver.impl.mapping.MapEntries.access$100(MapEntries.java:69)
at 
org.apache.sling.resourceresolver.impl.mapping.MapEntries$MapEntryIterator.seek(MapEntries.java:1456)
at 
org.apache.sling.resourceresolver.impl.mapping.MapEntries$MapEntryIterator.(MapEntries.java:1407)
at 
org.apache.sling.resourceresolver.impl.mapping.MapEntries.getResolveMapsIterator(MapEntries.java:694)
at 
org.apache.sling.resourceresolver.impl.ResourceResolverImpl.resolveInternal(ResourceResolverImpl.java:249)
at 
org.apache.sling.resourceresolver.impl.ResourceResolverImpl.resolve(ResourceResolverImpl.java:192)
at 
com.day.cq.wcm.core.impl.AuthoringUIModeServiceImpl.isEditor(AuthoringUIModeServiceImpl.java:385)
at 
com.day.cq.wcm.core.impl.AuthoringUIModeServiceImpl.doFilter(AuthoringUIModeServiceImpl.java:300)
at 
org.apache.sling.engine.impl.filter.AbstractSlingFilterChain.doFilter(AbstractSlingFilterChain.java:60)
{noformat}

> Shared session usage in Sling MapEntries causes contention
> --
>
> Key: SLING-4882
> URL: https://issues.apache.org/jira/browse/SLING-4882
> Project: Sling
>  Issue Type: Bug
>  Components: ResourceResolver
>Reporter: Antonio Sanso
>Assignee: Antonio Sanso
> Fix For: Resource Resolver 1.2.8
>
> Attachments: SLING-4882-patch.txt, SLING-4882-patchv2.txt
>
>
> {code:none}
> "pool-7-thread-103" prio=10 tid=0x7fede006c000 nid=0x6db8 waiting on 
> condition [0x7fecdbb7a000]
>java.lang.Thread.State: WAITING (parking)
>   at sun.misc.Unsafe.park(Native Method)
>   - parking to wait for  <0x0005063f5b00> (a 
> java.util.concurrent.locks.ReentrantLock$Nonfai

[jira] [Commented] (SLING-4882) Shared session usage in Sling MapEntries causes contention

2015-07-15 Thread Alexander Klimetschek (JIRA) 

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

Alexander Klimetschek commented on SLING-4882:
--

BTW, it's using an admin session, not a service user.

> Shared session usage in Sling MapEntries causes contention
> --
>
> Key: SLING-4882
> URL: https://issues.apache.org/jira/browse/SLING-4882
> Project: Sling
>  Issue Type: Bug
>  Components: ResourceResolver
>Reporter: Antonio Sanso
>Assignee: Antonio Sanso
> Fix For: Resource Resolver 1.2.8
>
> Attachments: SLING-4882-patch.txt, SLING-4882-patchv2.txt
>
>
> {code:none}
> "pool-7-thread-103" prio=10 tid=0x7fede006c000 nid=0x6db8 waiting on 
> condition [0x7fecdbb7a000]
>java.lang.Thread.State: WAITING (parking)
>   at sun.misc.Unsafe.park(Native Method)
>   - parking to wait for  <0x0005063f5b00> (a 
> java.util.concurrent.locks.ReentrantLock$NonfairSync)
>   at java.util.concurrent.locks.LockSupport.park(LockSupport.java:186)
>   at 
> java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:834)
>   at 
> java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireQueued(AbstractQueuedSynchronizer.java:867)
>   at 
> java.util.concurrent.locks.AbstractQueuedSynchronizer.acquire(AbstractQueuedSynchronizer.java:1197)
>   at 
> java.util.concurrent.locks.ReentrantLock$NonfairSync.lock(ReentrantLock.java:214)
>   at java.util.concurrent.locks.ReentrantLock.lock(ReentrantLock.java:290)
>   at 
> org.apache.jackrabbit.oak.jcr.delegate.SessionDelegate$WarningLock.lock(SessionDelegate.java:744)
>   at 
> org.apache.jackrabbit.oak.jcr.delegate.SessionDelegate$WarningLock.lock(SessionDelegate.java:775)
>   at 
> org.apache.jackrabbit.oak.jcr.delegate.SessionDelegate.perform(SessionDelegate.java:271)
>   at 
> org.apache.jackrabbit.oak.jcr.session.SessionImpl.perform(SessionImpl.java:127)
>   at 
> org.apache.jackrabbit.oak.jcr.session.SessionImpl.refresh(SessionImpl.java:430)
>   at sun.reflect.GeneratedMethodAccessor46.invoke(Unknown Source)
>   at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>   at java.lang.reflect.Method.invoke(Method.java:606)
>   at 
> org.apache.sling.jcr.base.SessionProxyHandler$SessionProxyInvocationHandler.invoke(SessionProxyHandler.java:113)
>   at com.sun.proxy.$Proxy7.refresh(Unknown Source)
>   at 
> org.apache.sling.jcr.resource.internal.helper.jcr.JcrResourceProvider.refresh(JcrResourceProvider.java:545)
>   at 
> org.apache.sling.resourceresolver.impl.helper.ResourceResolverContext.refresh(ResourceResolverContext.java:192)
>   at 
> org.apache.sling.resourceresolver.impl.ResourceResolverImpl.refresh(ResourceResolverImpl.java:1186)
>   at 
> org.apache.sling.resourceresolver.impl.mapping.MapEntries.doAddAttributes(MapEntries.java:321)
>   at 
> org.apache.sling.resourceresolver.impl.mapping.MapEntries.handleEvent(MapEntries.java:776)
>   at 
> org.apache.felix.eventadmin.impl.handler.EventHandlerProxy.sendEvent(EventHandlerProxy.java:412)
>   at 
> org.apache.felix.eventadmin.impl.tasks.SyncDeliverTasks.execute(SyncDeliverTasks.java:118)
>   at 
> org.apache.felix.eventadmin.impl.handler.EventAdminImpl.sendEvent(EventAdminImpl.java:114)
>   at 
> org.apache.felix.eventadmin.impl.security.EventAdminSecurityDecorator.sendEvent(EventAdminSecurityDecorator.java:96)
>   at 
> org.apache.sling.jcr.resource.internal.OakResourceListener.sendOsgiEvent(OakResourceListener.java:243)
>   at 
> org.apache.sling.jcr.resource.internal.OakResourceListener.added(OakResourceListener.java:109)
>   at 
> org.apache.jackrabbit.oak.plugins.observation.NodeObserver$NodeEventHandler.leave(NodeObserver.java:209)
>   at 
> org.apache.jackrabbit.oak.plugins.observation.FilteredHandler.leave(FilteredHandler.java:51)
>   at 
> org.apache.jackrabbit.oak.plugins.observation.EventGenerator$Continuation.run(EventGenerator.java:182)
>   at 
> org.apache.jackrabbit.oak.plugins.observation.EventGenerator.generate(EventGenerator.java:124)
>   at 
> org.apache.jackrabbit.oak.plugins.observation.NodeObserver.contentChanged(NodeObserver.java:163)
>   at 
> org.apache.jackrabbit.oak.spi.commit.BackgroundObserver$1$1.call(BackgroundObserver.java:124)
>   at 
> org.apache.jackrabbit.oak.spi.commit.BackgroundObserver$1$1.call(BackgroundObserver.java:118)
>   at java.util.concurrent.FutureTask.run(FutureTask.java:262)
>   at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
>   at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.

[jira] [Commented] (SLING-4860) Vanity Path cannot be used for MergedResource (or virtual resource)

2015-07-15 Thread Christanto (JIRA) 

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

Christanto commented on SLING-4860:
---

Any other solution to satisfy the requirement?

> Vanity Path cannot be used for MergedResource (or virtual resource)
> ---
>
> Key: SLING-4860
> URL: https://issues.apache.org/jira/browse/SLING-4860
> Project: Sling
>  Issue Type: Improvement
>  Components: Engine
>Reporter: Christanto
>
> Currently the vanity path config is specified at the target node:
> {code}
> + /libs/mypage
>   - jcr:mixinTypes = "sling:VanityPath"
>   - sling:vanityOrder = 100
>   - sling:vanityPath = "/index"
> {code}
> The page can be then accessed at {{/libs/mypage.html}} or {{/index.html}}.
> Since Resource Merger, the preferable path to access the content is actually 
> {{/mnt/overlay/mypage.html}}. However since the vanity path config can only 
> specified at the target node, we cannot do that.
> My suggestion is to expose one more optional property to {{sling:VanityPath}} 
> to specify the target so that the config can be specified anywhere.
> {code}
> + /libs/mypage
>   - jcr:mixinTypes = "sling:VanityPath"
>   - sling:vanityOrder = 100
>   - sling:vanityPath = "/index"
>   - sling:target = "/mnt/overlay/mypage"
> {code}



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

[jira] [Commented] (SLING-4860) Vanity Path cannot be used for MergedResource (or virtual resource)

2015-07-15 Thread Carsten Ziegeler (JIRA) 

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

Carsten Ziegeler commented on SLING-4860:
-

I think we decided against this because of security reasons as you could create 
vanity paths everywhere pointing to any location. cc [~asanso]

> Vanity Path cannot be used for MergedResource (or virtual resource)
> ---
>
> Key: SLING-4860
> URL: https://issues.apache.org/jira/browse/SLING-4860
> Project: Sling
>  Issue Type: Improvement
>  Components: Engine
>Reporter: Christanto
>
> Currently the vanity path config is specified at the target node:
> {code}
> + /libs/mypage
>   - jcr:mixinTypes = "sling:VanityPath"
>   - sling:vanityOrder = 100
>   - sling:vanityPath = "/index"
> {code}
> The page can be then accessed at {{/libs/mypage.html}} or {{/index.html}}.
> Since Resource Merger, the preferable path to access the content is actually 
> {{/mnt/overlay/mypage.html}}. However since the vanity path config can only 
> specified at the target node, we cannot do that.
> My suggestion is to expose one more optional property to {{sling:VanityPath}} 
> to specify the target so that the config can be specified anywhere.
> {code}
> + /libs/mypage
>   - jcr:mixinTypes = "sling:VanityPath"
>   - sling:vanityOrder = 100
>   - sling:vanityPath = "/index"
>   - sling:target = "/mnt/overlay/mypage"
> {code}



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

[VOTE] Release Apache Sling Event 3.7.4 and Apache Sling DEA 1.0.2

2015-07-15 Thread Carsten Ziegeler 
Hi,

We solved 1 issue in each module:
https://issues.apache.org/jira/browse/SLING-4758 (DEA 1.0.2)
https://issues.apache.org/jira/browse/SLING-4885 (Event 3.7.4)

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

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 1299 /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.
-- 
Carsten Ziegeler
Adobe Research Switzerland
cziege...@apache.org

[jira] [Created] (SLING-4887) Move to Servlet 3

2015-07-15 Thread Carsten Ziegeler (JIRA) 
Carsten Ziegeler created SLING-4887:
---

 Summary: Move to Servlet 3
 Key: SLING-4887
 URL: https://issues.apache.org/jira/browse/SLING-4887
 Project: Sling
  Issue Type: Task
  Components: Engine, Launchpad
Reporter: Carsten Ziegeler
 Fix For: Launchpad Base 2.6.4, Engine 2.4.4


As discussed in the mailing list we should move to servlet 3 as the base 
version; it's out for a very long time and supported by major app servers for 
some time as well



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

Re: [VOTE] Release Apache Sling Default GET Servlets 2.1.12

2015-07-15 Thread Carsten Ziegeler 
+1

-- 
Carsten Ziegeler
Adobe Research Switzerland
cziege...@apache.org

Re: [VOTE] Release Apache Sling JCR Resource Resolver 2.5.4

2015-07-15 Thread Carsten Ziegeler 
+1

-- 
Carsten Ziegeler
Adobe Research Switzerland
cziege...@apache.org

Re: [VOTE] Release Scripting API 2.1.8, Scripting Core 2.0.30, Scripting JavaScript 2.0.20, Scripting Sightly JS Use Provider 1.0.6

2015-07-15 Thread Carsten Ziegeler 
+1

-- 
Carsten Ziegeler
Adobe Research Switzerland
cziege...@apache.org

Re: [VOTE] Release Resource Merger 1.2.10

2015-07-15 Thread Carsten Ziegeler 
+1



-- 
Carsten Ziegeler
Adobe Research Switzerland
cziege...@apache.org

[jira] [Updated] (SLING-4886) Testing tools bundles installer fails if there are no bundles to install

2015-07-15 Thread Satya Deep Maheshwari (JIRA) 

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

Satya Deep Maheshwari updated SLING-4886:
-
Attachment: SLING-4886.patch

Attaching patch containing proposed fix.

> Testing tools bundles installer fails if there are no bundles to install
> 
>
> Key: SLING-4886
> URL: https://issues.apache.org/jira/browse/SLING-4886
> Project: Sling
>  Issue Type: Bug
>  Components: Testing
>Reporter: Satya Deep Maheshwari
>Priority: Minor
> Attachments: SLING-4886.patch
>
>
> Background:
> org.apache.sling.testing.tools.sling.BundlesInstaller.installBundles is 
> invoked by 
> org.apache.sling.testing.tools.sling.SlingTestBase.installAdditionalBundles 
> for installing any additional bundles which may be necessary while running a 
> test sling instance for some integration tests.
> Problem:
> The problem with BundlesInstaller.installBundles is that it fails if there 
> are no bundles to install and hence the integration tests fail. 
> Expectation:
> BundlesInstaller.installBundles should not fail if there are no bundles to 
> install. It should just be a no-op.
> Fix:
> The problem is with a log message in this method which assumes that the 
> bundles list will not be empty. Also the log text seems to incorrectly assume 
> that the list contains bundles' folder path while it actually contains the 
> bundle list.



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

[jira] [Resolved] (SLING-4885) creation of jobs via OSGI events stops working on Exceptions

2015-07-15 Thread Carsten Ziegeler (JIRA) 

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

Carsten Ziegeler resolved SLING-4885.
-
Resolution: Fixed

Moved the try/catch into the while loop

> creation of jobs via OSGI events stops working on Exceptions
> 
>
> Key: SLING-4885
> URL: https://issues.apache.org/jira/browse/SLING-4885
> Project: Sling
>  Issue Type: Bug
>  Components: Extensions
>Affects Versions: Event 3.5.4
> Environment: Oak 1.0.16, DocumentNodeStore
>Reporter: Jörg Hoh
>Assignee: Carsten Ziegeler
> Fix For: Event 3.7.4
>
>
> We have the case, that we create jobs based on OSGI events. At some point of 
> time it stops working and we have this exception:
> 15.07.2015 07:15:23.080 *ERROR* [Apache Sling Job Event Bridge] 
> org.apache.sling.event.impl.jobs.deprecated.EventAdminBridge Bridge thread 
> stopped with exception: 
> org.apache.jackrabbit.oak.plugins.document.DocumentStoreException:  
> at 
> com.google.common.cache.LocalCache$Segment.get(LocalCache.java:2199) 
> at com.google.common.cache.LocalCache.get(LocalCache.java:3932) 
> at 
> com.google.common.cache.LocalCache$LocalManualCache.get(LocalCache.java:4721) 
> at 
> org.apache.jackrabbit.oak.plugins.document.DocumentNodeStore.getChildren(DocumentNodeStore.java:812)
>  
> at 
> org.apache.jackrabbit.oak.plugins.document.DocumentNodeStore.getChildNodes(DocumentNodeStore.java:1008)
>  
> at 
> org.apache.jackrabbit.oak.plugins.document.DocumentNodeState.getChildNodeEntries(DocumentNodeState.java:481)
>  
> at 
> org.apache.jackrabbit.oak.plugins.document.DocumentNodeState.access$000(DocumentNodeState.java:64)
>  



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

[jira] [Created] (SLING-4886) Testing tools bundles installer fails if there are no bundles to install

2015-07-15 Thread Satya Deep Maheshwari (JIRA) 
Satya Deep Maheshwari created SLING-4886:


 Summary: Testing tools bundles installer fails if there are no 
bundles to install
 Key: SLING-4886
 URL: https://issues.apache.org/jira/browse/SLING-4886
 Project: Sling
  Issue Type: Bug
  Components: Testing
Reporter: Satya Deep Maheshwari
Priority: Minor


Background:
org.apache.sling.testing.tools.sling.BundlesInstaller.installBundles is invoked 
by org.apache.sling.testing.tools.sling.SlingTestBase.installAdditionalBundles 
for installing any additional bundles which may be necessary while running a 
test sling instance for some integration tests.

Problem:
The problem with BundlesInstaller.installBundles is that it fails if there are 
no bundles to install and hence the integration tests fail. 

Expectation:
BundlesInstaller.installBundles should not fail if there are no bundles to 
install. It should just be a no-op.

Fix:
The problem is with a log message in this method which assumes that the bundles 
list will not be empty. Also the log text seems to incorrectly assume that the 
list contains bundles' folder path while it actually contains the bundle list.



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

[jira] [Assigned] (SLING-4885) creation of jobs via OSGI events stops working on Exceptions

2015-07-15 Thread Carsten Ziegeler (JIRA) 

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

Carsten Ziegeler reassigned SLING-4885:
---

Assignee: Carsten Ziegeler

> creation of jobs via OSGI events stops working on Exceptions
> 
>
> Key: SLING-4885
> URL: https://issues.apache.org/jira/browse/SLING-4885
> Project: Sling
>  Issue Type: Bug
>  Components: Extensions
>Affects Versions: Event 3.5.4
> Environment: Oak 1.0.16, DocumentNodeStore
>Reporter: Jörg Hoh
>Assignee: Carsten Ziegeler
> Fix For: Event 3.7.4
>
>
> We have the case, that we create jobs based on OSGI events. At some point of 
> time it stops working and we have this exception:
> 15.07.2015 07:15:23.080 *ERROR* [Apache Sling Job Event Bridge] 
> org.apache.sling.event.impl.jobs.deprecated.EventAdminBridge Bridge thread 
> stopped with exception: 
> org.apache.jackrabbit.oak.plugins.document.DocumentStoreException:  
> at 
> com.google.common.cache.LocalCache$Segment.get(LocalCache.java:2199) 
> at com.google.common.cache.LocalCache.get(LocalCache.java:3932) 
> at 
> com.google.common.cache.LocalCache$LocalManualCache.get(LocalCache.java:4721) 
> at 
> org.apache.jackrabbit.oak.plugins.document.DocumentNodeStore.getChildren(DocumentNodeStore.java:812)
>  
> at 
> org.apache.jackrabbit.oak.plugins.document.DocumentNodeStore.getChildNodes(DocumentNodeStore.java:1008)
>  
> at 
> org.apache.jackrabbit.oak.plugins.document.DocumentNodeState.getChildNodeEntries(DocumentNodeState.java:481)
>  
> at 
> org.apache.jackrabbit.oak.plugins.document.DocumentNodeState.access$000(DocumentNodeState.java:64)
>  



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

[jira] [Updated] (SLING-4885) creation of jobs via OSGI events stops working on Exceptions

2015-07-15 Thread Carsten Ziegeler (JIRA) 

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

Carsten Ziegeler updated SLING-4885:

Fix Version/s: Event 3.7.4

> creation of jobs via OSGI events stops working on Exceptions
> 
>
> Key: SLING-4885
> URL: https://issues.apache.org/jira/browse/SLING-4885
> Project: Sling
>  Issue Type: Bug
>  Components: Extensions
>Affects Versions: Event 3.5.4
> Environment: Oak 1.0.16, DocumentNodeStore
>Reporter: Jörg Hoh
> Fix For: Event 3.7.4
>
>
> We have the case, that we create jobs based on OSGI events. At some point of 
> time it stops working and we have this exception:
> 15.07.2015 07:15:23.080 *ERROR* [Apache Sling Job Event Bridge] 
> org.apache.sling.event.impl.jobs.deprecated.EventAdminBridge Bridge thread 
> stopped with exception: 
> org.apache.jackrabbit.oak.plugins.document.DocumentStoreException:  
> at 
> com.google.common.cache.LocalCache$Segment.get(LocalCache.java:2199) 
> at com.google.common.cache.LocalCache.get(LocalCache.java:3932) 
> at 
> com.google.common.cache.LocalCache$LocalManualCache.get(LocalCache.java:4721) 
> at 
> org.apache.jackrabbit.oak.plugins.document.DocumentNodeStore.getChildren(DocumentNodeStore.java:812)
>  
> at 
> org.apache.jackrabbit.oak.plugins.document.DocumentNodeStore.getChildNodes(DocumentNodeStore.java:1008)
>  
> at 
> org.apache.jackrabbit.oak.plugins.document.DocumentNodeState.getChildNodeEntries(DocumentNodeState.java:481)
>  
> at 
> org.apache.jackrabbit.oak.plugins.document.DocumentNodeState.access$000(DocumentNodeState.java:64)
>  



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

[jira] [Created] (SLING-4885) creation of jobs via OSGI events stops working on Exceptions

2015-07-15 Thread JIRA 
Jörg Hoh created SLING-4885:
---

 Summary: creation of jobs via OSGI events stops working on 
Exceptions
 Key: SLING-4885
 URL: https://issues.apache.org/jira/browse/SLING-4885
 Project: Sling
  Issue Type: Bug
  Components: Extensions
Affects Versions: Event 3.5.4
 Environment: Oak 1.0.16, DocumentNodeStore
Reporter: Jörg Hoh


We have the case, that we create jobs based on OSGI events. At some point of 
time it stops working and we have this exception:

15.07.2015 07:15:23.080 *ERROR* [Apache Sling Job Event Bridge] 
org.apache.sling.event.impl.jobs.deprecated.EventAdminBridge Bridge thread 
stopped with exception: 
org.apache.jackrabbit.oak.plugins.document.DocumentStoreException:  
at com.google.common.cache.LocalCache$Segment.get(LocalCache.java:2199) 
at com.google.common.cache.LocalCache.get(LocalCache.java:3932) 
at 
com.google.common.cache.LocalCache$LocalManualCache.get(LocalCache.java:4721) 
at 
org.apache.jackrabbit.oak.plugins.document.DocumentNodeStore.getChildren(DocumentNodeStore.java:812)
 
at 
org.apache.jackrabbit.oak.plugins.document.DocumentNodeStore.getChildNodes(DocumentNodeStore.java:1008)
 
at 
org.apache.jackrabbit.oak.plugins.document.DocumentNodeState.getChildNodeEntries(DocumentNodeState.java:481)
 
at 
org.apache.jackrabbit.oak.plugins.document.DocumentNodeState.access$000(DocumentNodeState.java:64)
 





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

[VOTE] Release Resource Merger 1.2.10

2015-07-15 Thread Radu Cotescu 
Hi,

We solved 3 issues in this release:
*https://issues.apache.org/jira/browse/SLING/fixforversion/12329662
*

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

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 1298 /tmp/sling-staging

Please vote to approve this release:

  [ ] +1 Approve the release
  [ ]  0 Don't care
  [ ] -1 Don't release, because ...

This majority vote is open for at least 72 hours.

Cheers,
Radu

[jira] [Resolved] (SLING-4882) Shared session usage in Sling MapEntries causes contention

2015-07-15 Thread Antonio Sanso (JIRA) 

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

Antonio Sanso resolved SLING-4882.
--
   Resolution: Fixed
Fix Version/s: Resource Resolver 1.2.8

fixed in rev r1691149 

> Shared session usage in Sling MapEntries causes contention
> --
>
> Key: SLING-4882
> URL: https://issues.apache.org/jira/browse/SLING-4882
> Project: Sling
>  Issue Type: Bug
>  Components: ResourceResolver
>Reporter: Antonio Sanso
>Assignee: Antonio Sanso
> Fix For: Resource Resolver 1.2.8
>
> Attachments: SLING-4882-patch.txt, SLING-4882-patchv2.txt
>
>
> {code:none}
> "pool-7-thread-103" prio=10 tid=0x7fede006c000 nid=0x6db8 waiting on 
> condition [0x7fecdbb7a000]
>java.lang.Thread.State: WAITING (parking)
>   at sun.misc.Unsafe.park(Native Method)
>   - parking to wait for  <0x0005063f5b00> (a 
> java.util.concurrent.locks.ReentrantLock$NonfairSync)
>   at java.util.concurrent.locks.LockSupport.park(LockSupport.java:186)
>   at 
> java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:834)
>   at 
> java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireQueued(AbstractQueuedSynchronizer.java:867)
>   at 
> java.util.concurrent.locks.AbstractQueuedSynchronizer.acquire(AbstractQueuedSynchronizer.java:1197)
>   at 
> java.util.concurrent.locks.ReentrantLock$NonfairSync.lock(ReentrantLock.java:214)
>   at java.util.concurrent.locks.ReentrantLock.lock(ReentrantLock.java:290)
>   at 
> org.apache.jackrabbit.oak.jcr.delegate.SessionDelegate$WarningLock.lock(SessionDelegate.java:744)
>   at 
> org.apache.jackrabbit.oak.jcr.delegate.SessionDelegate$WarningLock.lock(SessionDelegate.java:775)
>   at 
> org.apache.jackrabbit.oak.jcr.delegate.SessionDelegate.perform(SessionDelegate.java:271)
>   at 
> org.apache.jackrabbit.oak.jcr.session.SessionImpl.perform(SessionImpl.java:127)
>   at 
> org.apache.jackrabbit.oak.jcr.session.SessionImpl.refresh(SessionImpl.java:430)
>   at sun.reflect.GeneratedMethodAccessor46.invoke(Unknown Source)
>   at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>   at java.lang.reflect.Method.invoke(Method.java:606)
>   at 
> org.apache.sling.jcr.base.SessionProxyHandler$SessionProxyInvocationHandler.invoke(SessionProxyHandler.java:113)
>   at com.sun.proxy.$Proxy7.refresh(Unknown Source)
>   at 
> org.apache.sling.jcr.resource.internal.helper.jcr.JcrResourceProvider.refresh(JcrResourceProvider.java:545)
>   at 
> org.apache.sling.resourceresolver.impl.helper.ResourceResolverContext.refresh(ResourceResolverContext.java:192)
>   at 
> org.apache.sling.resourceresolver.impl.ResourceResolverImpl.refresh(ResourceResolverImpl.java:1186)
>   at 
> org.apache.sling.resourceresolver.impl.mapping.MapEntries.doAddAttributes(MapEntries.java:321)
>   at 
> org.apache.sling.resourceresolver.impl.mapping.MapEntries.handleEvent(MapEntries.java:776)
>   at 
> org.apache.felix.eventadmin.impl.handler.EventHandlerProxy.sendEvent(EventHandlerProxy.java:412)
>   at 
> org.apache.felix.eventadmin.impl.tasks.SyncDeliverTasks.execute(SyncDeliverTasks.java:118)
>   at 
> org.apache.felix.eventadmin.impl.handler.EventAdminImpl.sendEvent(EventAdminImpl.java:114)
>   at 
> org.apache.felix.eventadmin.impl.security.EventAdminSecurityDecorator.sendEvent(EventAdminSecurityDecorator.java:96)
>   at 
> org.apache.sling.jcr.resource.internal.OakResourceListener.sendOsgiEvent(OakResourceListener.java:243)
>   at 
> org.apache.sling.jcr.resource.internal.OakResourceListener.added(OakResourceListener.java:109)
>   at 
> org.apache.jackrabbit.oak.plugins.observation.NodeObserver$NodeEventHandler.leave(NodeObserver.java:209)
>   at 
> org.apache.jackrabbit.oak.plugins.observation.FilteredHandler.leave(FilteredHandler.java:51)
>   at 
> org.apache.jackrabbit.oak.plugins.observation.EventGenerator$Continuation.run(EventGenerator.java:182)
>   at 
> org.apache.jackrabbit.oak.plugins.observation.EventGenerator.generate(EventGenerator.java:124)
>   at 
> org.apache.jackrabbit.oak.plugins.observation.NodeObserver.contentChanged(NodeObserver.java:163)
>   at 
> org.apache.jackrabbit.oak.spi.commit.BackgroundObserver$1$1.call(BackgroundObserver.java:124)
>   at 
> org.apache.jackrabbit.oak.spi.commit.BackgroundObserver$1$1.call(BackgroundObserver.java:118)
>   at java.util.concurrent.FutureTask.run(FutureTask.java:262)
>   at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
>   at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
>   at java.lang.Thr

[jira] [Resolved] (SLING-4878) Resource Merger: Infinite loop in case a parent resource has one of its children as a supertype

2015-07-15 Thread Radu Cotescu (JIRA) 

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

Radu Cotescu resolved SLING-4878.
-
Resolution: Fixed

Fixed in [r1691143|https://svn.apache.org/r1691143].

> Resource Merger: Infinite loop in case a parent resource has one of its 
> children as a supertype
> ---
>
> Key: SLING-4878
> URL: https://issues.apache.org/jira/browse/SLING-4878
> Project: Sling
>  Issue Type: Bug
>  Components: Extensions
>Affects Versions: Resource Merger 1.2.8
>Reporter: Vlad Bailescu
>Assignee: Radu Cotescu
> Fix For: Resource Merger 1.2.10
>
> Attachments: sling-4878-infinite-loop-in-resourcemerger.patch
>
>
> Assuming a hierarchy as:
> {code}
> /x (supertype = x/y)
> /x/y
> {code}
> Then the OverridingResourcePicker#pickResources() method will enter an 
> infinite loop.



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

[jira] [Assigned] (SLING-4878) Resource Merger: Infinite loop in case a parent resource has one of its children as a supertype

2015-07-15 Thread Radu Cotescu (JIRA) 

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

Radu Cotescu reassigned SLING-4878:
---

Assignee: Radu Cotescu

> Resource Merger: Infinite loop in case a parent resource has one of its 
> children as a supertype
> ---
>
> Key: SLING-4878
> URL: https://issues.apache.org/jira/browse/SLING-4878
> Project: Sling
>  Issue Type: Bug
>  Components: Extensions
>Affects Versions: Resource Merger 1.2.8
>Reporter: Vlad Bailescu
>Assignee: Radu Cotescu
> Fix For: Resource Merger 1.2.10
>
> Attachments: sling-4878-infinite-loop-in-resourcemerger.patch
>
>
> Assuming a hierarchy as:
> {code}
> /x (supertype = x/y)
> /x/y
> {code}
> Then the OverridingResourcePicker#pickResources() method will enter an 
> infinite loop.



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

[jira] [Created] (SLING-4884) remove embedded CaptureResponseWrapper

2015-07-15 Thread Oliver Lietz (JIRA) 
Oliver Lietz created SLING-4884:
---

 Summary: remove embedded CaptureResponseWrapper
 Key: SLING-4884
 URL: https://issues.apache.org/jira/browse/SLING-4884
 Project: Sling
  Issue Type: Task
  Components: Scripting
Affects Versions: Scripting Thymeleaf 0.0.6
Reporter: Oliver Lietz
Assignee: Oliver Lietz
Priority: Minor
 Fix For: Scripting Thymeleaf 0.0.8


use {{org.apache.sling.scripting.core.servlet.CaptureResponseWrapper}} from 
{{org.apache.sling.scripting.core}} (version {{2.0.30}})



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