Doug Cutting wrote:
> > Therefore, a "semi compound" segment file can be defined, that would be
> > made of 4 files (instead of 1):
> > - File 0: .fdx .tis .tvx
> > - File 1: .fdt .tii .tvd
> > - File 2: .frq .tvf
> > - File 3: .fnm .prx .fN
>
> I think this is a promising direction. Perhaps inste
Doug Cutting wrote:
> Doug Cutting wrote:
> > Yes. On 32-bit systems with indexes larger than 1GB or so, memory
> > mapping is impractical, so synchronization is required around shared
> > file handles (using Java's classic i/o APIs, w/o pread). The
> > non-compound format, with more files, has f
Hey Garth, that is a perfect moment to join. Well I'm on vacation at
the moment but I will be back in early jannuary. Can you keep your
fingers still until I'm back? I will give you all information you want
/ need. Would that be ok for you? If not there is a lot of stuff to do
with the GData Objec
This is caused by the same java.io.tempdir problem with
TestFieldsReader.testLazyPerformance. I have been working on nighly
builds on lucene.zones (Lucene 708) and I am afraid my testing of the
script is conflicting with Doug's nightly cron job when it comes to
testing.
I think we should
javacc-uptodate-check:
javacc-notice:
[echo]
[echo] One or more of the JavaCC .jj files is newer than its
corresponding
[echo] .java file. Run the "javacc" target to regenerate the
artifacts.
[echo]
init:
clover.setup:
[mkdir] Created dir: /tmp/lucen
javacc-uptodate-check:
javacc-notice:
[echo]
[echo] One or more of the JavaCC .jj files is newer than its
corresponding
[echo] .java file. Run the "javacc" target to regenerate the
artifacts.
[echo]
init:
clover.setup:
clover.info:
[echo]
[ec
Doug Cutting wrote:
Yes. On 32-bit systems with indexes larger than 1GB or so, memory
mapping is impractical, so synchronization is required around shared
file handles (using Java's classic i/o APIs, w/o pread). The
non-compound format, with more files, has fewer synchronization
bottlenecks.
Doug Cutting wrote:
> I'm not yet convinced that the costs of this mid-point justify its
> benefits.
That was too negative. Let me try a more positive angle.
Doron Cohen wrote:
Therefore, a "semi compound" segment file can be defined, that would be
made of 4 files (instead of 1):
- File 0: .fd
[ http://issues.apache.org/jira/browse/LUCENE-744?page=all ]
Grant Ingersoll resolved LUCENE-744.
Resolution: Fixed
OK, per Chris' suggestion, I changed this to use tempDir.
> TestFieldsReader - TestLazyPerformance problems w/ permissions in temp di
[ http://issues.apache.org/jira/browse/LUCENE-721?page=all ]
Grant Ingersoll resolved LUCENE-721.
Resolution: Fixed
Committed the change. Linked to the reports from the Resources -> Developers
page on the documentation. Current report was generate
[ http://issues.apache.org/jira/browse/LUCENE-713?page=all ]
Grant Ingersoll resolved LUCENE-713.
Resolution: Fixed
Put in wording to account for offset and position info in the TVF file.
Changes have been committed and website updated (allow time f
Marvin Humphrey wrote:
Out of curiosity, does the non-compound format yield any search-time
benefits?
Yes. On 32-bit systems with indexes larger than 1GB or so, memory
mapping is impractical, so synchronization is required around shared
file handles (using Java's classic i/o APIs, w/o pread)
On Dec 15, 2006, at 2:04 PM, Otis Gospodnetic wrote:
I think Doron is right on the money here. I know one "customer"
who'd be happy to trade its file descriptors for less IO -
simpy.com. It's exactly what Doron describes - a busy system with
a LOT of indices. File descriptors are kept u
Otis Gospodnetic wrote:
I think Doron is right on the money here. I know one "customer" who'd be happy
to trade its file descriptors for less IO - simpy.com. It's exactly what Doron describes
- a busy system with a LOT of indices. File descriptors are kept under control by
carefully closing
On 12/16/06, Chuck Williams <[EMAIL PROTECTED]> wrote:
Applying the patch moved the issue somewhat, but not materially. The
setup of the FieldCache comparator still takes the same amount of time
and all thread dumps still find the stack inside Object.clone() working
on finalizers.
Oops, I forg
[ http://issues.apache.org/jira/browse/LUCENE-750?page=all ]
Yonik Seeley updated LUCENE-750:
Attachment: IndexInput_finalizer.patch
Forgot to remove the finalizer from FSIndexInput in the first patch.
Note that I also removed the finalizer from FSIndexO
On Dec 16, 2006, at 3:44 AM, Chris Hostetter wrote:
: what they were). Solr had cross-site scripting issues in its JSP
: pages, which I think are now all fixed (?).
SOLR-74, just resolved.
I don't know if i'd really call them XSS issues: they are on the admin
pages; if a malicious user has ac
I can basically GUARANTEE that unless you are using large indexes and
loading into a RamDirectory (and use Java prior to 1.5) , that there
is NO ISSUE in using a ThreadLocal,
There is something else wrong in your application.
PLEASE get a good profiler and perform the required testing. It is
Chuck,
On Saturday 16 December 2006 09:06, Chuck Williams wrote:
> ...
> I can see reading 1 million terms and building the comparator taking a
> while, although not the 15-20 minutes it does, and am baffled at how
> every thread dump on many trials of this issue end up with every one
> inside th
: what they were). Solr had cross-site scripting issues in its JSP
: pages, which I think are now all fixed (?).
SOLR-74, just resolved.
I don't know if i'd really call them XSS issues: they are on the admin
pages; if a malicious user has access to them, you've got bigger problems
then them try
The problem appears to be this. We have an approximately 1 million item
index. It uses 6 parallel subindexes with ParallelReader, so each of
these subindexes has 1 million items. Each subindex has the same
segment structure, with 15 segments in each at the moment.
I mentioned before that the is
21 matches
Mail list logo
