Re: Oak query performance problem

[Thomas Mueller]

Hi,

There is the "nodetype" index (/oak:index/nodetype) which is normally used
for such queries. I would change that index.

Regards,
Thomas


On 18/10/16 17:08, "Roy Teeuwen"  wrote:

>Hey Thomas,
>
>Ok perfect, laying an oak:QueryIndexDefinition on propertyNames
>jcr:primaryType and declaringNodeTypes rep:ACL solved the issue.
>I presumed there already was an index for all the existing
>jcr:primaryTypes :), not that you have to specifically have them in the
>declaringNodeTypes
>
>Thanks!
>Roy
>> On 18 Oct 2016, at 16:53, Thomas Mueller  wrote:
>> 
>> Hi,
>> 
>>> I really don¹t see the reason why this could be such a hard query
>> 
>> 
>> Who said it's a hard query? :-)
>> 
>> Is the problem performance, or is the problem that you get an exception?
>> 
>> 
>> If the problem is performance, then you need an index on the node type
>> rep:ACL.
>> 
>> If the problem is the exception: In your case the query engine is
>> configured to fail the queries (the reason is written in the exception
>> message). You can change the limit using the JMX bean
>> "QueryEngineSettings". The default is Long.MAX_VALUE (virtually no
>>limit)
>> by the way.
>> 
>> Regards,
>> Thomas
>> 
>> 
>> 
>> On 18/10/16 16:44, "Roy Teeuwen"  wrote:
>> 
>>> Hello all,
>>> 
>>> I got a problem in oak concerning query performance for the following
>>> simple queries
>>> 
>>> SELECT * FROM [rep:ACL] WHERE ISDESCENDANTNODE([/content])
>>> SELECT * FROM [rep:ACL] WHERE ISDESCENDANTNODE([/var])
>>> 
>>> I get the following exception:
>>> 
>>> java.lang.UnsupportedOperationException: The query read or traversed
>>>more
>>> than 15 nodes. To avoid affecting other tasks, processing was
>>>stopped.
>>> at 
>>> 
>>>org.apache.jackrabbit.oak.query.FilterIterators.checkReadLimit(FilterIte
>>>ra
>>> tors.java:66)
>>> at 
>>> 
>>>org.apache.jackrabbit.oak.spi.query.Cursors$TraversingCursor.fetchNext(C
>>>ur
>>> sors.java:324)
>>> at 
>>> 
>>>org.apache.jackrabbit.oak.spi.query.Cursors$TraversingCursor.next(Cursor
>>>s.
>>> java:303)
>>> at 
>>> 
>>>org.apache.jackrabbit.oak.query.ast.SelectorImpl.next(SelectorImpl.java:
>>>40
>>> 9)
>>> at 
>>> 
>>>org.apache.jackrabbit.oak.query.QueryImpl$RowIterator.fetchNext(QueryImp
>>>l.
>>> java:773)
>>> at 
>>> 
>>>org.apache.jackrabbit.oak.query.QueryImpl$RowIterator.hasNext(QueryImpl.
>>>ja
>>> va:798)
>>> at 
>>> 
>>>org.apache.jackrabbit.oak.jcr.query.QueryResultImpl$3.fetch(QueryResultI
>>>mp
>>> l.java:181)
>>> at 
>>> 
>>>org.apache.jackrabbit.oak.jcr.query.QueryResultImpl$3.next(QueryResultIm
>>>pl
>>> .java:207)
>>> at 
>>> 
>>>org.apache.jackrabbit.oak.jcr.query.QueryResultImpl$3.next(QueryResultIm
>>>pl
>>> .java:170)
>>> at 
>>> 
>>>org.apache.jackrabbit.oak.jcr.delegate.SessionDelegate$SynchronizedItera
>>>to
>>> r.next(SessionDelegate.java:694)
>>> at 
>>> 
>>>org.apache.jackrabbit.oak.jcr.query.PrefetchIterator.next(PrefetchIterat
>>>or
>>> .java:97)
>>> at 
>>> 
>>>org.apache.jackrabbit.commons.iterator.RangeIteratorAdapter.next(RangeIt
>>>er
>>> atorAdapter.java:152)
>>> at 
>>> 
>>>org.apache.jackrabbit.commons.iterator.RangeIteratorDecorator.next(Range
>>>It
>>> eratorDecorator.java:92)
>>> at 
>>> 
>>>org.apache.jackrabbit.commons.iterator.NodeIteratorAdapter.nextNode(Node
>>>It
>>> eratorAdapter.java:80)
>>> at 
>>> 
>>>biz.netcentric.cq.tools.actool.helper.QueryHelper.getNodes(QueryHelper.j
>>>av
>>> a:128)
>>> at 
>>> 
>>>biz.netcentric.cq.tools.actool.helper.QueryHelper.getRepPolicyNodes(Quer
>>>yH
>>> elper.java:90)
>>> at 
>>> 
>>>biz.netcentric.cq.tools.actool.dumpservice.impl.DumpserviceImpl.getACLDu
>>>mp
>>> Beans(DumpserviceImpl.java:399)
>>> 
>>> Of course there is an oak:index on jcr:primaryType, so I really don¹t
>>>see
>>> the reason why this could be such a hard query to search for nodes
>>>under
>>> a path that are of type rep:ACL?
>>> (If you want more background, this query is used in the netcentric AC
>>> Tool to make a dump of all the existing rep policy ACL nodes)
>>> 
>>> Greetings,
>>> Roy
>>> 
>>> 
>> 
>

