Is the JVM Options List still being maintained anywhere? It seems to have disappeared from Oracle's website, but luckily the Wayback Machine has a copy.
Use java -XX:+PrintFlagsFinal to print available -XX options.
More diagnostic and experimental options can be added to list with following options:
-XX:+UnlockDiagnosticVMOptions
-XX:+UnlockExperimentalVMOptions (for Sun)
-XX:+UnlockInternalVMOptions (for JRockit)
NOTE: Current version of javac docs for Java 8 contains list of most -XX options: https://docs.oracle.com/javase/8/docs/technotes/tools/windows/java.html
Oracle's guide with 80+ options: http://www.oracle.com/technetwork/java/javase/tech/vmoptions-jsp-140102.html
Pierre Laporte's service with full search for 907 options (supports JDK 8):
http://jvm-options.tech.xebia.fr/
Stas's guide with 800+ options: http://stas-blogspot.blogspot.com/2011/07/most-complete-list-of-xx-options-for.html
Collection of options for 1.6.0 and older versions of JVM: http://www.xenoc.demon.co.uk/A%20Collection%20of%20JVM%20Options.htm
I used the same document very frequently as a reference, but unfortunately the original author was not maintaining it anymore.
I think it is still a valid list especially for older JVMs.
The www.xenoc.demon.co.uk referenced by Andriy is no more available...
So I'm trying to keep an updated version of the document here A Collection of JVM Options.
Related
I want to collect some buggy files.
So, I found data-set that present which file has a bug.
In data set, document said that Tomcat,6.0.389418,org.apache.jasper.compiler.Compiler file has a bug
In order to get bug file, i visit apache svn repository. And I found archive tomcat version 6_0_38 (http://svn.apache.org/repos/asf/tomcat/archive/tc6.0.x/tags/TOMCAT_6_0_38)
But I cant get file more detail version (6.0.389418) there is only 6_0_38
Can I think of two versions as the same?
Thank you.
Most importantly, you should know that Tomcat 6 has seen its end of life in December 2016, and the latest version that I can find in the archives is 6.0.53.
Based on this alone: Upgrade! First to the latest version in the 6.0 branch, then to a version that actually will continue to get security fixes. I've never seen any problems when upgrading within the same major version - the tomcat developers do a great job keeping their upgrades compatible.
And last, to the letters of your question instead of the spirit: The third digit of Tomcat version numbers is counting up, one by one. There is no 6.0.389418. As Tomcat uses Subversion, and subversion counts up the commits one by one, you might be lucky to find something around commit #389418 or #9418. Note: I've not even looked at their SVN to check if these are legitimate commits in the time that you're referring to (not even what the current commit is).
Eh, it might be quite hard to really nail this build number, but there is also a good chance this is a build you are asking for. Read for explanation.
You are asking for version: 6.0.389418
If you look into this file:
https://svn.apache.org/repos/asf/tomcat/archive/tc6.0.x/tags/TOMCAT_6_0_38/dist.xml
You can learn how build number is being built:
<property name="version.number" value="${version.major}.${version.minor}.${version.build}.${version.patch}"/>
values are taken from:
https://svn.apache.org/repos/asf/tomcat/archive/tc6.0.x/tags/TOMCAT_6_0_38/build.properties.default
# ----- Version Control Flags -----
version.major=6
version.minor=0
version.build=38
version.patch=0
version.suffix=
So the missing part of your version is 9418 which is should correspond to ${version.build} or (more unlikely) to ${version.patch}
In either case it might be not unambiguous, because often there is a build script used which performs multiple actions and as a result, appends its own version at the end of real package. I'd lean towards this explanation, because if this were to be a patch number, there would be some /patches directory in SVN, which I don't see in any other directories for more recent development.
But then, there is:
https://svn.apache.org/repos/asf/tomcat/archive/tc6.0.x/tags/TOMCAT_6_0_38/bin/version.sh -> running function from:
https://svn.apache.org/repos/asf/tomcat/archive/tc6.0.x/tags/TOMCAT_6_0_38/bin/catalina.sh
elif [ "$1" = "version" ] ; then
"$_RUNJAVA" \
-classpath "$CATALINA_HOME/lib/catalina.jar" \
org.apache.catalina.util.ServerInfo
else
Try to download it and run ./bin/version.sh
I am trying to connect the PHP with Java with the PHP/Java Bridge library. But I am facing an error as given below.
Please check below screenshot.
By default, the phpjavabridge servlet try to connect to a php-cgi daemon. It can be easily fixed, either by starting one of the bundled php-cgi (found in WEB_INF/cgi, follow the error message) or modify the configuration in the web.xml (see an example here) to provide your system php-cgi path. Repackage and redeploy your war file.
That said, if you want to use Java from PHP (and not PHP from Java), you don't need a php-cgi daemon. My recommendation, have a look to the following project: http://docs.soluble.io/soluble-japha/. This is a reworked version focusing on PHP -> Java integration.
Feel free to open issues on https://github.com/belgattitude/soluble-japha
Can anyone tell me what are the new features added in hybris 5.5.1.2 release when compared to hybris 5.5.1.1 release in hybris?Any one throw some light on it...
There are usually no features added in minor releases (anything from third qualifier on), usually those releases only contain critical security fixes and blocker/critical issues.
You can find more details for 5.5.1.2 here (scroll down a bit and you'll see it):
https://wiki.hybris.com/display/downloads/Archived+5.5.1+Release
If you have a hybris jira account you can look at the patch ticket: https://jira.hybris.com/browse/PATCH-2070
The issues mentioned in there are:
ECP-388: Running Initialization or Update from hAC causing SQLException on weblogic
ECP-537: Cronjobs in cluster: allow to set nodeGroup/nodeID without recreating the trigger
ECP-540: synchronousOM extension dump in 5.5.1.1 during build process
ECP-552: Datahub 5.5.1 -mysql 5.6 (linux) Could not load extension for raw type RawHybrisCustomer
Hope that helps!
I have three solr 3.4.0 indexes that I want to merge, after searching I've found that there are two ways to do it:
Using Lucene Merge tool.
Merging through core admin
I am using lucene 3.4.0 and running following command:
java -cp d:/lucene/lucene-core-3.4.0.jar:./contrib/misc/lucene-misc-3.4.0.jarorg/apache/lucene/misc/IndexMergeTool ./newindex ./app1/solr/data/index ./app2/solr/data/index
but unfortunately it gives me following exception:
Exception in thread "Main Thread" java.lang.NoClassDefFoundError:
org/apache/lucene/misc/IndexMergeTool
Can anybody help me with this?
Couple of things :-
./contrib/misc/lucene-misc-3.4.0.jar
Are you running it from the correct directory for it to find the jar. Why not use full path ?
You are using :(colon) as jar classpath separator, and using windows it should be ; (semi-colon)
Also -
If you already have Solr running with the Solr indexes ready, I would recommend you to use the second option - merging through Solr Admin.
This is more easy to use with direct http interface without any additional overheads and would work out of the box.
I solved this particular problem by creating a new java application in net beans 7.1 and adding both the jar files as library. and inside my new application's main method i have called
IndexMergeTool.main
and pass all command line arguments to above mentioned method.
Regards
Ahsan
I'm trying to give pg_bulkload a try.
When I try to use the postgresql executable it provides, I get the following error:
/usr/local/src/pg_bulkload-3.0.1/bin> ./postgresql start -D /pg_data
server starting
/usr/local/src/pg_bulkload-3.0.1/bin>
FATAL: unrecognized configuration parameter "wal_level"
Google turned up an exact match for this error when someone was using a 9.0 version of psql to run a script on an instance of Postgres 8.4. I don't see how that could be related to my case--I have two versions of Postgres, but I'm sure I'm pointing at the right directory... any thoughts are very welcome.
As far as I can tell from the docs, PostgreSQL 9.x supports a configuration parameter named "wal_level", but version 8.4 does not. The postgresql.conf file for my 9.0.something server has that parameter; the one for my 8.4 server does not.
PostgreSQL 9.x server configuration
PostgreSQL 8.4 server configuration
Your error message suggests you're running version 8.4, but it's reading the configuration file for a 9.x server. Check your postgresql.conf and installation process. I'm thinking pg_bulkload might have "helped" you in ways you didn't anticipate.
I think that it can be a bit tricky to install pg_bulkload to the right place if you have more than one version of PostgreSQL installed on your machine. My first problem was that pg_bulkload (version 3.1.6) could not find pg_port library. I copied the library libpgport.a (a static library) to /usr/local/lib where it was found, but this approach is not recommended, because this is only a quick fix that doesn't work at the end. So, very soon there was another problem: "undefined reference to `pstrdup'". I reckon that in pg_bulkload there should be a possibility of pointing out where PostgreSQL is installed. Well, I changed Makefile of pg_bulkload in pg_bulkload-3.1.6/bin, namely line with PG_LIBS: PG_LIBS = $(libpq) -L/current location of your PostgreSQL/PostgreSQL/pgsql/lib -lpgport -lpgcommon. -lpgport has to be added before -lpgcommon. Last but not least, to compile and install pg_bulkload you shoud modify your PATH: PATH=/current location of your PostgreSQL/PostgreSQL/pgsql/bin:$PATH make USE_PGXS=1 [install]; This makes sure that your pg_bulkload will be added to the correct version of PostgreSQL (in my case 9.3). Enjoy!