subQueries.get(i).close() is nothing but pulling the refrence from the
vector and closing it. So yes. it wouldnt throw exception.
vector<LocalSolrQueryRequests> subQueries
Please let me know if you need any more information
On Fri, Jul 27, 2012 at 10:14 PM, Karthick Duraisamy Soundararaj <
karthick.soundara...@gmail.com> wrote:
> 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
>>>
>>
>>
>>
>>
>>
>
>
>
