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_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 ...
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 ...
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 ...
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
The “X-Accel-Expires” header field sets caching time of a ...
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 ...
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 ...
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 ...
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.
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 ...
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 ...
PS Perm Generation
capacity = 88080384 (84.0MB)
used = 88080080 (83.99971008300781MB)
free = 304 (2.899169921875E-4MB)
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:
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 ...
You can use the IPAccessHandler that is in jetty 7, 8 and 9
you would wire this up in the handler chain so that it is executed before anything else in the handler chains
 also look at the jetty-ipaccess.xml file under $jetty.home/etc
You can try this approach http://wiki.apache.org/solr/CoreAdmin#RELOAD.
Using a command like this
will just reload all your configuration files and you will not have problems in doing SOLR queries querying while the core is restarted.
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 ...
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/>
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.
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
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/...
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 ...
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 ...
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, ...
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 ...