New answers tagged java
You are trying to write to root directory ('/') which is not writable for the user account you are using to run the sitemapgen4j (i.e. only root user can write to '/'). Change it to any directory where you have write access.
Disclaimer: from my point of view it is not a good idea to donwgrade the connection protocol to SSLv3 unless you have a device which does not support TLS. If you really need it you can force the tomcat connector to use the SSLv3 protocol. In the connector XML configuration: <!-- Define a SSL Coyote HTTP/1.1 Connector on port 8443 --> <Connector ...
Check your hostname using hostname, for example: $ hostname jasperserver then update your /etc/hosts: 127.0.0.1 localhost jasperserver Then re run the installer. It will be fine....:)
Try doubling it. If you don't have many other processes using up the 6GB of ram then giving 1-2GB of RAM to the JVM should be fine. -Xms1024m -Xmx2048m You can also run your app using the following: java -Xmx2g yourapp You can also try profiling the application to spot possible memory leaks or to find out what is causing the app to use up so much ...
Try remove trailing slash from balancermember: <Proxy balancer://testcluster> BalancerMember ajp://192.168.2.166:8010 route=acd11-node01 BalancerMember ajp://192.168.2.166:8011 route=acd11-node02 ProxySet lbmethod=byrequests </Proxy> https://issues.apache.org/bugzilla/show_bug.cgi?id=51982
If you have a Heap Dump it means that the server has thrown an exception of type: OutOfMemoryExceptions: That is the jvm garbage collector can't release memory and probably exist some memory leak and can occur again. You must store these dump (not necessary in the same machine) and send it to Development Team (or Support) These can be analyzed whit ...
Looks like it definitely was a problem with entropy generation with the SecureRandom class. I added this flag to the JAVA_OPTS: -Djava.security.egd=file:/dev/./urandom and it starts up perfectly fine. I know this isn't the perfect way to fix the problem so I'm going to see if upgrading to Java8 may solve it. I got my information from this link.
I installed java jre using this steps, you can do the same steps for jdk. tar xvfz jre-8u25-linux-i586.tar.gz mv jre1.8.0_25/ /opt/ usage: alternatives --install <link> <name> <path> <priority> alternatives --install /usr/bin/java java /opt/jre1.8.0_25/bin/java 2 alternatives --config java There are 2 programs which provide ...
There is some recent activity in bug tracker of OpenJDK related to this crash: http://icedtea.classpath.org/bugzilla/show_bug.cgi?id=1326 http://icedtea.classpath.org/bugzilla/show_bug.cgi?id=2160 Target fix version is icedtea-2.5.4 which should map to a OpenJDK7 version following u71b14 (since u71b14 corresponds to icedtea-2.5.3).
Your heap settings configure 4gigs not 2 - that's what the Xms4096m -Xmx4096m are telling you. Perm size adds another 200 megs. your New size (the amount that young gen grabs onto in a single operation) is very high - usually this number is between 64m and 256m - giving generation space to roam up and down the young heap. So the fact that you see 3.9g ...
You're doing nothing wrong. "Cached" memory in Linux is the kernel using available RAM to cache files from disk, for speedy access( no need to go to slow disk for commonly accessed files). This is by design, and a good thing.
Gusset do following: ping ip address. If get time out , it means there is network connection problem. If ping result indicates connection ok, and the still get same exception, then do: use command tracert Ip Address to gat domain name. use domain name instead of ip addesss in your connection string: ...
Top 50 recent answers are included