Thank you! I will look into that and give it a try. I also am going to look at the cache overall and try to tune it for the faceting we’re doing.
Ronald S. Wood | Senior Software Developer 857-991-7681 (mobile) Smarsh 100 Franklin St. Suite 903 | Boston, MA 02210 1-866-SMARSH-1 | 971-998-9967 (fax) www.smarsh.com <http://www.smarsh.com/> Immediate customer support: Call 1-866-762-7741 (x2) or visit www.smarsh.com/support <http://www.smarsh.com/support> On 7/3/15, 1:42 AM, "Shalin Shekhar Mangar" <shalinman...@gmail.com> wrote: >On Fri, Jul 3, 2015 at 1:06 AM, Ronald Wood <rw...@smarsh.com> wrote: >> >> >> I had initially suspect that distributed searches combined with faceting >> might be part of the issue, since I had seen some long-running threads that >> seemed to spend a long time in the FastLRUCache when getting facets for a >> single field. However, in the latest case of blocked queries, I am not >> seeing that. > >That happens because by default the FastLRUCache will steal the >request thread to perform clean up when the number of items exceed a >certain limit. You can avoid this by using cleanupThread="true" as an >attribute in the cache's configuration. That will spawn a new thread >to clean up if and when required so that request threads aren't >blocked for a long time. > >> >> We have two slaves that replicate from a master, and we were saw the issue >> recur after a while of client usage, ruling out a hardware issue. >> >> Does anyone have any suggestions for potential avenues of attack for getting >> to the bottom of this? Or are there any known issues that could be >> implicated in this? >> >> - Ronald S. Wood > > > >-- >Regards, >Shalin Shekhar Mangar.