Re: Oak query performance problem

[Roy Teeuwen]

Hey Thomas,

Ok perfect, laying an oak:QueryIndexDefinition on propertyNames jcr:primaryType 
and declaringNodeTypes rep:ACL solved the issue. 
I presumed there already was an index for all the existing jcr:primaryTypes :), 
not that you have to specifically have them in the declaringNodeTypes

Thanks!
Roy
> On 18 Oct 2016, at 16:53, Thomas Mueller  wrote:
> 
> Hi,
> 
>> I really don¹t see the reason why this could be such a hard query
> 
> 
> Who said it's a hard query? :-)
> 
> Is the problem performance, or is the problem that you get an exception?
> 
> 
> If the problem is performance, then you need an index on the node type
> rep:ACL.
> 
> If the problem is the exception: In your case the query engine is
> configured to fail the queries (the reason is written in the exception
> message). You can change the limit using the JMX bean
> "QueryEngineSettings". The default is Long.MAX_VALUE (virtually no limit)
> by the way.
> 
> Regards,
> Thomas
> 
> 
> 
> On 18/10/16 16:44, "Roy Teeuwen"  wrote:
> 
>> Hello all,
>> 
>> I got a problem in oak concerning query performance for the following
>> simple queries
>> 
>> SELECT * FROM [rep:ACL] WHERE ISDESCENDANTNODE([/content])
>> SELECT * FROM [rep:ACL] WHERE ISDESCENDANTNODE([/var])
>> 
>> I get the following exception:
>> 
>> java.lang.UnsupportedOperationException: The query read or traversed more
>> than 15 nodes. To avoid affecting other tasks, processing was stopped.
>>  at 
>> org.apache.jackrabbit.oak.query.FilterIterators.checkReadLimit(FilterItera
>> tors.java:66)
>>  at 
>> org.apache.jackrabbit.oak.spi.query.Cursors$TraversingCursor.fetchNext(Cur
>> sors.java:324)
>>  at 
>> org.apache.jackrabbit.oak.spi.query.Cursors$TraversingCursor.next(Cursors.
>> java:303)
>>  at 
>> org.apache.jackrabbit.oak.query.ast.SelectorImpl.next(SelectorImpl.java:40
>> 9)
>>  at 
>> org.apache.jackrabbit.oak.query.QueryImpl$RowIterator.fetchNext(QueryImpl.
>> java:773)
>>  at 
>> org.apache.jackrabbit.oak.query.QueryImpl$RowIterator.hasNext(QueryImpl.ja
>> va:798)
>>  at 
>> org.apache.jackrabbit.oak.jcr.query.QueryResultImpl$3.fetch(QueryResultImp
>> l.java:181)
>>  at 
>> org.apache.jackrabbit.oak.jcr.query.QueryResultImpl$3.next(QueryResultImpl
>> .java:207)
>>  at 
>> org.apache.jackrabbit.oak.jcr.query.QueryResultImpl$3.next(QueryResultImpl
>> .java:170)
>>  at 
>> org.apache.jackrabbit.oak.jcr.delegate.SessionDelegate$SynchronizedIterato
>> r.next(SessionDelegate.java:694)
>>  at 
>> org.apache.jackrabbit.oak.jcr.query.PrefetchIterator.next(PrefetchIterator
>> .java:97)
>>  at 
>> org.apache.jackrabbit.commons.iterator.RangeIteratorAdapter.next(RangeIter
>> atorAdapter.java:152)
>>  at 
>> org.apache.jackrabbit.commons.iterator.RangeIteratorDecorator.next(RangeIt
>> eratorDecorator.java:92)
>>  at 
>> org.apache.jackrabbit.commons.iterator.NodeIteratorAdapter.nextNode(NodeIt
>> eratorAdapter.java:80)
>>  at 
>> biz.netcentric.cq.tools.actool.helper.QueryHelper.getNodes(QueryHelper.jav
>> a:128)
>>  at 
>> biz.netcentric.cq.tools.actool.helper.QueryHelper.getRepPolicyNodes(QueryH
>> elper.java:90)
>>  at 
>> biz.netcentric.cq.tools.actool.dumpservice.impl.DumpserviceImpl.getACLDump
>> Beans(DumpserviceImpl.java:399)
>> 
>> Of course there is an oak:index on jcr:primaryType, so I really don¹t see
>> the reason why this could be such a hard query to search for nodes under
>> a path that are of type rep:ACL?
>> (If you want more background, this query is used in the netcentric AC
>> Tool to make a dump of all the existing rep policy ACL nodes)
>> 
>> Greetings,
>> Roy
>> 
>> 
> 

