Hello Team, Can anyone throw some light on optimizing the Solr search configuration in our application. Please find the details below.
We have used the Apache SOLR search API in our restful webservices. We came across couple of incidents in our production environment where in the SOLR search query is taking more time. Could you please help us in optimizing the query execution time. Thanks In Advance. Regards Muzeeb On Fri, Jun 27, 2014 at 6:01 PM, Dawid Weiss (JIRA) <[email protected]> wrote: > > [ > https://issues.apache.org/jira/browse/SOLR-6204?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14045901#comment-14045901 > ] > > Dawid Weiss commented on SOLR-6204: > ----------------------------------- > > No problem, Uwe. Thanks. > > > The question on the patch: It patches the "solaris" part... Why? > > Because this particular file is part of BSD's compilation tree -- it takes > sources from openjdk's Solaris variant. I didn't dig deeply on this. I > would also try to confirm what's happening to the "dying" threads on > jenkins -- the socket hang is one issue, the killed threads are another -- > so you don't have to update immediately. I'm waiting for another job to > hang to then diagnose debug logs. > > > FreeBSD does not break out of ServerSocketChannel.accept() > > ---------------------------------------------------------- > > > > Key: SOLR-6204 > > URL: https://issues.apache.org/jira/browse/SOLR-6204 > > Project: Solr > > Issue Type: Bug > > Reporter: Dawid Weiss > > Assignee: Dawid Weiss > > > > This may be the reason why tests behave as crazy as they do on FreeBSD > (lucene jenkins). Here's the story. > > I looked at Solr logs and saw this: > > {code} > > 2> 1012153 T10 oejut.QueuedThreadPool.doStop WARN 4 threads could not > be stopped > > {code} > > just before failures related to "socket/ port already bound" in > SSLMigrationTest. QueuedThreadPool in jetty attempts to wait for pool > threads, then terminates them (and waits again). This wait time is > configurable, alas broken in Solr's code in JettySolrRunner: > > {code} > > private void init(String solrHome, String context, int port, boolean > stopAtShutdown) { > > ... > > if (threadPool != null) { > > threadPool.setMaxThreads(10000); > > threadPool.setMaxIdleTimeMs(5000); > > threadPool.setMaxStopTimeMs(30000); > > } > > {code} > > The threadPool variable here is always null because it gets assigned > after jetty starts and the configuration block is executed before it. the > threadPool != null condition is never true and the code that configures > those timeouts is dead. > > That's not a biggie, I fixed it. The problem remains, however -- even > with a long wait time, the threads in accept() call are not interrupted. I > wrote a small test class: > > {code} > > import java.net.InetSocketAddress; > > import java.nio.channels.ServerSocketChannel; > > public class Foo { > > public static void main(String[] args) throws Exception { > > final ServerSocketChannel ssc = ServerSocketChannel.open(); > > ssc.configureBlocking(true); > > ssc.socket().setReuseAddress(true); > > ssc.socket().bind(new InetSocketAddress(0), 20); > > System.out.println("Port: " + ssc.socket().getLocalPort()); > > Thread t = new Thread() { > > @Override > > public void run() { > > try { > > System.out.println("Thread accept();"); > > ssc.accept().close(); > > System.out.println("Done?"); > > } catch (Exception e) { > > System.out.println("Thread ex: " + e); > > } > > } > > }; > > t.start(); > > Thread.sleep(2000); > > t.interrupt(); > > Thread.sleep(1000); > > System.out.println(t.getState()); > > } > > } > > {code} > > If you run it on Windows, for example, here's the expected result: > > {code} > > Port: 666 > > Thread accept(); > > Thread ex: java.nio.channels.ClosedByInterruptException > > TERMINATED > > {code} > > Makes sense. On FreeBSD though, the result is: > > {code} > > Port: 32596 > > Thread accept(); > > RUNNABLE > > {code} > > Interestingly, the thread IS terminated after ctrl-c is pressed... > > I think this is a showstopper since it violates the contract of > accept(), which states: > > {code} > > ClosedByInterruptException - If another thread interrupts the current > thread while the accept operation is in progress, thereby closing the > channel and setting the current thread's interrupt status > > {code} > > > > -- > This message was sent by Atlassian JIRA > (v6.2#6252) > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > >
