besides adjustments in code it makes the servlet settings in web.xml significant.
This applies to solr, gsa and proxy servlet. There is no longer a default setup in code during init (as jetty 9 checks for double definition).
introduced, it was also used for search facets. The generic search
facets are now deduced from generic solr fields which makes jena as tool
for facet semantics superfluous.
solrj.4.6.0 has a bug which prevents the attachment of a remote solr (as
tested with a SolrCloud). See bug report
https://issues.apache.org/jira/browse/SOLR-5532
This bug shall be fixed in Solr 4.6.1.
Fortunately, solrj-4.5.1 works together with solr-4.6.0 thus the current
index does not need to be changed.
- this allows additional features, like servlet configuration via web.xml and many more things.
- currently the standard servlets are still configured in the code (so the supplied defaults/web.xml is not realy needed, yet),
but could be expanded
- lookup for web.xml - 1. in /DATA/SETTINGS then in /defaults
- used Apache procrun as it has a small footprint and comes with a GUI to edit the service settings
see http://commons.apache.org/proper/commons-daemon/procrun.html
- added the service runner exe file under addon/windowsService
as is (without renaming the exe files)
- included installYaCyWindowsService.bat and uninstallYaCyWindowsService.bat to main directory
- which chooses the native exe according to the processor_architecture
been removed from the other start scripts recently. The reason to do so
was a comparisment of a debian-installed YaCy with 20 million document
which crashed after 10 hours with the debian start script, but did not
crash with the startYACY.sh start script. Both scripts now use the same
java start arguments.
Added also the Solr MMapDirectoryFactory switch which was missing so far
in the debian start script.
- removed httpclient 3.1 which has been used by solrj < 4.x.x and is now
not used any more
- fixed some parts in YaCy which used methods from httpclient 3.1
log4j-over-slf4j is there. From slf4j all loggings are routed to the jdk
logger. Now all loggings are consistently done to the jdk logger.
- added some lines to the logging properties to suppress many solr
logging statements. The number of the logging entries had already become
a performance issue, therefore removing these from the log should
increase performance.
- move jetty*.jar to test library
- move SolrServlet.main as is to test, add also a junit test simulating main
- add build.xml cleanup for EmbeddedSolrConnectorTest created test/DATA
- adjust some test compile errors
-Xss256k
and
-XX:ReservedCodeCacheSize=1024m
after appearance of a malloc error together with a crash of the jvm which stated at the end of the log:
# There is insufficient memory for the Java Runtime Environment to continue.
# Native memory allocation (malloc) failed to allocate 32756 bytes for ChunkPool::allocate
# Possible reasons:
# The system is out of physical RAM or swap space
# In 32 bit mode, the process size limit was hit
# Possible solutions:
# Reduce memory load on the system
# Increase physical memory or swap space
# Check if swap backing store is full
# Use 64 bit Java on a 64 bit OS
# Decrease Java heap size (-Xmx/-Xms)
# Decrease number of Java threads
# Decrease Java thread stack sizes (-Xss)
# Set larger code cache with -XX:ReservedCodeCacheSize=
this follows the last two points in the list of recommendations. To set appropriate values the default values from
http://www.oracle.com/technetwork/java/hotspotfaq-138619.html
and
http://www.oracle.com/technetwork/java/javase/tech/vmoptions-jsp-140102.html
had been considered
git-svn-id: https://svn.berlios.de/svnroot/repos/yacy/trunk@7823 6c8d7289-2bf4-0310-a012-ef5d649a1542
Michael Peter Christen