Re: Oak query performance problem

[Thomas Mueller]

Hi,

> I really don¹t see the reason why this could be such a hard query


Who said it's a hard query? :-)

Is the problem performance, or is the problem that you get an exception?


If the problem is performance, then you need an index on the node type
rep:ACL.

If the problem is the exception: In your case the query engine is
configured to fail the queries (the reason is written in the exception
message). You can change the limit using the JMX bean
"QueryEngineSettings". The default is Long.MAX_VALUE (virtually no limit)
by the way.

Regards,
Thomas



On 18/10/16 16:44, "Roy Teeuwen"  wrote:

>Hello all,
>
>I got a problem in oak concerning query performance for the following
>simple queries
>
>SELECT * FROM [rep:ACL] WHERE ISDESCENDANTNODE([/content])
>SELECT * FROM [rep:ACL] WHERE ISDESCENDANTNODE([/var])
>
>I get the following exception:
>
>java.lang.UnsupportedOperationException: The query read or traversed more
>than 15 nodes. To avoid affecting other tasks, processing was stopped.
>   at 
>org.apache.jackrabbit.oak.query.FilterIterators.checkReadLimit(FilterItera
>tors.java:66)
>   at 
>org.apache.jackrabbit.oak.spi.query.Cursors$TraversingCursor.fetchNext(Cur
>sors.java:324)
>   at 
>org.apache.jackrabbit.oak.spi.query.Cursors$TraversingCursor.next(Cursors.
>java:303)
>   at 
>org.apache.jackrabbit.oak.query.ast.SelectorImpl.next(SelectorImpl.java:40
>9)
>   at 
>org.apache.jackrabbit.oak.query.QueryImpl$RowIterator.fetchNext(QueryImpl.
>java:773)
>   at 
>org.apache.jackrabbit.oak.query.QueryImpl$RowIterator.hasNext(QueryImpl.ja
>va:798)
>   at 
>org.apache.jackrabbit.oak.jcr.query.QueryResultImpl$3.fetch(QueryResultImp
>l.java:181)
>   at 
>org.apache.jackrabbit.oak.jcr.query.QueryResultImpl$3.next(QueryResultImpl
>.java:207)
>   at 
>org.apache.jackrabbit.oak.jcr.query.QueryResultImpl$3.next(QueryResultImpl
>.java:170)
>   at 
>org.apache.jackrabbit.oak.jcr.delegate.SessionDelegate$SynchronizedIterato
>r.next(SessionDelegate.java:694)
>   at 
>org.apache.jackrabbit.oak.jcr.query.PrefetchIterator.next(PrefetchIterator
>.java:97)
>   at 
>org.apache.jackrabbit.commons.iterator.RangeIteratorAdapter.next(RangeIter
>atorAdapter.java:152)
>   at 
>org.apache.jackrabbit.commons.iterator.RangeIteratorDecorator.next(RangeIt
>eratorDecorator.java:92)
>   at 
>org.apache.jackrabbit.commons.iterator.NodeIteratorAdapter.nextNode(NodeIt
>eratorAdapter.java:80)
>   at 
>biz.netcentric.cq.tools.actool.helper.QueryHelper.getNodes(QueryHelper.jav
>a:128)
>   at 
>biz.netcentric.cq.tools.actool.helper.QueryHelper.getRepPolicyNodes(QueryH
>elper.java:90)
>   at 
>biz.netcentric.cq.tools.actool.dumpservice.impl.DumpserviceImpl.getACLDump
>Beans(DumpserviceImpl.java:399)
>
>Of course there is an oak:index on jcr:primaryType, so I really don¹t see
>the reason why this could be such a hard query to search for nodes under
>a path that are of type rep:ACL?
>(If you want more background, this query is used in the netcentric AC
>Tool to make a dump of all the existing rep policy ACL nodes)
>
>Greetings,
>Roy
>
>

