Im BPM- und Integrations-Umfeld trifft man immer wieder auf folgendes Problem:

After two years my improvment for the Lucene Java search library has been committted... See LUCENE-1287 for details.

I have submitted a patch to allow Solr's RequestHandlers to suppress the creation of HTTP caching headers. It makes no sense for example to cache responses for the admin pages and the update handlers. There is another patch that allows partial responses with timeout. This responses should not be cached as well.

Requests that end up in an exception should not be cached as well.

The patch is registered as SOLR-505 in Apache's JIRA.

LUCENE-1166 (A tokenfilter to decompose compound words) has been committed today. Hooray...

You can speedup Java processes that handle a big heap (several gigabytes) by configuring Linux and the JVM to use large memory pages. This minimizes the load on the TLB tables (which can hold only a limited number of entries) of the processor. For applications that don't have localized memory structures you can easily see a speedup of 50-100% because of the trashing of the TLB caches! But the speedup depends on the type of application you are running of course.

I am developing an Unix "tail" like application for some months now. It is called logtail. It is built as a Java webapplication using JSF as display layer.
For building and testing I use Maven. It is a very powerful software project management and comprehension tool.

There are a lot of causes for OOE in Java. Here is my list of causes

• Exhausted heap. Try to increase heap size with -Xmx.
• Too small PermSize. You can increase this memory pool by adding -XX:MaxPermSize=value to the JVMs command line. If you use JSPs or some similar technology you should set this to at least 128MB. (see http://java.sun.com/docs/hotspot/gc5.0/gc_tuning_5.html for details)