: 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
inst a server that isn't processing any
> queries -- one from when hte server first starts up, and one from when hte
> server crashes from an OOM (there's a JVM option for generating heap dumps
> on OOM that i can't think of off hte top of my head)
>
>
>
> -Hoss
>
>
>
--
View this message in context:
http://old.nabble.com/Plugin-Performance-Issues-tp24295010p26201123.html
Sent from the Solr - User mailing list archive at Nabble.com.
:
:
:
:
:
:
:
:
...
: 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.
.
mbed your custom handler directly into the solr.war ("The
>>> Old Way"
>>> on the SolrPlugins wiki) ... if you still have problems, then the
>>> cause
>>> isn't the plugin classloader.
>>>
>>>
>>>
>>>
>>>
>>> -Hoss
>>>
>>>
>>>
>>
>> --
>> View this message in context:
>> http://www.nabble.com/Plugin-Performance-Issues-tp24295010p26101741.html
>> Sent from the Solr - User mailing list archive at Nabble.com.
>>
>
> --
> Grant Ingersoll
> http://www.lucidimagination.com/
>
> Search the Lucene ecosystem (Lucene/Solr/Nutch/Mahout/Tika/Droids)
> using Solr/Lucene:
> http://www.lucidimagination.com/search
>
>
>
--
View this message in context:
http://www.nabble.com/Plugin-Performance-Issues-tp24295010p26118673.html
Sent from the Solr - User mailing list archive at Nabble.com.
ause
isn't the plugin classloader.
-Hoss
--
View this message in context:
http://www.nabble.com/Plugin-Performance-Issues-tp24295010p26101741.html
Sent from the Solr - User mailing list archive at Nabble.com.
--
Grant Ingersoll
http://www.lucidimaginati
king up all that ram.
>
> Alternately: a quick way to rule out the special plugin class loader would
> be to embed your custom handler directly into the solr.war ("The Old Way"
> on the SolrPlugins wiki) ... if you still have problems, then the cause
> isn&
: 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
>
gt;
> - Original Message
>> From: CameronL
>> To: solr-user@lucene.apache.org
>> Sent: Wednesday, July 1, 2009 2:37:40 PM
>> Subject: Plugin Performance Issues
>>
>>
>> We recently created a custom class for our spellchecking implementation
>>
- Original Message
> From: CameronL
> To: solr-user@lucene.apache.org
> Sent: Wednesday, July 1, 2009 2:37:40 PM
> Subject: Plugin Performance Issues
>
>
> We recently created a custom class for our spellchecking implementation in
> Solr. We decided to inclu
ndering if this is perhaps a side-effect
of using plugins in general, perhaps something going on with the custom
class loading of Solr.
We're using Tomcat 6 and Solr 1.3 by the way.
--
View this message in context:
http://www.nabble.com/Plugin-Performance-Issues-tp24295010p24295010.html
Sent
11 matches
Mail list logo