Oak query performance problem

[Roy Teeuwen]

Hello all,

I got a problem in oak concerning query performance for the following simple 
queries

SELECT * FROM [rep:ACL] WHERE ISDESCENDANTNODE([/content]) 
SELECT * FROM [rep:ACL] WHERE ISDESCENDANTNODE([/var]) 

I get the following exception:

java.lang.UnsupportedOperationException: The query read or traversed more than 
15 nodes. To avoid affecting other tasks, processing was stopped.
at 
org.apache.jackrabbit.oak.query.FilterIterators.checkReadLimit(FilterIterators.java:66)
at 
org.apache.jackrabbit.oak.spi.query.Cursors$TraversingCursor.fetchNext(Cursors.java:324)
at 
org.apache.jackrabbit.oak.spi.query.Cursors$TraversingCursor.next(Cursors.java:303)
at 
org.apache.jackrabbit.oak.query.ast.SelectorImpl.next(SelectorImpl.java:409)
at 
org.apache.jackrabbit.oak.query.QueryImpl$RowIterator.fetchNext(QueryImpl.java:773)
at 
org.apache.jackrabbit.oak.query.QueryImpl$RowIterator.hasNext(QueryImpl.java:798)
at 
org.apache.jackrabbit.oak.jcr.query.QueryResultImpl$3.fetch(QueryResultImpl.java:181)
at 
org.apache.jackrabbit.oak.jcr.query.QueryResultImpl$3.next(QueryResultImpl.java:207)
at 
org.apache.jackrabbit.oak.jcr.query.QueryResultImpl$3.next(QueryResultImpl.java:170)
at 
org.apache.jackrabbit.oak.jcr.delegate.SessionDelegate$SynchronizedIterator.next(SessionDelegate.java:694)
at 
org.apache.jackrabbit.oak.jcr.query.PrefetchIterator.next(PrefetchIterator.java:97)
at 
org.apache.jackrabbit.commons.iterator.RangeIteratorAdapter.next(RangeIteratorAdapter.java:152)
at 
org.apache.jackrabbit.commons.iterator.RangeIteratorDecorator.next(RangeIteratorDecorator.java:92)
at 
org.apache.jackrabbit.commons.iterator.NodeIteratorAdapter.nextNode(NodeIteratorAdapter.java:80)
at 
biz.netcentric.cq.tools.actool.helper.QueryHelper.getNodes(QueryHelper.java:128)
at 
biz.netcentric.cq.tools.actool.helper.QueryHelper.getRepPolicyNodes(QueryHelper.java:90)
at 
biz.netcentric.cq.tools.actool.dumpservice.impl.DumpserviceImpl.getACLDumpBeans(DumpserviceImpl.java:399)

Of course there is an oak:index on jcr:primaryType, so I really don’t see the 
reason why this could be such a hard query to search for nodes under a path 
that are of type rep:ACL?
(If you want more background, this query is used in the netcentric AC Tool to 
make a dump of all the existing rep policy ACL nodes)

Greetings,
Roy

[Oak origin/trunk] Apache Jackrabbit Oak matrix - Build # 1216 - Still Failing

[Apache Jenkins Server]

The Apache Jenkins build system has built Apache Jackrabbit Oak matrix (build 
#1216)

Status: Still Failing

Check console output at 
https://builds.apache.org/job/Apache%20Jackrabbit%20Oak%20matrix/1216/ to view 
the results.

Changes:
No changes
 

Test results:
18 tests failed.
FAILED:  
org.apache.jackrabbit.oak.remote.http.handler.RemoteServerIT.testReadLastRevisionTreeReferenceProperty[SegmentTar]

Error Message:
Address already in use

Stack Trace:
java.net.BindException: Address already in use
at sun.nio.ch.Net.bind0(Native Method)
at sun.nio.ch.Net.bind(Net.java:433)
at sun.nio.ch.Net.bind(Net.java:425)
at 
sun.nio.ch.ServerSocketChannelImpl.bind(ServerSocketChannelImpl.java:223)
at sun.nio.ch.ServerSocketAdaptor.bind(ServerSocketAdaptor.java:74)
at 
org.eclipse.jetty.server.nio.SelectChannelConnector.open(SelectChannelConnector.java:187)
at 
org.eclipse.jetty.server.AbstractConnector.doStart(AbstractConnector.java:316)
at 
org.eclipse.jetty.server.nio.SelectChannelConnector.doStart(SelectChannelConnector.java:265)
at 
org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:64)
at org.eclipse.jetty.server.Server.doStart(Server.java:291)
at 
org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:64)
at 
org.apache.jackrabbit.oak.remote.http.handler.RemoteServer.start(RemoteServer.java:54)
at 
org.apache.jackrabbit.oak.remote.http.handler.RemoteServerIT.setUp(RemoteServerIT.java:139)


FAILED:  
org.apache.jackrabbit.oak.plugins.document.DocumentNodeStoreIT.modifiedResetWithDiff[MemoryFixture:
 Memory]

Error Message:
org/apache/jackrabbit/oak/plugins/document/DocumentNodeStoreIT$1

Stack Trace:
java.lang.NoClassDefFoundError: 
org/apache/jackrabbit/oak/plugins/document/DocumentNodeStoreIT$1
at 
org.apache.jackrabbit.oak.plugins.document.DocumentNodeStoreIT.modifiedResetWithDiff(DocumentNodeStoreIT.java:58)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
at 
org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
at 
org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
at 
org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
at 
org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
at 
org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
at 
org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
at org.junit.runners.Suite.runChild(Suite.java:128)
at org.junit.runners.Suite.runChild(Suite.java:27)
at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
at 
org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:252)
at 
org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:141)
at 
org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:112)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
org.apache.maven.surefire.util.ReflectionUtils.invokeMethodWithArray(ReflectionUtils.java:189)
at 
org.apache.maven.surefire.booter.ProviderFactory$ProviderProxy.invoke(ProviderFactory.java:165)
at 
org.apache.maven.surefire.booter.ProviderFactory.invokeProvider(ProviderFactory.java:85)
at 
org.

[Oak origin/trunk] Apache Jackrabbit Oak matrix - Build # 1215 - Failure

[Apache Jenkins Server]

