[
https://issues.apache.org/jira/browse/JCR-1323?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Christoph Kiehl updated JCR-1323:
-
Fix Version/s: 1.4.1
When using QueryImpl.setLimit() and QueryImpl.setOffset
[
https://issues.apache.org/jira/browse/JCR-1323?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Christoph Kiehl resolved JCR-1323.
--
Resolution: Fixed
Fix Version/s: 1.5
Thanks a lot for clarifying! Fixed in rev. 613221
[
https://issues.apache.org/jira/browse/JCR-1196?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12560259#action_12560259
]
Christoph Kiehl commented on JCR-1196:
--
Description for slow ChildAxisQuery by Martin
[
https://issues.apache.org/jira/browse/JCR-1324?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Christoph Kiehl resolved JCR-1324.
--
Resolution: Duplicate
Assignee: Christoph Kiehl
Thanks for reporting but this is a knows
[
https://issues.apache.org/jira/browse/JCR-1302?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12557624#action_12557624
]
Christoph Kiehl commented on JCR-1302:
--
Thanks a lot Owen for tracking this down
[
https://issues.apache.org/jira/browse/JCR-1302?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Christoph Kiehl reassigned JCR-1302:
Assignee: Christoph Kiehl
ArrayHits does not end properly when skipTo doesn't find document
Jukka Zitting wrote:
I'm not saying it has to be the default, but it could be optional. I have a
patch for 1.4 that adds
a lockingStrategy attribute to the repository config (per repository), and it
has a few tweaks in
it. I can upload it for review. Our testing with 1.3.1 + FGL shows a
[
https://issues.apache.org/jira/browse/JCR-1251?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12549493
]
Christoph Kiehl commented on JCR-1251:
--
Well spotted! I observed another gain of about 7% on my machine
[
https://issues.apache.org/jira/browse/JCR-1251?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Christoph Kiehl resolved JCR-1251.
--
Resolution: Fixed
Committed in rev. 601562
DescendantSelfAxisQuery creates too many object
Marcel Reutegger (JIRA) wrote:
Finally committed a mix of christophs and my patch. The performance
characteristics are very similar to the attached patches.
I very much like the outcome! Thanks a lot for cleaning up!
Cheers,
Christoph
[
https://issues.apache.org/jira/browse/JCR-1251?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12547620
]
Christoph Kiehl commented on JCR-1251:
--
Ah, you are certainly right. I'll use System.arraycopy instead. Thanks
Components: jackrabbit-core, query
Reporter: Christoph Kiehl
Assignee: Christoph Kiehl
Priority: Minor
Fix For: 1.4
In DescendantSelfAxisQuery.DescendantSelfAxisScorer.isValid() there is an
ArrayList and an Integer instance created on every call. Since
[
https://issues.apache.org/jira/browse/JCR-1251?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Christoph Kiehl updated JCR-1251:
-
Attachment: DescendantSelfAxisQuery-patch.txt
I'm getting a performance boost of about 40% on big
Ard Schrijvers wrote:
Query q = qm.createQuery(stuff//[EMAIL PROTECTED], Query.XPATH);
if (q instanceof QueryImpl) {
// limit the result set
((QueryImpl) q).setLimit(1);
}
Since my stuff//[EMAIL PROTECTED] gives me 1.200.000, it makes perfect
sense to users I think, that even with our
Ard Schrijvers wrote:
Since my stuff//[EMAIL PROTECTED] gives me 1.200.000, it makes
perfect sense
to users I think, that even with our patches and a working
cache, that
retaining them all would be slow. But if I set the limit to
1 or 10, I
would expect to have performance (certainly when
[
https://issues.apache.org/jira/browse/JCR-1213?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Christoph Kiehl updated JCR-1213:
-
Attachment: JCR-1213-ckiehl.txt
I like Marcels idea to use the creation tick to identity the base
[
https://issues.apache.org/jira/browse/JCR-1213?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Christoph Kiehl updated JCR-1213:
-
Attachment: (was: JCR-1213-ckiehl.txt)
UUIDDocId cache does not work properly because
[
https://issues.apache.org/jira/browse/JCR-1213?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Christoph Kiehl updated JCR-1213:
-
Attachment: JCR-1213-ckiehl.txt
Fixed a small glitch. And btw, there is still some javadoc
[
https://issues.apache.org/jira/browse/JCR-1236?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12545755
]
Christoph Kiehl commented on JCR-1236:
--
What's the reason for changing the skin? I like the old one better than
[
https://issues.apache.org/jira/browse/JCR-1237?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12545971
]
Christoph Kiehl commented on JCR-1237:
--
+1 to change the default for respectDocumentOrder to false. Most people
[
https://issues.apache.org/jira/browse/JCR-1238?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12545975
]
Christoph Kiehl commented on JCR-1238:
--
Sounds good! +1
Change default value for maxMergeDocs
Jukka Zitting wrote:
Martijn and Ard, welcome to the team!
Great to have you both on board! Big welcome!
Cheers,
Christoph
Reporter: Christoph Kiehl
I find the following Exception in our log files from time to time. I don't know
how to replicate it and I couldn't find a ticket in Jira nor seemed the recent
changes on the participating classes in trunk handling this error:
java.lang.NullPointerException
Hi Ard!
Very nice analysis! It's indeed a very tricky bug ;) UUIDDocId should
not use WeakReferences on the one hand and equals() on the other hand.
Maybe we should better return the same instance of a CombinedIndexReader
in SearchIndex.getIndexReader() if possible and use a == comparison in
Ard Schrijvers wrote:
Follow up: it seems that my mergeFactor was way to high (100) resulting
in many indexes. Setting it to 5 seems to improve trivial searches a
lot! At the same time, I had maxMergeDocs too small, resulting in many
indexes as well.
Is there any golden rule on how to tune
Jukka Zitting wrote:
The components within jackrabbit/trunk/contrib are not included in our
releases and whenever a release branch is created the contrib folder
needs to be explicitly removed from the branch.
To avoid that removal step and to make it clearer that the contrib
components are not
Jukka Zitting wrote:
I hear a number of Apache projects have had good experience on using a
Confluence wiki as a kind of a CMS for editing their web sites. How
would you feel if we took the same approach in Jackrabbit? Write
access to the web site wiki would still be limited to committers.
I
Thomas Mueller wrote:
Two more advantages of a hand-written parser:
- You can actually debug the parser. No chance with JavaCC or ANTLR
A very important point in my opinion! I learned a lot of Jackrabbits internals
by debugging.
Cheers,
Christoph
Thomas Mueller wrote:
use javacc for SQL2 parsing
I would use a hand-written recursive descent parser. I know I'm
probably the only one suggesting this...
Well, not quite ;) I asked because currently you need to have knowledge about
javacc to extend the parsers. I would like to make it
Bertrand Delacretaz wrote:
On 9/11/07, Christoph Kiehl [EMAIL PROTECTED] wrote:
...WDOT?...
I agree with Thomas that he'll probably be the only one to suggest a
hand-written parser ;-)
Ok ;) So does anyone know of any easier to understand solutions than using
javacc? Maybe it is just
Marcel Reutegger wrote:
well, those are actually just my thoughts how I think we should
implement the query enhancements specified in JSR 283.
there are basically three major blocks that we need to implement:
- JQOM, allows you to programmatically create a query
- JCR-SQL2, the new SQL query
[
https://issues.apache.org/jira/browse/JCR-1041?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12524997
]
Christoph Kiehl commented on JCR-1041:
--
Fixed a little bug in ChildAxisScorer.skipTo() in revision 572885
Ard Schrijvers wrote:
Christoph Kiehl wrote:
I made some changes to the ChildAxisScorer while working on JCR-1041.
Unfortunately I don't have the time right now to check if I
introduced this bug.
I'll try to have a look later this day. Feel free to check
the affected revisions.
When
[
https://issues.apache.org/jira/browse/JCR-1073?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Christoph Kiehl resolved JCR-1073.
--
Resolution: Fixed
Fix Version/s: 1.4
Committed patch in revision 572889. I'll open a new
Type: Task
Components: query
Reporter: Christoph Kiehl
Assignee: Christoph Kiehl
Priority: Minor
Fix For: 1.4
QueryResultImpl isn't used in Jackrabbit anymore. Instead LazyQueryResultImpl
is now used. See the discussion in JCR-1073
[
https://issues.apache.org/jira/browse/JCR-1114?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Christoph Kiehl resolved JCR-1114.
--
Resolution: Fixed
Committed changes in revision 572890 and 572891.
Remove QueryResultImpl
Ard Schrijvers wrote:
when running the same very simple test below in the JR trunk a few times (~5
times) I get an ArrayOutOfBoundsException in the
ChildAxisQuery.ChildAxisScorer.indexIsValid(int i) on
Document node = reader.document(i);
Did anybody have this before? The simple test is below.
Jukka Zitting wrote:
Please cast your votes:
[x] +1 Approve the Sling project for incubation
[ ] -1 Don't approve the project, because...
Looking very much forward to it. Sounds like a _very_ interesting project.
Cheers,
Christoph
[
https://issues.apache.org/jira/browse/JCR-1066?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Christoph Kiehl updated JCR-1066:
-
Attachment: QueryNodeFactory_2.patch
I like the patch. Just one thought:
I would prefer removing
Ard Schrijvers wrote:
Hello,
there seems to be two LuceneQueryBuilder.createQuery methods, where the first
looks like:
public static Query createQuery(QueryRootNode root,
SessionImpl session,
ItemStateManager
[
https://issues.apache.org/jira/browse/JCR-1064?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12522442
]
Christoph Kiehl commented on JCR-1064:
--
I like the patch so far. Just a few comments:
LuceneQueryBuilder:
- I
Ard Schrijvers wrote:
So, WDOT about indexing properties in seperate lucene Fields, and about
possibly indexing more information of one property. My experience with
lucene, is that indexing tactically, eases querying a lot, and gains you lots
of performance. So, if you do agree on these
Ard Schrijvers wrote:
Christoph Kiehl wrote:
4. Regarding sorting: We will still need our own sorting because we cache
the document order per subreader whereas lucenes sorting only caches per
reader which get invalidated after every write operation. But the initial
cache creation will be faster
Ard Schrijvers wrote:
Wellif I start implementing the 1:1 mapping simultaneously and have to
make this backwards compatible also for old indices, I am afraid that I have
to test all around the place.
As far as I can see the following needs to be done:
In LuceneQueryBuilder methods need
[
https://issues.apache.org/jira/browse/JCR-1066?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Christoph Kiehl updated JCR-1066:
-
Attachment: patch_with_extendible_system_nodetypes.txt
I'm not really happy with all those
[
https://issues.apache.org/jira/browse/JCR-1073?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Christoph Kiehl updated JCR-1073:
-
Attachment: patch.txt
A first shot how this might look like. I stumbled over QueryResultImpl which
[
https://issues.apache.org/jira/browse/JCR-1066?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Christoph Kiehl updated JCR-1066:
-
Attachment: (was: patch.txt)
Exclude system index for queries that restrict the result set
[
https://issues.apache.org/jira/browse/JCR-1066?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Christoph Kiehl updated JCR-1066:
-
Attachment: patch.txt
rep:system was still missing
Exclude system index for queries
Jukka Zitting wrote:
Hi,
On 8/17/07, Christoph Kiehl [EMAIL PROTECTED] wrote:
Thomas Mueller wrote:
That's a good idea! Implementations that can't support it efficiently
could then calculate the size only when required. What about
getTotalSize()?
Implementations should maybe even allowed
Ard Schrijvers wrote:
Since IMO this is such a performance and scalability improvement I want to
discuss the backwards compatability for older jackrabbit releases which have
an index which is not suitable for this new approach. Checking the current
index at startup and then fallback to old
Ard Schrijvers wrote:
I did not know about the soon to be deprecated class.
Well, I thought Marcels suggestion implied that. To quote him:
further development will then only happen on the new QueryHandler implementation
Cheers,
Christoph
[
https://issues.apache.org/jira/browse/JCR-1066?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Christoph Kiehl updated JCR-1066:
-
Attachment: patch.txt
Added a corrected patch which incorporates the suggested changes. You were
Thomas Mueller wrote:
I'm not concerned about an implementation not being able to 'support'
setLimit(). I rather think of applications using that new method and at the same
time wish to find out the total number of matches, as written initially by
Christoph.
I understand.
keep the
Marcel Reutegger wrote:
Hmm, after some thinking here's another proposal:
keep the setLimit() as is. but introduce a getSize() (or
getTotalMatches()?) on the QueryResult. This method always returns the
total number of nodes/rows independent of setLimit().
That was what I was trying to
Ard Schrijvers wrote:
Ard Schrijvers wrote:
I did not know about the soon to be deprecated class.
Well, I thought Marcels suggestion implied that. To quote him:
further development will then only happen on the new QueryHandler
implementation
Yes you're right. I read it wrong and thought I
Marcel Reutegger wrote:
1) New QueryHandler class
2) Introduce parameter in configuration
3) Auto-detect in SearchIndex
I prefer 1) because it makes it explicit. I have reservations regarding
3) because it introduces some magic. I don't like 2) because we probably
cannot come up with a
[
https://issues.apache.org/jira/browse/JCR-1066?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Christoph Kiehl updated JCR-1066:
-
Attachment: (was: patch.txt)
Exclude system index for queries that restrict the result set
://issues.apache.org/jira/browse/JCR-1066
Project: Jackrabbit
Issue Type: Improvement
Components: query
Reporter: Christoph Kiehl
Assignee: Christoph Kiehl
Priority: Minor
Fix For: 1.4
We already have code that is able
[
https://issues.apache.org/jira/browse/JCR-1066?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Christoph Kiehl updated JCR-1066:
-
Attachment: patch.txt
This is an initial patch. I'm not fully satisfied with it because
[
https://issues.apache.org/jira/browse/JCR-1066?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Christoph Kiehl updated JCR-1066:
-
Attachment: (was: patch.txt)
Exclude system index for queries that restrict the result set
Hi!
First: This is definitely not supposed to become a discussion which IDE
is better!
I was just curious which IDEs Jackrabbit developers use. I generally use
Eclipse, but I've got some problems, as Subclipse still does not support
nested projects very well. Do you encounter this as well?
[
https://issues.apache.org/jira/browse/JCR-1041?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Christoph Kiehl resolved JCR-1041.
--
Resolution: Fixed
Fix Version/s: 1.4
Added suggested patch with additional license
Marcel Reutegger wrote:
Ard Schrijvers wrote:
IMO, we should index more (derived) data about a documents properties
(I'll
return to this in a mail about IndexingConfiguration which I think we
can add
some features that might tackle this) if we want to be able to query
fast.
For this specific
Jukka Zitting wrote:
Not having nested projects is not an issue to me, as I import the
projects beside each other, and generally do not care for the parent
projects, which I rarely (if ever) touch.
Exactly. My process of setting up a fresh checkout is:
$ mkdir jackrabbit
$ cd
Ard Schrijvers wrote:
Christoph Kiehl wrote:
We could use IndexReader.getFieldNames() at startup to check
if such a
field already exists which means we have an index in the new
format and
then use this information in MatchAllScorer to decide which
implementation to use
Marcel Reutegger wrote:
Christoph Kiehl wrote:
Well, I would prefer keeping the possible value set of true and
false since the name of the value implies that it is a boolean flag.
What about changing the the behaviour of Jackrabbit. If
forceConsistencyCheck is true a check is run otherwise
[
https://issues.apache.org/jira/browse/JCR-989?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12519626
]
Christoph Kiehl commented on JCR-989:
-
Okay. What to do now? Based on the discussion on the dev list
(http
[
https://issues.apache.org/jira/browse/JCR-1058?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Christoph Kiehl resolved JCR-1058.
--
Resolution: Fixed
Index segment lost after consistency check
[
https://issues.apache.org/jira/browse/JCR-1058?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Christoph Kiehl reopened JCR-1058:
--
Assignee: Christoph Kiehl
Index segment lost after consistency check
Marcel Reutegger wrote:
For now I'm thinking about disabling consistency checks at all by
default and run them in a maintenance window at night. Unfortunately
this might be a bit dangerous if parts of the application rely on
certain nodes to be found by queries :/
WDYT?
I agree with you.
Felix Meschberger wrote:
I favour neither of both :-) I would favor a real node type management
API, which would allow more fine grained control over the node type
registration process (such an API will be coming with JCR 2).
I see ;) I definitely like to see this happening, but this sound
Stefan Guggisberg wrote:
On 8/13/07, Felix Meschberger [EMAIL PROTECTED] wrote:
Hi,
Am Montag, den 13.08.2007, 10:31 +0200 schrieb Christoph Kiehl:
What do you think of option two in my original mail, regardless of when the new
nodetype management API is available?
Honestly, while I agree
Marcel Reutegger (JIRA) wrote:
[
https://issues.apache.org/jira/browse/JCR-1051?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Marcel Reutegger reopened JCR-1051:
---
Assignee: Marcel Reutegger (was: Christoph Kiehl)
We
qcfireball wrote:
Please refer to:
http://www.nabble.com/Reregistering-Node-Types-in-RMI-tf4253117.html
to see how to setup the ability to create new NodeTypes via RMI. Please
post any questions there. Thanks.
Please see my reply on the user list.
Cheers,
Christoph
Hi,
on the user list the question arose whether it is possible to reregister
node types via RMI. Currently JackrabbitNodeTypeManager doesn't expose
NodeTypeManagerImpl.registerNodeTypes(InputStream, String, boolean)
which allows to enable reregistration.
There are two options to implement
Felix Meschberger wrote:
I agree, that the cause must not be lost. But rather than logging the
cause inside loadBundle (in this case), I suggest the
hasNonVirtualItemState method should not ignore the exception and log
it.
IMHO, if an exception is thrown, the same message should not be logged
Christoph Kiehl wrote:
Maybe the following:
private boolean hasNonVirtualItemState(ItemId id) {
[...]
} catch (ItemStateException ise) {
return false;
}
[...]
}
should be rewritten to:
private boolean hasNonVirtualItemState(ItemId id) {
[...]
} catch
Felix Meschberger wrote:
Makes absolute sense, except for throwing the RuntimeException as you
noted in your own follow-up.
And yes, I agree, this would require a big code review. On the other
hand taking the pragmatic approach of fixing those places one after the
other as the issues are
Thomas Mueller wrote:
Exceptions should never be used for orinary control flow (see also
Effective Java page 170). My suggestion would be:
SharedItemStateManager.java,
private boolean hasNonVirtualItemState(ItemId id) throws
ItemStateException {
...
if (id.denotesNode()) {
Jukka Zitting wrote:
To best manage the change I would like to start a separate
jackrabbit-jsr283 component that would contain tentative JCR 2.0
extension interfaces in org.apache.jackrabbit.jsr283. We wouldn't need
to make any backwards compatibility claims for that component, but any
other
Julian Reschke wrote:
Jukka Zitting wrote:
On 8/8/07, Christoph Kiehl [EMAIL PROTECTED] wrote:
Sounds good. We just need to make sure that those jsr283 interfaces
do not
interfere with jsr170 interfaces because some Jackrabbit classes will
need to
implement both interfaces. But since jsr283
[
https://issues.apache.org/jira/browse/JCR-1041?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12518568
]
Christoph Kiehl commented on JCR-1041:
--
Well, according to various sources
(http://martin.nobilitas.com/java
Hi,
while preparing the testcase for JCR-1039 I found a construct like this:
protected synchronized NodePropBundle loadBundle(NodeId id)
throws ItemStateException {
[...]
} catch (Exception e) {
String msg = failed to read bundle: + id + : + e;
log.error(msg);
[
https://issues.apache.org/jira/browse/JCR-1051?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Christoph Kiehl reassigned JCR-1051:
Assignee: Christoph Kiehl
MatchAllScorer calculateDocFilter() bug
[
https://issues.apache.org/jira/browse/JCR-989?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Christoph Kiehl resolved JCR-989.
-
Resolution: Fixed
Fix Version/s: 1.4
committed in revision 563688
Modify
[
https://issues.apache.org/jira/browse/JCR-1039?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Christoph Kiehl updated JCR-1039:
-
Attachment: jackrabbit-core-testcase.patch
This is a patch for jackrabbit-core which includes
[
https://issues.apache.org/jira/browse/JCR-989?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Christoph Kiehl reassigned JCR-989:
---
Assignee: Christoph Kiehl
Modify LazyQueryResultImpl to allow resultFetchSize to be set
[
https://issues.apache.org/jira/browse/JCR-989?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Christoph Kiehl updated JCR-989:
Attachment: jackrabbit-core.patch
jackrabbit-api.patch
I finally made it. Took me
[
https://issues.apache.org/jira/browse/JCR-989?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Christoph Kiehl updated JCR-989:
Attachment: (was: LazyQueryResultImpl.patch)
Modify LazyQueryResultImpl to allow resultFetchSize
Stefan Guggisberg wrote:
we just discovered, that the orderable attribute of node types is not
inherited from supertypes. NodeTypeImpl.hasOrderableChildNodes() just calls
NodeTypeDef.hasOrderableChildNodes() instead of using the EffectiveNodeType to
determine if a node type allows orderable
Hi,
we just discovered, that the orderable attribute of node types is not
inherited from supertypes. NodeTypeImpl.hasOrderableChildNodes() just calls
NodeTypeDef.hasOrderableChildNodes() instead of using the EffectiveNodeType to
determine if a node type allows orderable child nodes.
The
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
[
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
: 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
[
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
Jukka Zitting wrote:
Please welcome Christoph Kiehl as a new committer and PMC member of
the Apache Jackrabbit project. The Jackrabbit PMC recently voted to
grant committership to Christoph and he accepted the nomination. The
related administrational work is also now taken care of.
Christoph
Alexandru Popescu ☀ wrote:
Please welcome Christoph Kiehl as a new committer and PMC member of
the Apache Jackrabbit project. The Jackrabbit PMC recently voted to
grant committership to Christoph and he accepted the nomination. The
related administrational work is also now taken care
bilobag wrote:
javax.jcr.RepositoryException: this session has been closed
Could you please provide the source code of a very simple TestCase that fails
for you? It seems like the session is closed to early (well obviously ;) but
without the source it's very difficult to tell what's going
bilobag wrote:
Ok, i think my issue is that I have the
org.springmodules.jcr.support.OpenSessionInViewFilter configured in my
web.xml which is supposed to keep my repository session open. My dao mainly
just uses the jcrTemplate methods to access the repository. I believe the
template opens
[
https://issues.apache.org/jira/browse/JCR-1006?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12511123
]
Christoph Kiehl commented on JCR-1006:
--
We actually ran into this issue on one of our production system where we
1 - 100 of 191 matches
Mail list logo
