Then I think you downloaded the wrong JDK 7 (32bits JDK?), if you are
running JDK 7 64bits the -server flag should be recognized. According to
the stackoverflow link you mentioned before.
Guido.
On 11/10/13 15:48, Peter Schmidt wrote:
no it is 64bit and just a development VM. In production the solr will use
multicore, also 64bit and some gb ram.
2013/10/11 Guido Medina <guido.med...@temetra.com>
If your single core is at 32bits use Oracle JDK 7u25 or Ubuntu Open JDK 7,
the JDK 7u40 for 32bits will corrupt indexes as stated on the lucene bug
report.
Guido.
On 11/10/13 15:13, Peter Schmidt wrote:
Oh, i got it
http://stackoverflow.com/a/**5273166/326905<http://stackoverflow.com/a/5273166/326905>
"at least 2 cores and at least 2 GB physical memory"
Until know i'm using a VM with single core and 1GB RAM.
So this will be later for production :)
Thank you Guido.
2013/10/11 Peter Schmidt <peter.schmidt0...@gmail.com>
Strange. When i add "-server" to the arguments, i got everytime the error
on jetty startup
Invalid option -server
Cannot parse command line arguments
2013/10/11 Guido Medina <guido.med...@temetra.com>
It is JVM parameter, example:
JAVA_OPTIONS="-Djava.awt.****headless=true -Dfile.encoding=UTF-8
-server
-Xms256m -Xmx256m"
If you want to concatenate more JVM parameters you do it like this:
JAVA_OPTIONS="-Dsolr.solr.****home=/usr/share/solr $JAVA_OPTIONS"
Take a good look at the format,
Guido.
On 11/10/13 13:37, Peter Schmidt wrote:
@Guido: Itried it before and than i thought you marked just the server
options
Because the -sever causes a:
sudo service jetty start
* Starting Jetty servlet engine.
jetty
Invalid option -server
Cannot parse command line arguments
Or should i substitute server with ...?
Options with -server:
JAVA_OPTIONS="-Djava.awt.****headless=true -Dfile.encoding=UTF-8
-server
-Xms256m -Xmx256m -XX:+UseG1GC -XX:MaxGCPauseMillis=50
-XX:+OptimizeStringConcat -XX:+UseStringCache
-Dsolr.solr.home=/usr/share/****solr $JAVA_OPTIONS"
2013/10/11 Guido Medina <guido.med...@temetra.com>
Remember the "-server" which for Java webapps or dedicated Java
services
will improve things.
Guido.
On 11/10/13 12:26, Peter Schmidt wrote:
I can report that jetty is running now with this options:
JAVA_OPTIONS="-Djava.awt.******headless=true -Dfile.encoding=UTF-8
-Xms256m
-Xmx256m -XX:+UseG1GC -XX:MaxGCPauseMillis=50
-XX:+OptimizeStringConcat
-XX:+UseStringCache -Dsolr.solr.home=/usr/share/******solr
$JAVA_OPTIONS"
@Guido: I reduced the min/max heap size to 256m, i will increase this
on
production server.
2013/10/11 Peter Schmidt <peter.schmidt0...@gmail.com>
So the main problem was that the libs must be copied to the
WEB-INF/lib
directory insteed of the jetty lib/ext directory. Is the fact that
you
should you use WEB-INF/lib somewhere documented?
2013/10/11 Peter Schmidt <peter.schmidt0...@gmail.com>
Not so hard switching it to Oracle JDK 7u40.
Just download it and change the JAVA_HOME path in
/etc/default/jetty, so
it's not nescessary to switch java version with
update-java-alternatives
The machine is 64bit :)
2013/10/11 Bill Bell <billnb...@gmail.com>
Does this work ?
I can suggest -XX:-UseLoopPredicate to switch off predicates.
???
Which version of 7 is recommended ?
Bill Bell
Sent from mobile
On Oct 10, 2013, at 11:29 AM, "Smiley, David W." <
dsmi...@mitre.org>
wrote:
*Don't* use JDK 7u40, it's been known to cause index corruption
and
SIGSEGV faults with Lucene: LUCENE-5212 This has not been
unnoticed
by
Oracle.
~ David
On 10/10/13 12:34 PM, "Guido Medina" <
guido.med...@temetra.com>
wrote:
2. Java version: There are huges performance winning between Java
5, 6
and 7; we use Oracle JDK 7u40.
