On Sat, Jul 3, 2010 at 1:10 PM, Lance Norskog wrote:
> You don't need to optimize, only commit.
OK, thanks for the tip, Lance. I thought the "too many open files"
problem was because I wasn't optimizing/merging frequently enough. My
understanding of your suggestion is that commit also does merg
nd serious problems can't be
differentiated at the client level from non-serious problems (eg tika
exceptions thrown by bad documents).
On Wed, Jun 9, 2010 at 10:13 AM, Jim Blomo wrote:
> In any case I bumped up the heap to 3G as suggested, which has helped
> stability. I have found that
On Fri, Jun 4, 2010 at 3:14 PM, Chris Hostetter
wrote:
> : That is still really small for 5MB documents. I think the default solr
> : document cache is 512 items, so you would need at least 3 GB of memory
> : if you didn't change that and the cache filled up.
>
> that assumes that the extracted te
On Thu, Jun 3, 2010 at 11:17 AM, Nagelberg, Kallin
wrote:
> How much memory have you given tomcat? The default is 64M which is going to
> be really small for 5MB documents.
-Xmx128M - my understanding is that this bumps heap size to 128M.
What is a reasonable size? Are there other memory flags
I am new to debugging Java services, so I'm wondering what the best
practices are for debugging solr on tomcat. I'm running into a few
issues while building up my index, using the ExtractingRequestHandler
to format the data from my sources. I can read through the catalina
log, but this seems to j
On Tue, May 18, 2010 at 12:31 PM, Sixten Otto wrote:
> So features are being actively added to / code rearranged in
> trunk/4.0, with some of the work being back-ported to this branch to
> form a stable 3.1 release? Is that accurate?
>
> Is there any thinking about when that might drop (beyond the
