updated index on search page

[Chetan Sahasrabudhe <Ch...@KPITCummins.com>]

Hello,
 
    Through background processing a batch job is updating nutch index.
When the user is searching for pages, the position of the link need to change as per the changes updated in nutch index.
 
When I restart my tomcat instance the changes are immd. visible, but when the tomcat is running, changes are not reflected in search results.
 
I tried changing, 
 
<property>
  <name>searcher.filter.cache.size</name>
  <value>16</value>
  <description>
  Maximum number of filters to cache.  Filters can accelerate certain
  field-based queries, like language, document format, etc.  Each
  filter requires one bit of RAM per page.  So, with a 10 million page
  index, a cache size of 16 consumes two bytes per page, or 20MB.
  </description>
</property>
 
value 16 is changed to 0 hoping that nutch web app will not take the filters from cache but will fire query to index.
is there any possiblity of solving this problem ?

Regards 
Chetan 
_______________________________ 

Tel +91-20-5652 5000 ext 2513

KPITCummins Infosystems Limited 
Hinjwadi
Pune INDIA 
_______________________________ 

 


---------------------------------
This message contains the information that may be privileged and is  the property of the KPIT Cummins Infosystems LTD.It is intended only for the person to whom it is addressed. If you are not intended recipient, you are not authorized to read, print , retain copy, disseminate, distribute, or use this message or any part thereof. If you receive this message in error, please notify the sender immediately and delete all copies of this message. KPIT Cummins does not accept any liability for virus infected mails.

Re: [Nutch-general] updated index on search page

["Peter A. Daly" <pe...@gmail.com>]

Right now (or last I knew), the web application needs to be reloaded
for changes to show up.  This is because the NutchBean is stored as an
Application Object that never is checked to see if it is stale.

The way I handle this, although I use Resin instead of Tomcat, is to
"touch" the web.xml file after an index completes.  In Resin, this
triggers an application reload...I don't know if it'll do the same in
Tomcat.

You need to figure out the best and non-intrusive way to restart the
webapp.  That's how I do it.

-Pete

On 5/11/05, Chetan Sahasrabudhe <Ch...@kpitcummins.com> wrote:
> Hello,
> 
>     Through background processing a batch job is updating nutch index.
> When the user is searching for pages, the position of the link need to change as per the changes updated in nutch index.
> 
> When I restart my tomcat instance the changes are immd. visible, but when the tomcat is running, changes are not reflected in search results.
> 
> I tried changing,
> 
> <property>
>   <name>searcher.filter.cache.size</name>
>   <value>16</value>
>   <description>
>   Maximum number of filters to cache.  Filters can accelerate certain
>   field-based queries, like language, document format, etc.  Each
>   filter requires one bit of RAM per page.  So, with a 10 million page
>   index, a cache size of 16 consumes two bytes per page, or 20MB.
>   </description>
> </property>
> 
> value 16 is changed to 0 hoping that nutch web app will not take the filters from cache but will fire query to index.
> is there any possiblity of solving this problem ?
> 
> Regards
> Chetan
> _______________________________
> 
> Tel +91-20-5652 5000 ext 2513
> 
> KPITCummins Infosystems Limited
> Hinjwadi
> Pune INDIA
> _______________________________
> 
> ---------------------------------
> This message contains the information that may be privileged and is  the property of the KPIT Cummins Infosystems LTD.It is intended only for the person to whom it is addressed. If you are not intended recipient, you are not authorized to read, print , retain copy, disseminate, distribute, or use this message or any part thereof. If you receive this message in error, please notify the sender immediately and delete all copies of this message. KPIT Cummins does not accept any liability for virus infected mails.
> 
>