Hi Erick > You're probably on your own here. I'd be surprised if people were willing to work on code of that vintage. Yes, this is not a vintage wine!
I just hoped someone would say, "ah, we had this issue before and..." :-) I think best is to just upgrade like you suggested. Thanks for your time Ericz On Sun, Oct 28, 2012 at 6:34 PM, Erick Erickson <erickerick...@gmail.com>wrote: > Oh, 1.4.1. You're probably on your own here. I'd be surprised if > people were willing to work on code of that vintage. Are > you sure you can't upgrade at least to 3.6? > > Best > Erick > > On Sun, Oct 28, 2012 at 12:43 PM, Eric Grobler > <impalah...@googlemail.com> wrote: > > Hi Erick, > > > > It is Solr 1.41 (a Drupal installation) running on Jetty. > > How can one get a stack trace? (there is no exception/error) > > > > Could it be that solr does something like this? > > start delete job > > cannot find bogus id to delete > > does some reindex or optimization anyway regardless which takes 80 > > seconds > > end delete job > > > > Anyway, does it sound like Solr is just waiting 80 seconds for some > > exclusive lock or is it actually doing something in a background > thread?. I > > do not know what kind of calls drupal is doing. > > > > Thanks & Regards > > Ericz > > > > > > > > > > On Sun, Oct 28, 2012 at 3:08 PM, Erick Erickson <erickerick...@gmail.com > >wrote: > > > >> That is very weird. What version of Solr are you using, and is there > >> any way you could get a stack trace when this is happening? > >> > >> Best > >> Erick > >> > >> On Sun, Oct 28, 2012 at 6:22 AM, Eric Grobler < > impalah...@googlemail.com> > >> wrote: > >> > Hi > >> > > >> > I am a bit confused why the server sometimes takes 80 seconds to > respond > >> > when I specify an id to delete than does not even exist in the index. > >> > > >> > If I loop this query and send a bogus id to delete every minute. > >> > 03:27:38 125 ms <delete><id>bogusidthatdoesnotexist</id></delete> > >> commit > >> > 03:28:38 125 ms <delete><id>bogusidthatdoesnotexist</id></delete> > >> commit > >> > 03:29:38 69125 ms <delete><id>bogusidthatdoesnotexist</id></delete> > >> commit > >> > 03:30:38 124 ms <delete><id>bogusidthatdoesnotexist</id></delete> > >> commit > >> > 03:31:38 84141 ms <delete><id>bogusidthatdoesnotexist</id></delete> > >> commit > >> > 03:33:38 125 ms <delete><id>bogusidthatdoesnotexist</id></delete> > >> commit > >> > 03:34:38 141 ms <delete><id>bogusidthatdoesnotexist</id></delete> > >> commit > >> > 03:35:43 55476 ms <delete><id>bogusidthatdoesnotexist</id></delete> > >> commit > >> > 03:36:38 141 ms <delete><id>bogusidthatdoesnotexist</id></delete> > >> commit > >> > This was at 3am and the server only has about 200,000 documents and is > >> not > >> > busy, average query time is a constant < 5ms. > >> > > >> > If the server takes 80 seconds when it needs to update the index I > would > >> > understand it. > >> > *But in this case the id does not exists, so the server should just > >> return > >> > immediately?* > >> > I then must assume that the delete command must be in some low > priority > >> > queue and waits for some exclusive lock? > >> > When I look at the stats it seems that it was only my loop that did > >> > cumulative_deletesById every minute. > >> > > >> > What settings in the solrconfig.xml would effect this behaviour? > >> > > >> > Thank you & Regards > >> > Ericz > >> >
