Re: [VOTE] Release Apache Jackrabbit 1.3.1
Roy T. Fielding wrote: On Jul 27, 2007, at 11:57 PM, Jukka Zitting wrote: If my reasoning is correct, I would treat the issue as a test case bug to be fixed in a future release, and not a blocker to 1.3.1. I don't consider it a blocker. I think it may have existed on 1.3.0 as well, since I remember trying to test it and being unable to vote because of the failure (and not enough time to investigate it). Since nobody else has seen it, I just assume it is a local setup issue with maven. I just saw the same problem with trunk and JCR2SPI, in testing my SPI implementation. It seems it's triggered by the presence of pre-JDK-1.5 XML jars (Xerces, Xalan...). So no, it's nothing specific to the 1.3.1 release. Best regards, Julian
[jira] Created: (JCR-1039) Bundle Persistence Manager error - failing to read bundle the first time
Bundle Persistence Manager error - failing to read bundle the first time
Key: JCR-1039
URL: https://issues.apache.org/jira/browse/JCR-1039
Project: Jackrabbit
Issue Type: Bug
Affects Versions: 1.3
Environment: Windows
Reporter: Sridhar
Code:
NodeIterator entiter = null;
Node root = null, contNode = null, entsNode = null;
try
{
root = session.getRootNode();
contNode = root.getNode(sr:cont);
entsNode = contNode.getNode(sr:ents);
entiter = entsNode.getNodes();
}
catch (Exception e)
{
logger.error(Getting ents nodes, e);
}
Output:
12359 [http-8080-Processor24] ERROR
org.apache.jackrabbit.core.persistence.bundle.BundleDbPersistenceManager -
failed to read bundle: c3a09c19-cc6b-45bd-a42e-c4c925b67d02:
java.io.IOException: ERROR 40XD0: Container has been closed
12375 [http-8080-Processor24] ERROR com.taxila.editor.sm.RepoOperations -
Getting ents nodes
javax.jcr.PathNotFoundException: sr:ents
at org.apache.jackrabbit.core.NodeImpl.getNode(NodeImpl.java:2435)
at com.taxila.editor.sm.RepoOperations.getEntityNodes
(RepoOperations.java:4583)
at
com.taxila.editor.sm.RepoOperations.displayEntities(RepoOperations.java:4159)
at
com.taxila.editor.sm.RepoOperations.displayEntities(RepoOperations.java:4114)
at com.taxila.editor.em.um.MainEntityForm.reset (MainEntityForm.java:215)
at org.apache.struts.taglib.html.FormTag.doStartTag(FormTag.java:640)
at
org.apache.jsp.pages.jsp.entity.MainEntity_jsp._jspService(MainEntity_jsp.java:414)
at org.apache.jasper.runtime.HttpJspBase.service (HttpJspBase.java:97)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:802)
at
org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:332)
at org.apache.jasper.servlet.JspServlet.serviceJspFile (JspServlet.java:314)
at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:264)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:802)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter
(ApplicationFilterChain.java:252)
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)
at
org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDispatcher.java
:672)
at
org.apache.catalina.core.ApplicationDispatcher.processRequest(ApplicationDispatcher.java:463)
at
org.apache.catalina.core.ApplicationDispatcher.doForward(ApplicationDispatcher.java:398)
at org.apache.catalina.core.ApplicationDispatcher.forward
(ApplicationDispatcher.java:301)
at
org.apache.struts.action.RequestProcessor.doForward(RequestProcessor.java:1014)
at
org.apache.struts.action.RequestProcessor.processForwardConfig(RequestProcessor.java:417)
at
org.apache.struts.action.RequestProcessor.processActionForward(RequestProcessor.java:390)
at
org.apache.struts.action.RequestProcessor.process(RequestProcessor.java:271)
at org.apache.struts.action.ActionServlet.process (ActionServlet.java:1292)
at org.apache.struts.action.ActionServlet.doPost(ActionServlet.java:510)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:709)
at javax.servlet.http.HttpServlet.service (HttpServlet.java:802)
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:252)
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java
:173)
at
org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:213)
at
org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:178)
at org.apache.catalina.core.StandardHostValve.invoke
(StandardHostValve.java:126)
at
org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:105)
at
org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:107)
at org.apache.catalina.connector.CoyoteAdapter.service
(CoyoteAdapter.java:148)
at
org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:869)
at
org.apache.coyote.http11.Http11BaseProtocol$Http11ConnectionHandler.processConnection(Http11BaseProtocol.java
:664)
at
org.apache.tomcat.util.net.PoolTcpEndpoint.processSocket(PoolTcpEndpoint.java:527)
at
org.apache.tomcat.util.net.LeaderFollowerWorkerThread.runIt(LeaderFollowerWorkerThread.java:80)
at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run
(ThreadPool.java:684)
at java.lang.Thread.run(Unknown Source)
On the other hand if I do this:
Code:
try
{
root = session.getRootNode ();
contNode = root.getNode(sr:cont);
entsNode = contNode.getNode(sr:ents);
entiter = entsNode.getNodes();
}
catch (Exception e)
{
logger.error(Getting ents nodes, e);
try
{
entsNode = contNode.getNode(sr:ents);
entiter =
Re: Jira troubles
Jukka Zitting wrote: Hi, On 7/27/07, Julian Reschke [EMAIL PROTECTED] wrote: still can't create new issues. Is this: [...] the same problem others are seeing? There's a number of problems being reported on various forums. They are all caused by Jira running out of memory and starting to act strangely. The latest news on infrastructure@ is that the Jira installation should get upgraded tomorrow, after which things will hopefully return to normal. I just noticed that others have been successfully creating new issues, so I investigated further. It seems that *my* issue was caused by the fact that I'm running Firefox 3.0 alpha on my development machine. Once I used the latest FF 2.*, all was fine. Best regards, Julian
[jira] Created: (JCR-1040) JCR2SPI: remove node operation missing in submitted SPI batch
JCR2SPI: remove node operation missing in submitted SPI batch
-
Key: JCR-1040
URL: https://issues.apache.org/jira/browse/JCR-1040
Project: Jackrabbit
Issue Type: Bug
Components: SPI
Reporter: Julian Reschke
In JCR2SPI, the following sequence of operations seems to lead to an incorrect
SPI batch being submitted:
1) remove /a
2) add /a
3) add /a/b
4) session.save()
This seems to create an SPI batch where the first remove operation is missing.
Note that the problem only seems to occur when step 3 is part of the sequence.
Full Java source for test:
try {
if
(session.getRepository().getDescriptor(Repository.LEVEL_2_SUPPORTED).equals(true))
{
Node testnode;
String name = delete-test;
Node root = session.getRootNode();
// make sure it's there
if (! root.hasNode(name)) {
root.addNode(name, nt:folder);
session.save();
}
// now test remove/add in one batch
if (root.hasNode(name)) {
testnode = root.getNode(name);
testnode.remove();
// session.save(); // un-commenting this makes the test pass
}
testnode = root.addNode(name, nt:folder);
// add one child
testnode.addNode(name, nt:folder); // commenting this out makes the
test pass
session.save();
}
} finally {
session.logout();
}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (JCR-1039) Bundle Persistence Manager error - failing to read bundle the first time
[
https://issues.apache.org/jira/browse/JCR-1039?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12516346
]
Stefan Guggisberg commented on JCR-1039:
java.io.IOException: ERROR 40XD0: Container has been closed
seems to be DerbyPersistenceManager related (40XD0 is a derby error code).
googling ERROR 40XD0: Container has been closed returns lots of interesting
hits.
seems like this problem only occurs with autoCommit=true.
during reading a serialized 'bundle' from the db, other stmts might be issued
(like reading name index) which in turn could cause the original stream to
be closed, hence the Container has been closed IOException.
Bundle Persistence Manager error - failing to read bundle the first time
Key: JCR-1039
URL: https://issues.apache.org/jira/browse/JCR-1039
Project: Jackrabbit
Issue Type: Bug
Affects Versions: 1.3
Environment: Windows
Reporter: Sridhar
Code:
NodeIterator entiter = null;
Node root = null, contNode = null, entsNode = null;
try
{
root = session.getRootNode();
contNode = root.getNode(sr:cont);
entsNode = contNode.getNode(sr:ents);
entiter = entsNode.getNodes();
}
catch (Exception e)
{
logger.error(Getting ents nodes, e);
}
Output:
12359 [http-8080-Processor24] ERROR
org.apache.jackrabbit.core.persistence.bundle.BundleDbPersistenceManager -
failed to read bundle: c3a09c19-cc6b-45bd-a42e-c4c925b67d02:
java.io.IOException: ERROR 40XD0: Container has been closed
12375 [http-8080-Processor24] ERROR com.taxila.editor.sm.RepoOperations -
Getting ents nodes
javax.jcr.PathNotFoundException: sr:ents
at org.apache.jackrabbit.core.NodeImpl.getNode(NodeImpl.java:2435)
at com.taxila.editor.sm.RepoOperations.getEntityNodes
(RepoOperations.java:4583)
at
com.taxila.editor.sm.RepoOperations.displayEntities(RepoOperations.java:4159)
at
com.taxila.editor.sm.RepoOperations.displayEntities(RepoOperations.java:4114)
at com.taxila.editor.em.um.MainEntityForm.reset (MainEntityForm.java:215)
at org.apache.struts.taglib.html.FormTag.doStartTag(FormTag.java:640)
at
org.apache.jsp.pages.jsp.entity.MainEntity_jsp._jspService(MainEntity_jsp.java:414)
at org.apache.jasper.runtime.HttpJspBase.service (HttpJspBase.java:97)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:802)
at
org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:332)
at org.apache.jasper.servlet.JspServlet.serviceJspFile
(JspServlet.java:314)
at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:264)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:802)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter
(ApplicationFilterChain.java:252)
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)
at
org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDispatcher.java
:672)
at
org.apache.catalina.core.ApplicationDispatcher.processRequest(ApplicationDispatcher.java:463)
at
org.apache.catalina.core.ApplicationDispatcher.doForward(ApplicationDispatcher.java:398)
at org.apache.catalina.core.ApplicationDispatcher.forward
(ApplicationDispatcher.java:301)
at
org.apache.struts.action.RequestProcessor.doForward(RequestProcessor.java:1014)
at
org.apache.struts.action.RequestProcessor.processForwardConfig(RequestProcessor.java:417)
at
org.apache.struts.action.RequestProcessor.processActionForward(RequestProcessor.java:390)
at
org.apache.struts.action.RequestProcessor.process(RequestProcessor.java:271)
at org.apache.struts.action.ActionServlet.process
(ActionServlet.java:1292)
at org.apache.struts.action.ActionServlet.doPost(ActionServlet.java:510)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:709)
at javax.servlet.http.HttpServlet.service (HttpServlet.java:802)
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:252)
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java
:173)
at
org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:213)
at
org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:178)
at org.apache.catalina.core.StandardHostValve.invoke
(StandardHostValve.java:126)
at
org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:105)
at
org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:107)
at org.apache.catalina.connector.CoyoteAdapter.service
(CoyoteAdapter.java:148)
at
[jira] Updated: (JCR-1039) Bundle Persistence Manager error - failing to read bundle the first time
[
https://issues.apache.org/jira/browse/JCR-1039?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Guggisberg updated JCR-1039:
---
Component/s: core
Bundle Persistence Manager error - failing to read bundle the first time
Key: JCR-1039
URL: https://issues.apache.org/jira/browse/JCR-1039
Project: Jackrabbit
Issue Type: Bug
Components: core
Affects Versions: 1.3
Environment: Windows
Reporter: Sridhar
Code:
NodeIterator entiter = null;
Node root = null, contNode = null, entsNode = null;
try
{
root = session.getRootNode();
contNode = root.getNode(sr:cont);
entsNode = contNode.getNode(sr:ents);
entiter = entsNode.getNodes();
}
catch (Exception e)
{
logger.error(Getting ents nodes, e);
}
Output:
12359 [http-8080-Processor24] ERROR
org.apache.jackrabbit.core.persistence.bundle.BundleDbPersistenceManager -
failed to read bundle: c3a09c19-cc6b-45bd-a42e-c4c925b67d02:
java.io.IOException: ERROR 40XD0: Container has been closed
12375 [http-8080-Processor24] ERROR com.taxila.editor.sm.RepoOperations -
Getting ents nodes
javax.jcr.PathNotFoundException: sr:ents
at org.apache.jackrabbit.core.NodeImpl.getNode(NodeImpl.java:2435)
at com.taxila.editor.sm.RepoOperations.getEntityNodes
(RepoOperations.java:4583)
at
com.taxila.editor.sm.RepoOperations.displayEntities(RepoOperations.java:4159)
at
com.taxila.editor.sm.RepoOperations.displayEntities(RepoOperations.java:4114)
at com.taxila.editor.em.um.MainEntityForm.reset (MainEntityForm.java:215)
at org.apache.struts.taglib.html.FormTag.doStartTag(FormTag.java:640)
at
org.apache.jsp.pages.jsp.entity.MainEntity_jsp._jspService(MainEntity_jsp.java:414)
at org.apache.jasper.runtime.HttpJspBase.service (HttpJspBase.java:97)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:802)
at
org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:332)
at org.apache.jasper.servlet.JspServlet.serviceJspFile
(JspServlet.java:314)
at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:264)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:802)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter
(ApplicationFilterChain.java:252)
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)
at
org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDispatcher.java
:672)
at
org.apache.catalina.core.ApplicationDispatcher.processRequest(ApplicationDispatcher.java:463)
at
org.apache.catalina.core.ApplicationDispatcher.doForward(ApplicationDispatcher.java:398)
at org.apache.catalina.core.ApplicationDispatcher.forward
(ApplicationDispatcher.java:301)
at
org.apache.struts.action.RequestProcessor.doForward(RequestProcessor.java:1014)
at
org.apache.struts.action.RequestProcessor.processForwardConfig(RequestProcessor.java:417)
at
org.apache.struts.action.RequestProcessor.processActionForward(RequestProcessor.java:390)
at
org.apache.struts.action.RequestProcessor.process(RequestProcessor.java:271)
at org.apache.struts.action.ActionServlet.process
(ActionServlet.java:1292)
at org.apache.struts.action.ActionServlet.doPost(ActionServlet.java:510)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:709)
at javax.servlet.http.HttpServlet.service (HttpServlet.java:802)
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:252)
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java
:173)
at
org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:213)
at
org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:178)
at org.apache.catalina.core.StandardHostValve.invoke
(StandardHostValve.java:126)
at
org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:105)
at
org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:107)
at org.apache.catalina.connector.CoyoteAdapter.service
(CoyoteAdapter.java:148)
at
org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:869)
at
org.apache.coyote.http11.Http11BaseProtocol$Http11ConnectionHandler.processConnection(Http11BaseProtocol.java
:664)
at
org.apache.tomcat.util.net.PoolTcpEndpoint.processSocket(PoolTcpEndpoint.java:527)
at
org.apache.tomcat.util.net.LeaderFollowerWorkerThread.runIt(LeaderFollowerWorkerThread.java:80)
at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run
(ThreadPool.java:684)
at java.lang.Thread.run(Unknown Source)
On the
Re: Jira troubles
Bertrand Delacretaz wrote: On 7/30/07, Julian Reschke [EMAIL PROTECTED] wrote: ...It seems that *my* issue was caused by the fact that I'm running Firefox 3.0 alpha on my development machine. Once I used the latest FF 2.*, all was fine Yes, there's an issue between Firefox 3.0 alpha and Jira, see https://issues.apache.org/jira/browse/INFRA-1285 Recent Firefox builds send a Content-Type header with each multipart/form-data part, this might break a few webapps out there. Bertrand, thanks for the pointers. At least now I understand what's going on :-). Best regards, Julian
[jira] Commented: (JCR-1040) JCR2SPI: remove node operation missing in submitted SPI batch
[
https://issues.apache.org/jira/browse/JCR-1040?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12516380
]
Julian Reschke commented on JCR-1040:
-
This seems to be non trivial.
The code in o.a.j.jcr2spi.state.ChangeLog tries to sanitize the operations, but
seems to go to far.
a) statusChanged EXISTING_REMOVED-REMOVED removes the Remove operation.
b) Taking out that code leads to a ConstraintViolation in
checkIsSelfContained().
c) Taking out that check leads to a Batch being submitted which does contain
the Remove operation, but now another issue becomes visible -- looking at the
sequence of operations again:
1) remove /a
2) add /a
3) add /a/b
The third operation's parent id now refers to the node /a that was removed in
step 1, and thus will cause a failure in the SPI implementation (because that
node is gone when step 3 is executed).
This requires more research...
JCR2SPI: remove node operation missing in submitted SPI batch
-
Key: JCR-1040
URL: https://issues.apache.org/jira/browse/JCR-1040
Project: Jackrabbit
Issue Type: Bug
Components: SPI
Reporter: Julian Reschke
In JCR2SPI, the following sequence of operations seems to lead to an
incorrect SPI batch being submitted:
1) remove /a
2) add /a
3) add /a/b
4) session.save()
This seems to create an SPI batch where the first remove operation is missing.
Note that the problem only seems to occur when step 3 is part of the sequence.
Full Java source for test:
try {
if
(session.getRepository().getDescriptor(Repository.LEVEL_2_SUPPORTED).equals(true))
{
Node testnode;
String name = delete-test;
Node root = session.getRootNode();
// make sure it's there
if (! root.hasNode(name)) {
root.addNode(name, nt:folder);
session.save();
}
// now test remove/add in one batch
if (root.hasNode(name)) {
testnode = root.getNode(name);
testnode.remove();
// session.save(); // un-commenting this makes the test pass
}
testnode = root.addNode(name, nt:folder);
// add one child
testnode.addNode(name, nt:folder); // commenting this out makes the
test pass
session.save();
}
} finally {
session.logout();
}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (JCR-1037) Memory leak causing performance problems
[ https://issues.apache.org/jira/browse/JCR-1037?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12516399 ] Antonio Carballo commented on JCR-1037: --- We were wondering if it was a way to turn off the caching-subsystem. We are just getting nervous about JCR's ability to handle heavy loads with its current caching algorithm. Please advice. /Antonio Memory leak causing performance problems Key: JCR-1037 URL: https://issues.apache.org/jira/browse/JCR-1037 Project: Jackrabbit Issue Type: Bug Components: Jackrabbit API Affects Versions: 1.2.1, 1.2.2, 1.2.3, 1.3 Environment: Tomcat 6.0, XP Pro w/1Gb Reporter: Antonio Carballo Folks, We have been running tests on JCR v1.3 and v1.2.1 for the past two weeks. The system keeps running out of memory after X number of documents are added. Our initial test consisted of about 50 documents and gradually increased to about 150 documents. The size of the documents ranged from 1K to 9MB. We later changed the test to consist of files with less than 1K in length with the same result. Increasing the heap size delays the error but the outcome is always the same (Servlet runs out of heap memory.) Using JProbe we found a high number of references created by the caching sub-system (SessionItemStateManager.java, SharedItemStateManager.java, LocalItemStateManager.java). We changed the caching parameters using CacheManager (min 64K - max 16MB). This change only delayed the error. Servlet eventually runs out of heap memory. We are more than happy to share our findings (even source code and test data) with the Jackrabbit team. Please let us know how you wish to proceed. Sincerely, Antonio Carballo -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (JCR-1034) Unable to save session after saving a renamed node
[
https://issues.apache.org/jira/browse/JCR-1034?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Guggisberg resolved JCR-1034.
Resolution: Fixed
fixed in svn rev. #561000
Unable to save session after saving a renamed node
--
Key: JCR-1034
URL: https://issues.apache.org/jira/browse/JCR-1034
Project: Jackrabbit
Issue Type: Bug
Components: core
Reporter: Edgar Poce
Assignee: Stefan Guggisberg
Priority: Minor
TransientRepository repo = new TransientRepository(
applications/test/repository.xml,
applications/test);
Session s = repo.login(new SimpleCredentials(test,
.toCharArray()));
if (s.getRootNode().hasNode(parent)) {
s.getRootNode().getNode(parent).remove();
s.save();
}
// create parent node
Node parent = s.getRootNode().addNode(parent);
// create node to rename
parent.addNode(newnode);
s.save();
// rename node
s.move(/parent/newnode, /parent/renamedNewNode);
// save renamed node
s.getRootNode().getNode(parent/renamedNewNode).save();
// try to save session -- FAILS
s.save();
s.logout();
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Created: (JCR-1041) Avoid using BitSets in ChildAxisQuery to minimize memory usage
Avoid using BitSets in ChildAxisQuery to minimize memory usage -- Key: JCR-1041 URL: https://issues.apache.org/jira/browse/JCR-1041 Project: Jackrabbit Issue Type: Improvement Components: query Affects Versions: 1.3 Reporter: Christoph Kiehl Assignee: Christoph Kiehl When doing ChildAxisQueries on large indexes the internal BitSet instance (hits) may consume a lot of memory because the BitSet is always as large as IndexReader.maxDoc(). In our case we had a query consisting of 7 ChildAxisQueries which combined to a total of 14MB. Since we have multiple users executing this query simultaneously this caused an out of memory error. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (JCR-1041) Avoid using BitSets in ChildAxisQuery to minimize memory usage
[ https://issues.apache.org/jira/browse/JCR-1041?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christoph Kiehl updated JCR-1041: - Attachment: avoid_using_bitsets.patch This patch introduces a few new classes for the handling of hits. In essence this patch does two things: 1. It tries to use int arrays instead of BitSet to reduce memory consumption. If a BitSet is more efficient than an int array it switches to using a BitSet instance. 2. The nameTestHits are only created lazily by wrapping the nameTestScorer in a Hits instance. 3. The calculation if the index of a childnode is valid is only done if the corresponding hit is requested. In our internal tests the query execution performance didn't suffer but is much better for ChildAxisQueries with a large number of matching child nodes. Avoid using BitSets in ChildAxisQuery to minimize memory usage -- Key: JCR-1041 URL: https://issues.apache.org/jira/browse/JCR-1041 Project: Jackrabbit Issue Type: Improvement Components: query Affects Versions: 1.3 Reporter: Christoph Kiehl Assignee: Christoph Kiehl Attachments: avoid_using_bitsets.patch When doing ChildAxisQueries on large indexes the internal BitSet instance (hits) may consume a lot of memory because the BitSet is always as large as IndexReader.maxDoc(). In our case we had a query consisting of 7 ChildAxisQueries which combined to a total of 14MB. Since we have multiple users executing this query simultaneously this caused an out of memory error. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (JCR-1042) Disable norms for untokenized fields to reduce memory consumption
Disable norms for untokenized fields to reduce memory consumption - Key: JCR-1042 URL: https://issues.apache.org/jira/browse/JCR-1042 Project: Jackrabbit Issue Type: Improvement Components: indexing Affects Versions: 1.3 Reporter: Christoph Kiehl Assignee: Christoph Kiehl Attachments: NodeIndexer.patch For repositories with many indexed fields, the norms cause memory problems both during indexing and querying (see LUCENE-448). Since the fields in question were never boosted they could as well be indexed without norms. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (JCR-1042) Disable norms for untokenized fields to reduce memory consumption
[ https://issues.apache.org/jira/browse/JCR-1042?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christoph Kiehl updated JCR-1042: - Attachment: NodeIndexer.patch Index all un-tokenized field without norms Disable norms for untokenized fields to reduce memory consumption - Key: JCR-1042 URL: https://issues.apache.org/jira/browse/JCR-1042 Project: Jackrabbit Issue Type: Improvement Components: indexing Affects Versions: 1.3 Reporter: Christoph Kiehl Assignee: Christoph Kiehl Attachments: NodeIndexer.patch For repositories with many indexed fields, the norms cause memory problems both during indexing and querying (see LUCENE-448). Since the fields in question were never boosted they could as well be indexed without norms. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[RESULT] [VOTE] Release Apache Jackrabbit 1.3.1
Hi, On 7/21/07, Jukka Zitting [EMAIL PROTECTED] wrote: Please vote on releasing these packages as Apache Jackrabbit 1.3.1. The vote passes with the following votes (* is member of the Jackrabbit PMC): +1 Jukka Zitting (*) +1 Alexandre Martins +1 Bertrand Delacretaz +1 Stefan Guggisberg (*) +1 Julian Reschke (*) I will make the release available and send the official release announcement once the download mirrors have been updated (or a bit later, depending on when I next have net access). BR, Jukka Zitting (at 69.039020, 20.817030)
[jira] Created: (JCR-1043) Package names for spring project do not match update ocm packages
Package names for spring project do not match update ocm packages - Key: JCR-1043 URL: https://issues.apache.org/jira/browse/JCR-1043 Project: Jackrabbit Issue Type: Bug Components: jcr-mapping Affects Versions: 1.3 Environment: All environments Reporter: Padraic Hannon Priority: Blocker The spring package and tests reference the old graffitto package naming scheme. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (JCR-1043) Package names for spring project do not match update ocm packages
[ https://issues.apache.org/jira/browse/JCR-1043?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Padraic Hannon updated JCR-1043: Attachment: spring.tar.gz Here is a directory structure with refactored files that will work. I tried to do a svn diff, but with the directory changes it was fairly unhappy. Not being a subversion expert a tar ball was easier. Package names for spring project do not match update ocm packages - Key: JCR-1043 URL: https://issues.apache.org/jira/browse/JCR-1043 Project: Jackrabbit Issue Type: Bug Components: jcr-mapping Affects Versions: 1.3 Environment: All environments Reporter: Padraic Hannon Priority: Blocker Attachments: spring.tar.gz The spring package and tests reference the old graffitto package naming scheme. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (JCR-1044) NTCollectionConverterImpl throws a null pointer exception on update
NTCollectionConverterImpl throws a null pointer exception on update --- Key: JCR-1044 URL: https://issues.apache.org/jira/browse/JCR-1044 Project: Jackrabbit Issue Type: Bug Components: jcr-mapping Affects Versions: 1.3 Environment: All Reporter: Padraic Hannon When calling update on a node which has no child nodes stored (but which can have child nodes) the code can generate a null pointer exception. In the case where one goes to remove JCR nodes which are not present in the current objects collection of child objects the code is calling getCollectionNodes().iterator(). However, since is not checking for the case where getCollectionNodes() returns null if there are no child nodes present a null pointer exception will be generated. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (JCR-1044) NTCollectionConverterImpl throws a null pointer exception on update
[ https://issues.apache.org/jira/browse/JCR-1044?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Padraic Hannon updated JCR-1044: Attachment: NTCollectionConverterImpl.diff This puts a null check around the code which is attempting to delete JCR nodes not present in the current objects collection. NTCollectionConverterImpl throws a null pointer exception on update --- Key: JCR-1044 URL: https://issues.apache.org/jira/browse/JCR-1044 Project: Jackrabbit Issue Type: Bug Components: jcr-mapping Affects Versions: 1.3 Environment: All Reporter: Padraic Hannon Attachments: NTCollectionConverterImpl.diff When calling update on a node which has no child nodes stored (but which can have child nodes) the code can generate a null pointer exception. In the case where one goes to remove JCR nodes which are not present in the current objects collection of child objects the code is calling getCollectionNodes().iterator(). However, since is not checking for the case where getCollectionNodes() returns null if there are no child nodes present a null pointer exception will be generated. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
