Hot answers tagged

38

You didn't told nginx for how much time the response is valid and must be served from cache. This must be specified with proxy_cache_valid directive. proxy_cache one; proxy_cache_key $host$uri$is_args$args; proxy_cache_valid 200 10m; But, this won't work for POST requests because you have no cache key that differs from a POST request to another on the ...


26

Ok I finally solved it. I was directed to try this and Henk's solution. Neither of which seemed to work with the remote virtual server. I'm guessing the fact that because I'm on a shared kernel space so the provider prevents this. In any case I added: JAVA_OPTS= $JAVA_OPTS -Djava.net.preferIPv4Stack=true -Djava.net.preferIPv4Addresses to the catalina.sh ...


24

Many suggested updating catalina.sh startup script. Yes, that solution would work, but catalina.sh script is not meant to be customized/updated. All changes should go into the customization script instead, i.e. setenv.sh. NOTE: TOMCAT_HOME/bin/setenv.sh doesn't exist by default, you need to create it. Check the catalina.sh script and you will see the ...


14

From: http://nginx.org/en/docs/http/ngx_http_proxy_module.html#proxy_cache_valid Syntax: proxy_cache_valid [code ...] time; ... Parameters of caching can also be set directly in the response header. This has higher priority than setting of caching time using the directive. The “X-Accel-Expires” header field sets caching time of a ...


11

<Set name="headerBufferSize">65536</Set> is now deprecated. You can use: <Set name="requestHeaderSize">65535</Set> instead.


9

From what is mentioned in http://pecl.php.net/bugs/bug.php?id=17012&edit=1, pecl does not recognize php modules that were not statically compiled into php. So if you are using any shared libraries, pecl will ignore them. Pecl also ignores your php.ini. The good news is there are still two easy ways to install this if you have curl as a shared ...


7

The order of iptables rules is important, as first-match-wins. Red Hat, like most sensible people, usually puts a blanket REJECT at the end of its chain, and adding rules to permit solr traffic - or any other kind of traffic - after that won't help, as the packet will never get that far down the chain. If this is what's biting you, you need to do an ...


7

From "man initctl"... restart JOB [KEY=VALUE]... Requests that an instance of the named JOB be restarted, outputting the status of the job to standard output when the command completes. The job instance being restarted will retain its original configuration. To have the new instance run with the latest job configuration, stop the job and then start it ...


7

I don't believe you can get the Debian style daemon to work in CentOS, in CentOS it is more common to source /etc/init.d/functions in your init script. This will make the daemon function available to you - with totally different options than the example you posted! For a simple example check out the crond init script at /etc/init.d/crond.


6

Get the PID of the process that solr is running and then cat /proc/$SOLR_PID/limits -- this will tell you the actual limits of the process. I'd recommend to run things like solr as a seperated unprivileged user. When doing this you have multiple options (limits.conf or add a ulimit -n 2048 to the init script, ...). The last one isn't all that shiny but ...


6

It's waiting for more content. When Solr runs a commit operation to bring more documents into the index, it needs to tear down its existing searcher core and start up a new one. This is a resource intensive operation, and destroys all of the old searcher's caches (and re-runs its cache warming process). If you're doing your updates in a number of ...


6

PS Perm Generation capacity = 88080384 (84.0MB) used = 88080080 (83.99971008300781MB) free = 304 (2.899169921875E-4MB) 99.99965486072358% used There's your culprit. PermGen is used for class definitions, and you seem to have a lot of them! Try cranking up your PermGen size by adding this to your Tomcat launch options: -XX:MaxPermSize=...


5

After changing number of open files in /etc/security/limits.conf, user must log out and log back in to take effect. So, try this: $ sudo su - # ulimit -Sn


5

I know you are using Jetty, but I have a method using Tomcat that works and will explain below. Basically, I have given up trying to understand what I perceive as excessively obtuse ways Java web apps protect themselves in Jetty and Tomcat. So I prefer allowing Apache to do the heavy lifting of being the first line of defense against access. Apache is solid ...


5

You can use the IPAccessHandler that is in jetty 7, 8 and 9 http://download.eclipse.org/jetty/stable-9/apidocs/org/eclipse/jetty/server/handler/IPAccessHandler.html you would wire this up in the handler chain so that it is executed before anything else in the handler chains [edit] also look at the jetty-ipaccess.xml file under $jetty.home/etc http://git....


