date:20130708

[jira] [Created] (SLING-2946) IOOBE in TopicRoundRobinJobQueue

2013-07-08 Thread Timothee Maret (JIRA)

Timothee Maret created SLING-2946:
-

 Summary: IOOBE in TopicRoundRobinJobQueue
 Key: SLING-2946
 URL: https://issues.apache.org/jira/browse/SLING-2946
 Project: Sling
  Issue Type: Bug
  Components: Engine
Affects Versions: Extensions Event 3.1.4
Reporter: Timothee Maret


The TopicRoundRobinJobQueue throws IndexOutOfBoundsException which fill the 
logs.
The reason is that the 'topicIndex' is never decreased (or set to 0) when the 
'topics' array list can be decreased in two methods:

* clear
* removeAllJobs


--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (SLING-2945) ClusterLoadTest failures

2013-07-08 Thread Robert Munteanu (JIRA)


[ 
https://issues.apache.org/jira/browse/SLING-2945?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13701883#comment-13701883
 ] 

Robert Munteanu commented on SLING-2945:


[~egli] - I've taken a look at the tests and tried to implement them using the 
RetryLoop, for maximum flexibility. I'm not sure if the semantics are preserved 
( the RetryLoop waits for each instance on each iteration, instead of waiting 
for all instances once at the start of the iteration ).

The tests consistently pass for me, tested with a heavy CPU/IO process running 
on the same time, whereas they were failing before.

I also needed to add a try/catch to the dumpRepo calls, they failed probably 
due to concurrent session access ( will paste stack trace below ). Anyway, I'd 
appreciate if you could take a look at the patch and let me know if I can apply 
it as-is or if it needs rework.

javax.jcr.InvalidItemStateException: Item does not exist anymore: 
4b3d508e-5e4c-4385-a6d4-68f07d8dce89
at 
org.apache.jackrabbit.core.ItemImpl.itemSanityCheck(ItemImpl.java:116)
at org.apache.jackrabbit.core.ItemImpl.perform(ItemImpl.java:90)
at org.apache.jackrabbit.core.NodeImpl.getNodes(NodeImpl.java:2141)
at 
org.apache.sling.discovery.impl.setup.Instance.dump(Instance.java:393)
at 
org.apache.sling.discovery.impl.setup.Instance.dump(Instance.java:396)
at 
org.apache.sling.discovery.impl.setup.Instance.dump(Instance.java:396)
at 
org.apache.sling.discovery.impl.setup.Instance.dump(Instance.java:396)
at 
org.apache.sling.discovery.impl.setup.Instance.dump(Instance.java:396)
at 
org.apache.sling.discovery.impl.setup.Instance.dump(Instance.java:396)
at 
org.apache.sling.discovery.impl.setup.Instance.dump(Instance.java:396)
at 
org.apache.sling.discovery.impl.setup.Instance.dump(Instance.java:396)
at 
org.apache.sling.discovery.impl.setup.Instance.dump(Instance.java:396)
at 
org.apache.sling.discovery.impl.setup.Instance.dump(Instance.java:396)
at 
org.apache.sling.discovery.impl.setup.Instance.dumpRepo(Instance.java:355)
at 
org.apache.sling.discovery.impl.cluster.ClusterLoadTest.doTest(ClusterLoadTest.java:145)
at 
org.apache.sling.discovery.impl.cluster.ClusterLoadTest.testSevenInstances(ClusterLoadTest.java:102)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:592)
at 
org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:45)
at 
org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:15)
at 
org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:42)
at 
org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:20)
at 
org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:30)
at org.junit.rules.Verifier$1.evaluate(Verifier.java:33)
at org.junit.rules.RunRules.evaluate(RunRules.java:18)
at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:263)
at 
org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:68)
at 
org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:47)
at org.junit.runners.ParentRunner$3.run(ParentRunner.java:231)
at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:60)
at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:229)
at org.junit.runners.ParentRunner.access$000(ParentRunner.java:50)
at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:222)
at org.junit.runners.ParentRunner.run(ParentRunner.java:300)
at 
org.eclipse.jdt.internal.junit4.runner.JUnit4TestReference.run(JUnit4TestReference.java:50)
at 
org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38)
at 
org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:467)
at 
org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:683)
at 
org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:390)
at 
org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:197)



 ClusterLoadTest failures
 

 Key: SLING-2945
 URL: https://issues.apache.org/jira/browse/SLING-2945
 Project: Sling
  Issue Type: Bug
  Components: Extensions
