[
https://issues.apache.org/jira/browse/JCR-788?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
David Johnson updated JCR-788:
--
Attachment: patch.txt
Patch file for upgrade to Lucene 2.1.0
> Upgrade to Lucene
[
https://issues.apache.org/jira/browse/JCR-788?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12484230
]
David Johnson commented on JCR-788:
---
I have upgraded my local version to Lucene 2.1
I needed to change 2 files - the
Anything look strange in the stack traces from my last post on this thread?
Or does this all look 'normal'
-Dave
On 3/14/07, David Johnson <[EMAIL PROTECTED]> wrote:
I have 5-7 stack dumps from 2 different runs that I captured using jstack.
Here is an interesting (in that the
I have 5-7 stack dumps from 2 different runs that I captured using jstack.
Here is an interesting (in that there are 2 blocked threads) example - I
have many more, and can create many more as needed - I was running a 4
thread test corresponding to the # of cores on my system. I ran another
test
Both of these proposals sound great - particularly the additional caching in
DescendantSelfAxisQuery. I think this would address the scenario that I
suggested additional indexing earlier in this thread. As I mentioned, in my
query test set DescendantSelfAxisQuery.DescendantSelfAxisScorer.next()
Do you have a patch for the file, I would love to check it out and run it
against my query suite.
-Dave
On 3/13/07, Christoph Kiehl <[EMAIL PROTECTED]> wrote:
Christoph Kiehl wrote:
> I was digging a bit into Jackrabbit today and found another place where
> some caching did provide a substant
self: is '~350ms' per query fast enough for my
application? how do my queries look like? can i optimize on the query
or data structure?
regards, toby
On 3/12/07, David Johnson <[EMAIL PROTECTED]> wrote:
> This is related to two ongoing list threads - one on synchronization and
th
gt; lot of info in a path that is relevant to a query - given that we have
gone
> ahead and nicely partitioned our content !).
>
> On 3/13/07, David Johnson <[EMAIL PROTECTED]> wrote:
>>
>> As another example, for each node, perhaps every potential parent path
>> could
wrote:
David Johnson wrote:
> This is related to two ongoing list threads - one on synchronization and
> the
> other on query performance.
>
> As I have mentioned in previous posts, I have been running a variety of
> query tests. I am using a suite of 100 queries and running them
entials credJBoss = new SimpleCredentials("username",
"password"
.toCharArray());
return repository.login(credJBoss);
} catch (NamingException ex) {
ex.printStackTrace();
}
return null;
}
}
On 3/13/07, Marce
ady in the code. Is ChildAxisQuery and
DescendantSelfAxisQuery currently used for cases like this?
-Dave
On 3/12/07, Marcel Reutegger <[EMAIL PROTECTED]> wrote:
David Johnson wrote:
> I think I was again focusing on range queries and giving Lucene some way
of
> filtering out subsets o
This is related to two ongoing list threads - one on synchronization and the
other on query performance.
As I have mentioned in previous posts, I have been running a variety of
query tests. I am using a suite of 100 queries and running them against
Jackrabbit in several different threading scena
Issue Type: Bug
Components: core
Affects Versions: 1.2.3
Reporter: David Johnson
Priority: Minor
As briefly mentioned in the dev email list, improperly implemented (i.e.,
missing - using the default Object implementation) equals and hashcode in
Done:
https://issues.apache.org/jira/browse/JCR-787
I did file it as a bug - as it really is an incorrect implementation (i.e.,
missing implementation) of equals and hashcode.
-Dave
On 3/12/07, Jukka Zitting <[EMAIL PROTECTED]> wrote:
Hi,
On 3/10/07, David Johnson <[EMAIL PROTECTE
On 3/9/07, David Johnson <[EMAIL PROTECTED]> wrote:
-- snip --
yes, this should ensure that caching in lucene is used wherever possible.
> Even
> though there might be bugs that prevent this. Just like this one:
>
> http://svn.apache.org/viewvc?view=rev&revision=506908
&
Will making an associated JIRA issue speed the inclusion of the change?
From my understanding it is fixing a real bug. I can create an issue if
that will bring it into a release faster.
-Dave
On 3/9/07, Jukka Zitting <[EMAIL PROTECTED]> wrote:
Hi,
On 3/9/07, David Johnson &
-- snip --
yes, this should ensure that caching in lucene is used wherever possible.
Even
though there might be bugs that prevent this. Just like this one:
http://svn.apache.org/viewvc?view=rev&revision=506908
which prevented the re-use of SharedFiledSortComparator even if nothing
changed
betw
On 3/6/07, Marcel Reutegger <[EMAIL PROTECTED]> wrote:
Hi David,
David Johnson wrote:
> Yes, I am using Jackrabbit 1.2.x and I am not seeing that dramatic of a
> difference between 1.1.x and the 1.2.x, although I have not done a
direct
> comparison between the two with the s
- and "safe" ways to modify it i.e., I would rather only
modify the Query Syntax Tree and continue to use the LuceneQueryBuilder for
most of the query processing - would be appreciated.
-Dave
On 3/2/07, Jukka Zitting <[EMAIL PROTECTED]> wrote:
Hi,,
On 2/28/07, David
Christoph Kiehl <[EMAIL PROTECTED]> wrote:
David Johnson wrote:
> Digging into the internals of Jackrabbit, we have noticed that there is
an
> implementation of RangeQuery that essentially walks the results if the #
of
> query terms is greater than what Lucene can handle. Reading t
We are exploring using Jackrabbit in a production environment. I have a
repository that we have created from our content that has > 100K nodes.
Several of our use case need to use date range queries and also use 'order
by' frequently. We have noticed that the query time is significantly slower
t
Components: rmi
Affects Versions: 1.2.1
Reporter: David Johnson
Priority: Minor
The file jackrabbit-rmi-service.xml is missing from the
jackrabbit-jcr-rmi-1.2.1.jar.
The cause of the issue appears that the directory structure of the
jackrabbit-jcr-rmi sub
This thread originally intended for the developer list - sorry.
-Dave
-- Forwarded message --
From: David Johnson <[EMAIL PROTECTED]>
Date: Jan 19, 2007 12:23 PM
Subject: Re: jackrabbit-jcr-rmi-1.2.1.jar missing jackrabbit-rmi-service.xml
?
To: users@jackrabbit.apache.or
Thanks,
Looks good.
-Dave
On 1/19/07, Jukka Zitting <[EMAIL PROTECTED]> wrote:
Hi,
On 1/19/07, Jukka Zitting <[EMAIL PROTECTED]> wrote:
> I'm planning to make a 1.2.2 patch release already in a few weeks with
> this and a couple other lower priority fixes. See
>
https://issues.apache.org/jir
Did this make it into the 1.2.1 release? Or since it was committed to the
trunk will it have to wait for the 1.3 version?
-Dave
On 1/18/07, Stefan Guggisberg <[EMAIL PROTECTED]> wrote:
On 1/18/07, Olivier Dony <[EMAIL PROTECTED]> wrote:
> On Jan 17, 2007, at 6:19 PM, Stefan Guggisberg wrote:
My initial tests also work with our repository. This was a JCA repository
running in JBoss with a MySQL datasource. I upgraded to the 1.2 branch,
without deleting the index directories (i.e., using the 1.1.1 index). I
plan on deleting the 1.1.1 index directories and testing again.
-Dave
On 1/
26 matches
Mail list logo