4

You need to adjust autocommit option in your solrconfig.xml. By default its: <autoCommit> <maxDocs>2000</maxDocs> <maxTime>120000</maxTime> </autoCommit> maxTime is what you need, it's in miliseconds.


4

You can try this approach http://wiki.apache.org/solr/CoreAdmin#RELOAD. Using a command like this http://localhost:8983/solr/admin/cores?action=RELOAD&core=core0 will just reload all your configuration files and you will not have problems in doing SOLR queries querying while the core is restarted.


4

At Websolr, we use a combination of a custom init.d script plus Monit to start Solr and ensure that it stays running. That said, for a simpler self-hosted setup, I would recommend using Upstart to start and stop Solr, if your system has Upstart available. Upstart scripts have the benefit of being fairly simple, and Upstart does a good job restarting ...


4

I ran into this same issue on RHEL 5.3 with Tomcat 7 and solr 3.5. I just disabled the query response writer velocity inside the solrconfig file. But if you need to use velocity, which i don't, it appears that you'll need to drop some files into the lib folder. <queryResponseWriter name="velocity" class=solr.VelocityResponseWriter" enable=false/> ...


4

You can try Mysql or MongoDB full-text search capabilities. http://dev.mysql.com/doc/refman/5.0/en/fulltext-search.html http://www.mongodb.org/display/DOCS/Full+Text+Search+in+Mongo


4

The correct syntax for modifying catalina.sh would be: JAVA_OPTS=" $JAVA_OPTS -Djava.net.preferIPv4Stack=true -Djava.net.preferIPv4Addresses=true "


4

We switched to elasticsearch and couldn't be happier. It still uses lucene but can horizontally scale better since it has build in sharding. So it should work well if you have multiple nodes for a 150gig DB. http://www.elasticsearch.org/


4

OK, I found the answer myself. Problem was in the errors in configuration. On newest Wheezy the config tree for PHP is as follows: /etc/php5/mods-available/*.ini # here's the ini files containing `extension=modulename.so` lines and module-specific config. /conf.d/NN-*.ini # here's the symlinks to real .ini files in mods-available /cli/...


4

The links from the HTML content page for the CSS and other files are probably absolute paths - so they're linked to /solr/path/to/css instead of path/to/css. You should be able to solve this by adding another ProxyPass: ProxyPass /solrsearch http://localhost:8983/solr/collection1/browse ProxyPassReverse /solrsearch http://localhost:8983/solr/collection1/...


3

We could fix it with the help of one of the contributors from sunspot rails and returned to a release candidate gem verioned before the last update. gem 'sunspot_rails', :git => 'https://github.com/sunspot/sunspot.git', :ref => '79175ea' gem 'sunspot_solr', :git => 'https://github.com/sunspot/sunspot', :ref => '79175ea' This fixed the issue for ...


3

The reason you are seeing such high virtual memory usage is that Solr uses MMapFSDirectory as the default class for manipulating the Lucene index. This class will attempt to map any indexes under Solr control to virtual memory - the more cores/indexes the worse it gets. The fun part is that this is outside the JVM's knowledge/control. The JVM will only ...


3

Stop Solr Go to the directory where you run "java -jar start.jar" mkdir work java -jar start.jar It seems that Jetty will use the work directory if it exists, otherwise it uses /tmp


3

I'd go with the first: /var/lib/solr. Why? Following the FHS on the var folder: There is a set of predefined folders inside var. It doesn't mean that you cannot add more, but you could prefer not to make it dirty. The /var/lib is where programs store the variable information they need to run. (Correct me if I'm wrong but I guess mysql uses /var/lib/mysql, ...


3

I think I figured it out myself. What I did was, inside the example directory, rename webapps/solr.war to webapps/foobar.war Also, I changed a line in solr/conf/scripts.conf to webapp_name=foobar


3

Solr's indexes are modified by making API calls to the Solr web service. Something outside of Solr should be making those calls to manage the members of the Solr index, and that's where you'll need to track the status of the work; Solr itself doesn't have any concept of tracking the progress of a bulk indexing job. You could guess at it badly with some ...


Only top voted, non community-wiki answers of a minimum length are eligible