To adress security vulnerability CVE-2017-3241 (Java RMI Registry.bind() Unvalidated Deserialization) which affects JRE version prior to 1.8.0_121. In addition to using JRE 1.8.0_121 ,we added below lines of code in java.security file.
jdk.serialFilter=*
sun.rmi.registry.registryFilter=*
sun.rmi.transport.dgcFilter=\
java.rmi.server.ObjID;\
java.rmi.server.UID;\
java.rmi.dgc.VMID;\
java.rmi.dgc.Lease;\ maxdepth=2147483647;maxarray=2147483647;maxrefs=2147483647;maxbytes=2147483647
Once we add these lines then we are getting below lines whenever do any RMI call.
Feb 13, 2017 1:00:53 AM sun.misc.ObjectInputFilter$Config lambda$static$0
INFO: Creating serialization filter from *
We want to suppress these info, can somebody suggest any solution for this.
I use -Djdk.serialFilter=maxbytes=10000;!org.* as JVM arguments, don`t see any log info.
Related
I tried to open the Groovy Shell (groovysh) on Windows 8 and got the following output:
java.util.prefs.WindowsPreferences <init>
WARNING: Could not open/create prefs root node Software\JavaSoft\Prefs
at root 0x80000002. Windows RegCreateKeyEx(...) returned error code 5.
After printing the above message the shell started as expected.
Dennis answer is correct. However I would like to explain the solution in a bit more detailed way (for Windows User):
Go into your Start Menu and type regedit into the search field.
Navigate to path HKEY_LOCAL_MACHINE\Software\JavaSoft (Windows 10 seems to now have this here: HKEY_LOCAL_MACHINE\Software\WOW6432Node\JavaSoft)
Right click on the JavaSoft folder and click on New -> Key
Name the new Key Prefs and everything should work.
Alternatively, save and execute a *.reg file with the following content:
Windows Registry Editor Version 5.00
[HKEY_LOCAL_MACHINE\Software\JavaSoft\Prefs]
I was able to resolve the problem by manually creating the following registry key:
HKEY_LOCAL_MACHINE\Software\JavaSoft\Prefs
This is actually a JDK bug. It has been reported several times over the years, but only in 8139507 was it finally taken seriously by Oracle.
The problem was in the JDK source code for WindowsPreferences.java. In this class, both nodes userRoot and systemRoot were declared static as in:
/**
* User root node.
*/
static final Preferences userRoot =
new WindowsPreferences(USER_ROOT_NATIVE_HANDLE, WINDOWS_ROOT_PATH);
/**
* System root node.
*/
static final Preferences systemRoot =
new WindowsPreferences(SYSTEM_ROOT_NATIVE_HANDLE, WINDOWS_ROOT_PATH);
This means that the first time the class is referenced both static variables would be initiated and by this the Registry Key for HKEY_LOCAL_MACHINE\Software\JavaSoft\Prefs (= system tree) will be attempted to be created if it doesn't already exist.
So even if the user took every precaution in his own code and never touched or referenced the system tree, then the JVM would actually still try to instantiate systemRoot, thus causing the warning. It is an interesting subtle bug.
There's a fix committed to the JDK source in June 2016 and it is part of Java9 onwards. There's also a backport for Java8 which is in u202.
What you see is really a warning from the JDK's internal logger. It is not an exception. I believe that the warning can be safely ignored .... unless the user code is indeed wanting the system preferences, but that is very rarely the case.
Bonus info
The bug did not reveal itself in versions prior to Java 1.7.21, because up until then the JRE installer would create Registry key HKEY_LOCAL_MACHINE\Software\JavaSoft\Prefs for you and this would effectively hide the bug. On the other hand you've never really been required to run an installer in order to have a JRE on your machine, or at least this hasn't been Sun/Oracle's intent. As you may be aware Oracle has been distributing the JRE for Windows in .tar.gz format for many years.
If anyone is trying to solve this on a 64-bit version of Windows, you might need to create the following key:
HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\JavaSoft\Prefs
The problem is that simple console can't edit the registry. No need to edit the registry by hand, just launch the groovysh once with administrative priveleges. All subsequent launches work without error.
Had a similar problem when starting apache jmeter on windows 8 64 bit:
[]apache-jmeter-2.13\bin>jmeter
java.util.prefs.WindowsPreferences <init>
WARNING: Could not open/create prefs root node Software\JavaSoft\Prefs at root 0x80000002. Windows RegCreateKeyEx(...) returned error code 5.
Successfully used Dennis Traub solution, with Mkorsch explanations. Or you can create a file with the extension "reg" and write into it the following:
Windows Registry Editor Version 5.00
[HKEY_LOCAL_MACHINE\SOFTWARE\JavaSoft\Prefs]
... then execute it.
I was getting the following message:
Could not open/create prefs root node Software\JavaSoft\Prefs at root 0x80000002
and it was gone after creating one of these registry keys, mine is 64 bit so I tried only that.
32 bit Windows
HKEY_LOCAL_MACHINE\Software\JavaSoft\Prefs
64 bit Windows
HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\JavaSoft\Prefs
This happened to me.
Apparently it is because Java does not have permission to create registry keys.
See: Java: java.util.Preferences Failing
The problem is indeed the register key that is missing. It can be created manually
OR
it can be created automagically by running the program as administrator once. That will give the program the permissions required, and when it will be ran as normal it will still work correctly.
I wrote a ROS node using rosjava.
When it starts up, there are a few logging outputs like:
Loading node class: MyApp.RosWrapper
Jun 18, 2015 3:12:39 PM org.ros.internal.node.client.Registrar <init>
INFO: MasterXmlRpcEndpoint URI: http://localhost:11311
Jun 18, 2015 3:12:39 PM org.ros.internal.node.client.Registrar onPublisherAdded
INFO: Registering publisher: Publisher<PublisherDefinition<PublisherIdentifier<NodeIdentifier</mynode, http://127.0.0.1:39009/>, TopicIdentifier</rosout>>, Topic<TopicIdentifier</rosout>, TopicDescription<rosgraph_msgs/Log, acffd30cd6b6de30f120938c17c593fb>>>>
I've found out that rosjava uses the org.apache.commons.logging.Log approach (see https://github.com/rosjava/rosjava_core/blob/indigo/rosjava/src/main/java/org/ros/internal/node/client/Registrar.java#L54)
To configure this, you should normally put a file called commons-logging.properties in your Classpath. I tried to add the folder containing this file to the classpath, but nothing changed.
UPDATE:
I found out that by default rosjava uses the Jdk14Logger class.
How can I decrease the log-level to e.g. WARN? Where do I have to put the corresponding config files?
Disclaimer: As stated in the comment, this does not work for rosjava and therefore does not answer the question. I do not delete the post, however, to keep records that this has already been tried.
Permanent setting
To permanently modify the log-level, create a file and add something like the following:
# Set the default ros output to warning and higher
log4j.logger.ros=WARN
# Override my package to output everything
log4j.logger.ros.my_package_name=DEBUG
For ROS to use this file, you have to define the environment ROSCONSOLE_CONFIG_FILE and set it to the path of your file. This can be done by adding the following line to ~/.bashrc:
export ROSCONSOLE_CONFIG_FILE=/path/to/config_file
See also the ROS wiki about rosconsole configuration.
Temporary setting
If you only want to temporarily change the log-level for a currently running node, you can use the tool rqt_logger_level. This will start a GUI where you can change the log-level for each running node. The settings are not stored, however, so it will be lost after restarting the node.
To manage the log levels for any ROSJava project, create a file like this one:
log-config.properties
# The following creates two handlers
handlers=java.util.logging.ConsoleHandler, java.util.logging.FileHandler
# Set the default logging level for the root logger
.level=ALL
# log level for the "com.example" package
org.ros.logging.level=ALL
# Set the default logging level
java.util.logging.ConsoleHandler.level=ALL
java.util.logging.FileHandler.level=ALL
# Set the default formatter
java.util.logging.ConsoleHandler.formatter=java.util.logging.SimpleFormatter
java.util.logging.FileHandler.formatter=java.util.logging.SimpleFormatter
# Specify the location and name of the log file
java.util.logging.FileHandler.pattern=/home/robot/test.log
and later, load the configuration in the execution:
java -Djava.util.logging.config.file=/home/robot/log-config.properties -jar rosjava-helloworld-0.1.0-SNAPSHOT-all.jar
Juan Antonio
There is sample java code for Hbase connectivity program which is the famous "HbaseTest" class sample, which is available in the internet for long time.
I have compiled the code in my server and compiling was successful. When i run my Java class file, i am able to see that it is getting hanged in the particular line. "HTable table = new HTable(conf, tableName);"
It throws the below alert when running.
Jun 18, 2015 12:16:14 PM org.apache.hadoop.util.NativeCodeLoader WARNING: Unable to load native-hadoop library for your platform... using builtin-java classes where applicable Jun 18, 2015 12:16:15 PM org.apache.hadoop.hbase.zookeeper.RecoverableZooKeeper INFO: The identifier of this process is pid#servername
I have identified it has stuck in that particular lines by giving Print statements.
Please do let me know what to do for the same. I have checked that the Hbase is running properly.
Kindly share your thoughts and idea's.
#hive #hbase #hadoop
Thanks in Advance Sam
I had a similar problem before it was network issues. Try setting retry and timeout parameters, e.g.
hbase.client.retries.number=2
zookeeper.session.timeout=2000
zookeeper.recovery.retry=0
hbase.rpc.timeout=100
ipc.socket.timeout=100
hbase.client.pause=100
zookeeper.recovery.retry.intervalmill=100
timeout=100
You may need to modify your network settings according to the errors that are thrown.
I've got a Tomcat webapp where I'm using AspectJ for logging and metrics, everything seems fine, but it keep creating several files like ajcore.20150310.113255.780.txt in the root folder. There is no exception in this files, so they are completely useless.
I've found this: https://eclipse.org/aspectj/doc/released/pdguide/ajcore.html
That states that using org.aspectj.weaver.Dump.exception="false" should disable this behavior, yet the files are still appearing. Is there any other way to completely disable the creation of this files? The other option mentioned: org.aspectj.dump.directory would also solve the problem, but it doesn't seem to work either.
This is the content of the file in case it helps for anything:
---- AspectJ Properties ---
AspectJ Compiler 1.7.1 built on Thursday Sep 6, 2012 at 16:39:22 GMT
---- Dump Properties ---
Dump file: ajcore.20150310.113255.780.txt
Dump reason: org.aspectj.weaver.BCException
Dump on exception: true
Dump at exit condition: abort
---- Exception Information ---
---- System Properties ---
... My system properties here
---- Command Line --- Empty
---- Full Classpath --- Empty
---- Compiler Messages --- Empty
Either of the following options may help:
Executing this code before any AspectJ weaving occurs (if possible): org.aspectj.weaver.Dump.setDumpOnExit(org.aspectj.bridge.IMessage.ABORT)
Adding this system property definition to your java command-line: -Dorg.aspectj.weaver.Dump.condition=abort
I think it is good that the AJ core dump happens because something seems to go wrong during LTW compilation:
Dump file: ajcore.20150310.113255.780.txt
Dump reason: org.aspectj.weaver.BCException
So there is an exception and you should investigate and fix it. Maybe some of your classes are woven with the logging code correctly and some are not. Run the weaver in verbose mode and check your console output, maybe you see something strange there. An AJ core file means that the weaver/compiler was shut down completely (abnormal termination).
As for the actual problem, I think that this
---- Command Line --- Empty
looks strange, as if no command line parameters were passed to the weaver. Also that no exception is actually logged is really unusual.
Which Java version are you on? I assume Java 7 because 1.6 is really old and Java 8 needs AspectJ 1.8. Anyway, can you try to use the latest AspectJ version 1.8.5 or at least the latest 1.7.4 from the old release and see if the problem still occurs?
Add this argument to your JVM run: -Dorg.aspectj.weaver.Dump.exception=false
And also see official docs
I downloaded the examples of latest version for chapter 09 of “Mahout in Action”. I can successfully run several examples, but for three files, NewsKMeansClustering.java, ReutersToSparseVectors.java, and NewsFuzzyKMeansClusteing.java. Running these three programs gives similar error messages:
Aug 3, 2011 2:03:54 PM org.apache.hadoop.metrics.jvm.JvmMetrics init
INFO: Initializing JVM Metrics with processName=JobTracker, sessionId=
Aug 3, 2011 2:03:54 PM org.apache.hadoop.mapred.JobClient configureCommandLineOptions
WARNING: Use GenericOptionsParser for parsing the arguments. Applications should
implement Tool for the same.
Aug 3, 2011 2:03:54 PM org.apache.hadoop.mapred.JobClient configureCommandLineOptions
WARNING: No job jar file set. User classes may not be found. See JobConf(Class) or
JobConf#setJar(String).
Exception in thread "main" org.apache.hadoop.mapreduce.lib.input.InvalidInputException: Input path does not exist: file:/home/user1/workspaceMahout1/recommender/inputDir
at org.apache.hadoop.mapreduce.lib.input.FileInputFormat.listStatus(FileInputFormat.java:224)
at org.apache.hadoop.mapreduce.lib.input.SequenceFileInputFormat.listStatus(SequenceFileInputFormat.java:55)
at org.apache.hadoop.mapreduce.lib.input.FileInputFormat.getSplits(FileInputFormat.java:241)
at org.apache.hadoop.mapred.JobClient.writeNewSplits(JobClient.java:885)
at org.apache.hadoop.mapred.JobClient.submitJobInternal(JobClient.java:779)
at org.apache.hadoop.mapreduce.Job.submit(Job.java:432)
at org.apache.hadoop.mapreduce.Job.waitForCompletion(Job.java:447)
at org.apache.mahout.vectorizer.DocumentProcessor.tokenizeDocuments(DocumentProcessor.java:93)
at mia.clustering.ch09.NewsKMeansClustering.main(NewsKMeansClustering.java:54)
For the above messages, I do not quite understand what do those two warnings mean? Moreover, it looks like that “input path” should have been created, how can I create this type of input? Thanks.
You can ignore the warnings. The error is that the input directory you have specified does not exist. Does it exist? What is your command line?
I ran into a similar mismatch. The MiA files at https://github.com/tdunning/MiA have some cases where a .csv file is left in the same dir as the Java source. For example https://github.com/tdunning/MiA/tree/master/src/main/java/mia/recommender/ch02 ... however via Eclipse, loading it using DataModel model = new FileDataModel(new File("intro.csv")); ...doesn't find it.
Adding
System.out.println("CWD: "+System.getProperty("user.dir"));
...will reveal where Eclipse is looking (in my case, a couple levels up the filetree, but this might vary depending on how exactly you've set things up).