: the thing though: We had one field defined using this fieldtype and we
: deployed the new schema to solr when we started seeing the issue. However,
: we had not yet released our code that was using the new field (obviously we
: have to make the change on the solr end before the code, so we
: as
Interesting...I guess I had logically assumed that having type="index" meant
it wasn't used for query time, but I see why that's not possible. Here's
the thing though: We had one field defined using this fieldtype and we
deployed the new schema to solr when we started seeing the issue. However,
:
:
:
:
:
:
:
:
...
: only do indexing on the master server. However, with this schema in place
: on the slaves, as well as our custom.jar in the solrHome/lib directory, we
: run into these issues where the memory usage grows and grows without
: explanation.
.
Here is where our custom class is referenced in the schema:
As you can see, we built our own field type to be used at index time to
essentially act as a sort of KeywordTokenizer, but removing stopwords. We
share a schema.xml for both master and slave servers for conv
I would guess that your code is being used. I'm not sure what you
mean by it "was only referenced in the schema". That implies usage to
me. Is it a new field type? What is your plugin doing?
Have you tried setting breakpoints at method entry points in your
plugin and starting up Solr w/
This is an issue we experienced a while back. We once again tried to load a
custom class as a plugin jar from the lib directory and began experiencing
severe memory problems again. The code in our jar wasn't being used at
all...the class was only referenced in the schema. I find it strange that
: I'm not entirely convinced that it's related to our code, but it could be.
: Just trying to get a sense if other plugins have had similar problems, just
: by the nature of using Solr's resource loading from the /lib directory.
Plugins aren't something that every Solr users -- but enough people
hem and sort by them, or round those dates up.
Otis
--
Sematext -- http://sematext.com/ -- Lucene - Solr - Nutch
- Original Message
> From: CameronL
> To: solr-user@lucene.apache.org
> Sent: Wednesday, July 1, 2009 4:43:11 PM
> Subject: Re: Plugin Performance Issues
>
Our max heap was configured to use 5GB. It has been running fine until we
tried to deploy a new queryConverter for our SpellcheckComponent. After
which, we upped our heap to 8GB and still had issues.
Solr is the only webapp running on Tomcat.
We are using sorting and faceting, but again, hadn'
Hi,
Could it simply be the case that you really do need all that memory that the
JVM start consuming with time? How large of a heap are you using, is Solr the
only webapp in your TOmcat, and are you using sorting or faceting?
Otis
--
Sematext -- http://sematext.com/ -- Lucene - Solr - Nutch
10 matches
Mail list logo