Reporter: Robert Munteanu
Assignee: Stefan Egli

Re: SLING-2803 validation module, hierarchical structures and extensible types

2013-07-08 Thread Alexander Klimetschek

On 04.07.2013, at 07:54, Carsten Ziegeler cziege...@apache.org wrote:

 As I wrote, a hierarchy is only supported by a single implementation for
 reading - not for writing, so it doesn't make sense to me to support this
 in validation as this can't be written through the resource api in the same
 way. The post servlet is splitting paths and creates a resource for each
 part of the path except the last part which is the property on the last
 resource.

Validation is only about reading, so there is no problem if the 
ModifiableValueMap doesn't support relative paths, it would never be used by 
validation code.

IMO the relative paths in the JcrPropertyMap are a great feature (at least for 
reading). Relative paths are a good invention and shorten the code a lot.

Cheers,
Alex

Re: SLING-2803 validation module, hierarchical structures and extensible types

2013-07-08 Thread Alexander Klimetschek

On 04.07.2013, at 14:56, Carsten Ziegeler cziege...@apache.org wrote:

 Adding this - maybe as an optional service - into the resource resolver
 makes it also impossible to bypass validation - the validation is always
 done regardless whether the changes are done through the post servlet, any
 other servlet, or some server side code running in the background.

We should be careful with the imposed new processing overhead of this. There 
needs to be control over it, and IMO an active whitelisting for which 
validators (i.e. resource types) this would happen and when. And the simplest 
way to do that is to have custom application code call the validation service 
(one-liner) themselves and do it automatically only in the post servlet (but 
also with an option to enable/disable individual validators).

Cheers,
Alex

[jira] [Commented] (SLING-2945) ClusterLoadTest failures

2013-07-08 Thread Stefan Egli (JIRA)

[
https://issues.apache.org/jira/browse/SLING-2945?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13701899#comment-13701899
]

Stefan Egli commented on SLING-2945:

[~rombert], excellent. That patch looks good. I might add some more asserts to
the Condition there to check not only the count but if the correct instances
are visible. But I can apply that after patch.

Re the exception: jup, I should probably have done some more safety-checks
there - but the catch is fine for now.

ClusterLoadTest failures

Key: SLING-2945
URL: https://issues.apache.org/jira/browse/SLING-2945
Project: Sling
Issue Type: Bug
Components: Extensions
Reporter: Robert Munteanu
Assignee: Stefan Egli
Attachments: SLING-2945-retry-loop.patch

This test has failed recently on Jenkins at [1], with the message:
---
T E S T S
---
Running org.apache.sling.discovery.impl.cluster.ClusterLoadTest
Build timed out (after 150 minutes). Marking the build as failed.
Results :
Tests run: 0, Failures: 0, Errors: 0, Skipped: 0
To debug infra issues, I've also set up a Travis CI build at [2] . This test
also fails there, but the error message is clearer: Caused by:
javax.jcr.PathNotFoundException: /var/discovery/impl . The full build log is
at [3].
I also have errors when repeatedly running the test locally, so it's not just
CI flakiness.
[1] :
https://builds.apache.org/view/S-Z/view/Sling/job/sling-trunk-1.6/1715/console
[2]: http://travis-ci.org/rombert/sling/
[3]: https://s3.amazonaws.com/archive.travis-ci.org/jobs/8746894/log.txt

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

49 matches

Mail list logo