Re: The revenge of OAK-53 part II: IT failure
Hi Michi, And you're sure you built and installed the latest oak-mk package, and are not accidentally refering to an old one that doesn't contain the fix made in OAK-12, namely to BoundaryInputStream? Cheers Dominique On May 24, 2012, at 11:43 AM, Michael Dürig wrote: Hi Dominique, On 23.5.12 13:45, Dominique Pfister wrote: Hi Michi, On May 23, 2012, at 1:38 PM, Michael Dürig wrote: Didn't see it again up to now. I'll keep an eye on it. Is there any log data that would be helpful if this occurs again? Unfortunately not (yet), if it reappears, I'll add a logger to the mk subproject and log messages in the server. This just happens again. The output form the Maven build is --- T E S T S --- Running org.apache.jackrabbit.mk.test.EverythingIT java.io.IOException: Bad HTTP request line: 9?)c??:O?+?w ?c9???'td???aY??#0??ˀ??+??4¨?:?0?1 #`# at org.apache.jackrabbit.mk.server.Request.parse(Request.java:72) at org.apache.jackrabbit.mk.server.HttpProcessor.process(HttpProcessor.java:100) at org.apache.jackrabbit.mk.server.HttpProcessor.process(HttpProcessor.java:75) at org.apache.jackrabbit.mk.server.Server.process(Server.java:169) at org.apache.jackrabbit.mk.server.Server$2.run(Server.java:131) at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) at java.lang.Thread.run(Thread.java:680) Tests run: 72, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 15.639 sec FAILURE! Results : Tests in error: testBlobs[1](org.apache.jackrabbit.mk.test.MicroKernelIT): java.net.SocketException: Broken pipe Tests run: 72, Failures: 0, Errors: 1, Skipped: 0 Stack trace from the logs: --- Test set: org.apache.jackrabbit.mk.test.EverythingIT --- Tests run: 72, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 15.64 sec FAILURE! testBlobs[1](org.apache.jackrabbit.mk.test.MicroKernelIT) Time elapsed: 4.259 sec ERROR! org.apache.jackrabbit.mk.api.MicroKernelException: java.net.SocketException: Broken pipe at org.apache.jackrabbit.mk.client.Client.toMicroKernelException(Client.java:372) at org.apache.jackrabbit.mk.client.Client.write(Client.java:353) at org.apache.jackrabbit.mk.test.MicroKernelIT.testBlobs(MicroKernelIT.java:855) at org.apache.jackrabbit.mk.test.MicroKernelIT.testBlobs(MicroKernelIT.java:843) 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:597) 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.RunBefores.evaluate(RunBefores.java:28) at org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:30) 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.junit.runners.Suite.runChild(Suite.java:128) at org.junit.runners.Suite.runChild(Suite.java:24) 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.junit.runners.Suite.runChild(Suite.java:128) at org.junit.runners.Suite.runChild(Suite.java:24)
Re: TCK: strange XPath query
On 2012-05-24 12:12, Thomas Mueller wrote: Hi, The test org.apache.jackrabbit.test.api.query.OrderByMultiTypeTest.testMultipleOrder currently fails at line 73, where it tries to run a query of the form: (1) //testroot/*[@jcr:primaryType='nt:unstructured'] I believe there is a typo in the test, and the query should be: (2) /jcr:root/testroot/*[@jcr:primaryType='nt:unstructured'] Queries of type (1) are currently not supported, because they would contain two wildcards: path like '%/testroot/%'. I wonder if such queries are important, that is, whether we need to support them in the XPath to SQL-2 converter. It's possible to support them, but I would like to not support them now, unless *really* necessary. What do you think? Indeed!
[jira] [Resolved] (OAK-112) Refactor ModifiedNodeState and related classes to use type safe iterator utilities
[
https://issues.apache.org/jira/browse/OAK-112?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Dürig resolved OAK-112.
---
Resolution: Fixed
Fix Version/s: 0.3
fixed at revision 1342200
Refactor ModifiedNodeState and related classes to use type safe iterator
utilities
--
Key: OAK-112
URL: https://issues.apache.org/jira/browse/OAK-112
Project: Jackrabbit Oak
Issue Type: Improvement
Components: core
Reporter: Michael Dürig
Assignee: Michael Dürig
Fix For: 0.3
ModifiedNodeState and related classes currently use the iterator utilities
from commons-collections. This is a bit verbose and not type safe. I'd like
to refactor that and use the wrappers in
{{org.apache.jackrabbit.oak.util.Iterators}}.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (OAK-113) drop MicroKernel getNodes(String, String) convenience signature
Stefan Guggisberg created OAK-113:
-
Summary: drop MicroKernel getNodes(String, String) convenience
signature
Key: OAK-113
URL: https://issues.apache.org/jira/browse/OAK-113
Project: Jackrabbit Oak
Issue Type: Improvement
Components: mk
Reporter: Stefan Guggisberg
Assignee: Stefan Guggisberg
Priority: Minor
Fix For: 0.3
the MK API provides two getNodes signatures:
- {{getNodes(String, String)}}
- {{getNodes(String, String, int, long, int, String)}}
the former is a convenience method and equivalent to
{{getNodes(path, revisionId, 1, 0, -1, null)}}.
it's currently only used in test cases. in order to
streamline the API and the javadoc i suggest to drop it.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (OAK-114) MicroKernel API: specify retention policy for old revisions
Stefan Guggisberg created OAK-114: - Summary: MicroKernel API: specify retention policy for old revisions Key: OAK-114 URL: https://issues.apache.org/jira/browse/OAK-114 Project: Jackrabbit Oak Issue Type: Improvement Components: mk Reporter: Stefan Guggisberg the MicroKernel API javadoc should specify the minimal guaranteed retention period for old revisions. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (OAK-6) Setup integration tests and TCK tests
[ https://issues.apache.org/jira/browse/OAK-6?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13282489#comment-13282489 ] Julian Reschke commented on OAK-6: -- TCK status: Tests: 1905, Errors: 30, Failures: 114 Setup integration tests and TCK tests - Key: OAK-6 URL: https://issues.apache.org/jira/browse/OAK-6 Project: Jackrabbit Oak Issue Type: New Feature Components: it Reporter: Michael Dürig Labels: test Fix For: 0.1 See discussion here [1] and here [2] [1] http://markmail.org/message/km64ybgh5g7hvtiy?q=Jackrabbit+Oak+0.1+release+plan+%28Was:+[jr3]+Release+roadmap%29 [2] http://markmail.org/message/pwtxszvupvxyagk5?q=Integration+Tests+with+TCK -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (OAK-115) ItemDelegate and sub classes should throw IllegalItemStateException on stale items
[ https://issues.apache.org/jira/browse/OAK-115?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Dürig resolved OAK-115. --- Resolution: Fixed Fix Version/s: 0.3 Fixed at revision 1342275 ItemDelegate and sub classes should throw IllegalItemStateException on stale items -- Key: OAK-115 URL: https://issues.apache.org/jira/browse/OAK-115 Project: Jackrabbit Oak Issue Type: Improvement Components: jcr Reporter: Michael Dürig Assignee: Michael Dürig Fix For: 0.3 ItemDelegate and sub classes should throw IllegalItemStateException on stale items instead of relying on the consumer API to check staleness upfront -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Assigned] (OAK-116) MicroKernel API: clarify semantics of getNodes depth, offset and count parameters
[
https://issues.apache.org/jira/browse/OAK-116?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Guggisberg reassigned OAK-116:
-
Assignee: Stefan Guggisberg
MicroKernel API: clarify semantics of getNodes depth, offset and count
parameters
-
Key: OAK-116
URL: https://issues.apache.org/jira/browse/OAK-116
Project: Jackrabbit Oak
Issue Type: Improvement
Components: mk
Reporter: Stefan Guggisberg
Assignee: Stefan Guggisberg
Fix For: 0.3
{{MicroKernel.getNode(String path, String revisionId, int depth, long offset,
int count, String filter)}}
the semantics of {{depth}} as currently documented in the javadoc is
inconsistent:
- depth=0 returns empty child node objects
- depth=1 OTOH doesn't return empty grand children objects
the amount of information returned on the deepest level should IMO be
independent of the depth value.
{{count}} as currently documented is only applied to the root of the returned
subtree. this would imply that the implementation has to always return *all*
child nodes on deeper levels, even for potentially very large child node sets.
i suggest we rename {{count}} to {{maxChildNodes}} and apply it on every
level of the returned subtree.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
Path and name normalization in the query engine
Hi, The query engine in oak-core needs to normalize paths and names (convert ./name to name), for example for the TCK test org.apache.jackrabbit.test.api.query.qom.NodeNameTest.testURILiteral. I don't see a way to do the normalization within oak-jcr. The component that seems to be able to do that is NamePathMapper. I think there are two options: either add the NamePathMapper as a parameter to (the oak-core API method) QueryEngine.executeQuery, or add the NamePathMapper to (the oak-core interface) ContentSession. But I guess that would mean it needs to be added as a parameter to ContentRepository.login, which seems to be a bit strange. So I will add it as a parameter to QueryEngine.executeQuery. In the near future, the query engine will also need to evaluate node type information (also in oak-core). The method executeQuery will get at least one additional parameter, so will have 8 parameters in total. One alternative would be to keep the node type information and name path mapper in ContentSession. But I guess that's not what you guys want to do, right? Regards, Thomas