The Apache Jenkins build system has built Apache Jackrabbit Oak matrix (build 
#1215)

Status: Failure

Check console output at 
https://builds.apache.org/job/Apache%20Jackrabbit%20Oak%20matrix/1215/ to view 
the results.

Changes:
No changes
 

Test results:
2 tests failed.
FAILED:  
org.apache.jackrabbit.oak.plugins.observation.CommitRateLimiterTest.blockCommits

Error Message:
Unexpected exception, 
expected but 
was

Stack Trace:
java.lang.Exception: Unexpected exception, 
expected but 
was
at 
org.junit.internal.runners.statements.ExpectException.evaluate(ExpectException.java:28)
at 
org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
at 
org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
at 
org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
at 
org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:252)
at 
org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:141)
at 
org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:112)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
org.apache.maven.surefire.util.ReflectionUtils.invokeMethodWithArray(ReflectionUtils.java:189)
at 
org.apache.maven.surefire.booter.ProviderFactory$ProviderProxy.invoke(ProviderFactory.java:165)
at 
org.apache.maven.surefire.booter.ProviderFactory.invokeProvider(ProviderFactory.java:85)
at 
org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:115)
at 
org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:75)
Caused by: java.lang.InterruptedException
at java.lang.Object.wait(Native Method)
at java.lang.Thread.join(Thread.java:1249)
at java.lang.Thread.join(Thread.java:1323)
at 
org.apache.jackrabbit.oak.plugins.observation.CommitRateLimiterTest.blockCommits(CommitRateLimiterTest.java:99)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
at 
org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
at 
org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
at 
org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
at 
org.junit.internal.runners.statements.ExpectException.evaluate(ExpectException.java:19)
... 22 more


FAILED:  
org.apache.jackrabbit.oak.plugins.observation.CommitRateLimiterTest.blockCommits

Error Message:
Unexpected exception, 
expected but 
was

Stack Trace:
java.lang.Exception: Unexpected exception, 
expected but 
was
at 
org.junit.internal.runners.statements.ExpectException.evaluate(ExpectException.java:28)
at 
org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
at 
org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
at 
org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
at 
org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:252)
at 
org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:141)
at 
org.apache.maven.surefire.junit4.JUnit

Re: [Fwd: New Windows Slaves Online - Old slaves will ge going Offline]

[Michael Dürig]

Thanks for forwarding. We've been to one of those slaved before but the 
build didn't get far. I switched to the generic Windows label as 
recommended for now. Let's see how this turns out.


Michael

On 18.10.16 9:22 , Robert Munteanu wrote:

Hi,

This might be of interest to you in the context of getting Oak CI
builds setup on Windows.

Robert

 Forwarded Message 
From: Gavin McDonald 
Reply-to: bui...@apache.org
To: bui...@apache.org
Subject: New Windows Slaves Online - Old slaves will ge going Offline
Date: Tue, 18 Oct 2016 16:44:34 +1100


HI All,

As some of you know, we have been working on replacements for
Windows1(hudson-win.apache.org )  and
Windows2 (je-win2012.apache.org )
Jenkins slaves.

We are pleased to announce that windows-2012-1 and windows-2012-2 are
online and operational.
Please do start using these now.

The new nodes are direct replacements for windows1 and windows2 nodes
which as of this notice are now
deprecated and will be turned off at the end of this month - 31st
October 2016.

Please move your jobs to the Generic ‘Windows’ label if you have not
already done so, or tie your jobs to the
new slaves if you wish to start testing on those before the cut off
date.

Any jobs still tied to the deprecated slaves by the cut-off date will
be moved to the Windows generic label by
Infra.

Thanks!


Gav… (ASF Infra Team)

[Fwd: New Windows Slaves Online - Old slaves will ge going Offline]

[Robert Munteanu]

Hi,

This might be of interest to you in the context of getting Oak CI
builds setup on Windows.

Robert

 Forwarded Message 
From: Gavin McDonald 
Reply-to: bui...@apache.org
To: bui...@apache.org
Subject: New Windows Slaves Online - Old slaves will ge going Offline
Date: Tue, 18 Oct 2016 16:44:34 +1100

> HI All,
> 
> As some of you know, we have been working on replacements for
> Windows1(hudson-win.apache.org )  and
> Windows2 (je-win2012.apache.org )
> Jenkins slaves. 
> 
> We are pleased to announce that windows-2012-1 and windows-2012-2 are
> online and operational. 
> Please do start using these now.
> 
> The new nodes are direct replacements for windows1 and windows2 nodes
> which as of this notice are now 
> deprecated and will be turned off at the end of this month - 31st
> October 2016.
> 
> Please move your jobs to the Generic ‘Windows’ label if you have not
> already done so, or tie your jobs to the 
> new slaves if you wish to start testing on those before the cut off
> date.
> 
> Any jobs still tied to the deprecated slaves by the cut-off date will
> be moved to the Windows generic label by 
> Infra.
> 
> Thanks!
> 
> 
> Gav… (ASF Infra Team)