SimpleOrderedMap<Object> commonRequestParams; //This holds the common
request params.
Vector<SimpleOrderedMap<Object>> subQueryRequestParams;  // This holds the
request params of sub Queries

I use the above to create multiple localQueryRequests. To add a little more
information, I create new ResponseBuilder for each request

I also hold a reference to query component as a private member in my
CustomHandler. Considering that the component is initialized only once
during the start up, I assume this isnt a cause of concernt.

On Fri, Jul 27, 2012 at 9:49 PM, Karthick Duraisamy Soundararaj <
karthick.soundara...@gmail.com> wrote:

> First no. Because i do the following
>             for(i=0;i<subqueries.size();i++) {
>                       subQueries.get(i).close();
>             }
>
> Second, I dont see any exception until the first searcher leak happens.
>
>
> On Fri, Jul 27, 2012 at 9:04 PM, Lance Norskog <goks...@gmail.com> wrote:
>
>> A finally clause can throw exceptions. Can this throw an exception?
>>  subQueries.get(i).close();
>>
>>  If so, each close() call should be in a try-catch block.
>>
>> On Fri, Jul 27, 2012 at 5:28 PM, Karthick Duraisamy Soundararaj
>> <karthick.soundara...@gmail.com> wrote:
>> > Hello all,
>> >             While running in my eclipse and run a set of queries, this
>> > works fine, but when I run it in test production server, the searchers
>> are
>> > leaked. Any hint would be appreciated. I have not used CoreContainer.
>> >
>> > Considering that the SearchHandler is running fine, I am not able to
>> think
>> > of a reason why my extended version wouldnt work.. Does anyone have any
>> > idea?
>> >
>> > On Fri, Jul 27, 2012 at 10:19 AM, Karthick Duraisamy Soundararaj <
>> > karthick.soundara...@gmail.com> wrote:
>> >
>> >> I have tons of these open.
>> >> searcherName : Searcher@24be0446 main
>> >> caching : true
>> >> numDocs : 1331167
>> >> maxDoc : 1338549
>> >> reader :
>> SolrIndexReader{this=5585c0de,r=ReadOnlyDirectoryReader@5585c0de
>> >> ,refCnt=1,segments=18}
>> >> readerDir : org.apache.lucene.store.NIOFSDirectory@
>> >> /usr/local/solr/highlander/data/......@2f2d9d89
>> >> indexVersion : 1336499508709
>> >> openedAt : Fri Jul 27 09:45:16 EDT 2012
>> >> registeredAt : Fri Jul 27 09:45:19 EDT 2012
>> >> warmupTime : 0
>> >>
>> >> In my custom handler, I have the following code
>> >> I have the following problem
>> >> Although in my custom handler, I have the following implementation(its
>> not
>> >> the full code but it gives an overall idea of the implementation) and
>> it
>> >>
>> >>       class CustomHandler extends SearchHandler {
>> >>
>> >>             void handleRequestBody(SolrQueryRequest
>> req,SolrQueryResponse
>> >> rsp)
>> >>
>> >>                          SolrCore core= req.getCore();
>> >>                          vector<SimpleOrderedMap<Object>>
>> requestParams =
>> >> new   vector<SimpleOrderedMap<Object>>();
>> >>                         /*parse the params such a way that
>> >>                                  requestParams[i] -=> parameter of the
>> ith
>> >> request
>> >>                           */
>> >>                         ......
>> >>
>> >>                   try {
>> >>                        vector<LocalSolrQueryRequests> subQueries = new
>> >>  vector<LocalSolrQueryRequests>(solrcore, requestParams[i]);
>> >>
>> >>                        for(i=0;i<subQueryCount;i++) {
>> >>                               ResponseBuilder rb = new
>> ResponseBuilder()
>> >>                               rb.req = req;
>> >>                                ....
>> >>                               handlerRequestBody(req,rsp,rb); //this
>> would
>> >> call search handler's handler request body, whose signature, i have
>> modified
>> >>                      }
>> >>                  } finally {
>> >>                           for(i=0; i<subQueries.size();i++)
>> >>                                  subQueries.get(i).close();
>> >>                  }
>> >>       }
>> >>
>> >> *Search Handler Changes*
>> >>       class SearchHandler {
>> >>             void handleRequestBody(SolrQueryRequest req,
>> SolrQueryResponse
>> >> rsp, ResponseBuilder rb, ArrayList<Component> comps) {
>> >>                //  ResponseBuilder rb = new ResponseBuilder()  ;
>> >>
>> >>                            ......................
>> >>              }
>> >>             void handleRequestBody(SolrQueryRequest req,
>> >> SolrQueryResponse) {
>> >>                      ResponseBuilder rb = new ResponseBuilder(req,rsp,
>> new
>> >> ResponseBuilder());
>> >>                      handleRequestBody(req, rsp, rb, comps) ;
>> >>              }
>> >>       }
>> >>
>> >>
>> >> I don see the index old index searcher geting closed after warming up
>> the
>> >> new guy... Because I replicate every 5 mintues, it crashes in 2 hours..
>> >>
>> >>  On Fri, Jul 27, 2012 at 3:36 AM, roz dev <rozde...@gmail.com> wrote:
>> >>
>> >>> in my case, I see only 1 searcher, no field cache - still Old Gen is
>> >>> almost
>> >>> full at 22 GB
>> >>>
>> >>> Does it have to do with index or some other configuration
>> >>>
>> >>> -Saroj
>> >>>
>> >>> On Thu, Jul 26, 2012 at 7:41 PM, Lance Norskog <goks...@gmail.com>
>> wrote:
>> >>>
>> >>> > What does the "Statistics" page in the Solr admin say? There might
>> be
>> >>> > several "searchers" open: org.apache.solr.search.SolrIndexSearcher
>> >>> >
>> >>> > Each searcher holds open different generations of the index. If
>> >>> > obsolete index files are held open, it may be old searchers. How big
>> >>> > are the caches? How long does it take to autowarm them?
>> >>> >
>> >>> > On Thu, Jul 26, 2012 at 6:15 PM, Karthick Duraisamy Soundararaj
>> >>> > <karthick.soundara...@gmail.com> wrote:
>> >>> > > Mark,
>> >>> > >         We use solr 3.6.0 on freebsd 9. Over a period of time, it
>> >>> > > accumulates lots of space!
>> >>> > >
>> >>> > > On Thu, Jul 26, 2012 at 8:47 PM, roz dev <rozde...@gmail.com>
>> wrote:
>> >>> > >
>> >>> > >> Thanks Mark.
>> >>> > >>
>> >>> > >> We are never calling commit or optimize with openSearcher=false.
>> >>> > >>
>> >>> > >> As per logs, this is what is happening
>> >>> > >>
>> >>> > >>
>> >>> >
>> >>>
>> openSearcher=true,waitSearcher=true,expungeDeletes=false,softCommit=false}
>> >>> > >>
>> >>> > >> --
>> >>> > >> But, We are going to use 4.0 Alpha and see if that helps.
>> >>> > >>
>> >>> > >> -Saroj
>> >>> > >>
>> >>> > >>
>> >>> > >>
>> >>> > >>
>> >>> > >>
>> >>> > >>
>> >>> > >>
>> >>> > >>
>> >>> > >>
>> >>> > >>
>> >>> > >> On Thu, Jul 26, 2012 at 5:12 PM, Mark Miller <
>> markrmil...@gmail.com>
>> >>> > >> wrote:
>> >>> > >>
>> >>> > >> > I'd take a look at this issue:
>> >>> > >> > https://issues.apache.org/jira/browse/SOLR-3392
>> >>> > >> >
>> >>> > >> > Fixed late April.
>> >>> > >> >
>> >>> > >> > On Jul 26, 2012, at 7:41 PM, roz dev <rozde...@gmail.com>
>> wrote:
>> >>> > >> >
>> >>> > >> > > it was from 4/11/12
>> >>> > >> > >
>> >>> > >> > > -Saroj
>> >>> > >> > >
>> >>> > >> > > On Thu, Jul 26, 2012 at 4:21 PM, Mark Miller <
>> >>> markrmil...@gmail.com
>> >>> > >
>> >>> > >> > wrote:
>> >>> > >> > >
>> >>> > >> > >>
>> >>> > >> > >> On Jul 26, 2012, at 3:18 PM, roz dev <rozde...@gmail.com>
>> >>> wrote:
>> >>> > >> > >>
>> >>> > >> > >>> Hi Guys
>> >>> > >> > >>>
>> >>> > >> > >>> I am also seeing this problem.
>> >>> > >> > >>>
>> >>> > >> > >>> I am using SOLR 4 from Trunk and seeing this issue repeat
>> every
>> >>> > day.
>> >>> > >> > >>>
>> >>> > >> > >>> Any inputs about how to resolve this would be great
>> >>> > >> > >>>
>> >>> > >> > >>> -Saroj
>> >>> > >> > >>
>> >>> > >> > >>
>> >>> > >> > >> Trunk from what date?
>> >>> > >> > >>
>> >>> > >> > >> - Mark
>> >>> > >> > >>
>> >>> > >> > >>
>> >>> > >> > >>
>> >>> > >> > >>
>> >>> > >> > >>
>> >>> > >> > >>
>> >>> > >> > >>
>> >>> > >> > >>
>> >>> > >> > >>
>> >>> > >> > >>
>> >>> > >> >
>> >>> > >> > - Mark Miller
>> >>> > >> > lucidimagination.com
>> >>> > >> >
>> >>> > >> >
>> >>> > >> >
>> >>> > >> >
>> >>> > >> >
>> >>> > >> >
>> >>> > >> >
>> >>> > >> >
>> >>> > >> >
>> >>> > >> >
>> >>> > >> >
>> >>> > >> >
>> >>> > >>
>> >>> >
>> >>> >
>> >>> >
>> >>> > --
>> >>> > Lance Norskog
>> >>> > goks...@gmail.com
>> >>> >
>> >>>
>> >>
>> >>
>> >>
>> >>
>>
>>
>>
>> --
>> Lance Norskog
>> goks...@gmail.com
>>
>
>
>
>
>

Reply via email to