I am trying to track down a memory leak that I am having with a Grails application and am using the Yourkit Profiler, but am running into a problem.
I have the Grails application running in Tomcat6 on the Production server and have unpacked the YourKit profiler and ran it according to the documentation using sudo bin/yjp.sh -attach, but I am getting the error:
java.lang.reflect.InvocationTargetException
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at com.yourkit.Main$2.run(a:19)
Caused by: com.yourkit.runtime.PresentableException: com.sun.tools.attach.AttachNotSupportedException: Unable to open socket file: target process not responding or HotSpot VM not loaded
at com.yourkit.ui.s.n.a(a:170)
at com.yourkit.ui.s.n.a(a:176)
at com.yourkit.ui.s.j.a(a:250)
at com.yourkit.c.do(a:73)
at com.yourkit.Main0.entry(a:274)
... 5 more
I am using YourKit v10 and am on an Ubuntu 11.04 server. Any ideas?
It looks like I had to run as the user running the container. Changing sudo bin/yjp.sh -attach to sudo -u tomcat6 bin/yjp.sh -attach worked.
You need to have the Attach API working before you can continue:
com.sun.tools.attach.AttachNotSupportedException: Unable to open socket file: target process not responding or HotSpot VM not loaded
See the JVisualVM FAQ - their troubleshooting can be used here too.
Related
I am unable to start the gerrit.sh script. while running this script, it says starting failed. Below is the error that i can see in the error_log:
[2018-09-10 02:05:13,886] ERROR com.google.gerrit.pgm.Daemon : Unable to start daemon
java.lang.IllegalStateException: Cannot bind to NewVoE-GIT01:29418
at com.google.gerrit.sshd.SshDaemon.start(SshDaemon.java:290)
at com.google.gerrit.lifecycle.LifecycleManager.start(LifecycleManager.java:74)
at com.google.gerrit.pgm.Daemon.start(Daemon.java:258)
at com.google.gerrit.pgm.Daemon.run(Daemon.java:186)
at com.google.gerrit.pgm.util.AbstractProgram.main(AbstractProgram.java:63)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at com.google.gerrit.launcher.GerritLauncher.invokeProgram(GerritLauncher.java:169)
at com.google.gerrit.launcher.GerritLauncher.mainImpl(GerritLauncher.java:93)
at com.google.gerrit.launcher.GerritLauncher.main(GerritLauncher.java:50)
at Main.main(Main.java:25)
Caused by: java.net.BindException: Address already in use
at sun.nio.ch.Net.bind0(Native Method)
at sun.nio.ch.Net.bind(Net.java:444)
at sun.nio.ch.Net.bind(Net.java:436)
Although my gerrit code review site is working fine but the gitweb option is not able to fetch the details from backend. Please suggest.
And thanks in advance for your help:)
The error message:
Address already in use
tells that there is already a service bound to port 29418 This prevents Gerrit's SSH daemon from starting up because it uses port 29418 by default.
You should check what is using that port, and stop it if possible, or configure Gerrit to listen to SSH on a different port. You can do the latter by setting sshd.listenAddress in the site's etc/gerrit.config file.
I have configured JRebel remoting mode in an Eclipse maven project on a Windows Machine, and running WebSphere in a Linux docker container.
In JVM args, it's setting
-agentpath:/opt/jrebel/lib/libjrebel64.dll -Drebel.remoting_plugin=true
When I change source code, jrebel start updating code, and I got the error:
2018-02-27 23:32:14.066 ERROR [rebel-CancellableExecutorService-1] c.z.jrebel.remoting.Transaction - [OUT] [tr_36] [Project <maven-module-name>, server websphere] Synchronization failed! Read timed out
com.zeroturnaround.jrebel.remoting.RemotingException: Read timed out
at com.zeroturnaround.jrebel.remoting.net.RemotingClient.tryMakePostRequest(JRebelRemoting:189)
at com.zeroturnaround.jrebel.remoting.net.RemotingClient.sendTransactionCommand(JRebelRemoting:147)
at com.zeroturnaround.jrebel.remoting.net.RemotingClient.commitTransaction(JRebelRemoting:101)
at com.zeroturnaround.jrebel.remoting.Transaction.commit(JRebelRemoting:487)
at com.zeroturnaround.jrebel.remoting.Transaction.synchronize(JRebelRemoting:231)
at com.zeroturnaround.jrebel.remoting.RemoteServer$1.run(JRebelRemoting:56)
at org.zeroturnaround.common.util.ExecutorUtil$RunnableWrapper.run(ExecutorUtil.java:153)
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
at java.util.concurrent.FutureTask.run(FutureTask.java:266)
at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:180)
at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
at java.lang.Thread.run(Thread.java:748)
Caused by: java.net.SocketTimeoutException: Read timed out
After that, the web application and WebSphere crashed.
The error message indicates that the connection failed between the IDE and the WebSphere application server running inside your Linux Docker container.
Firstly, if you are starting your WebSphere server on a Linux machine, you should use the JRebel's agent library compiled for Linux. That is, you should use libjrebel64.so in the -agentpath argument's path value instead of libjrebel64.dll. Using the .dll in Linux environment should crash the server on startup. Currently, my hypothesis is that the server does not respond since it does not even start up correctly.
Additionally, please make sure that the server is reachable via the address you entered in the remote server configuration on the IDE side.
If the same issue persists after the previous suggestions, please do reproduce this issue and send us the jrebel.log and jrebel-eclipse.log files from ~/.jrebel/ directory to support#zeroturnaround.com.
At my Neo4j 3.1.3/SDN 4 project from time to time I'm facing with a following Neo4j exception:
Caused by: java.lang.RuntimeException: org.neo4j.ogm.exception.TransactionException: Could not apply the transaction to the store after written to log
at org.neo4j.ogm.drivers.bolt.request.BoltRequest.executeRequest(BoltRequest.java:175)
at org.neo4j.ogm.drivers.bolt.request.BoltRequest.execute(BoltRequest.java:89)
at org.neo4j.ogm.autoindex.AutoIndexManager.assertIndexes(AutoIndexManager.java:187)
at org.neo4j.ogm.autoindex.AutoIndexManager.build(AutoIndexManager.java:92)
at org.neo4j.ogm.session.SessionFactory.<init>(SessionFactory.java:45)
at org.neo4j.ogm.session.SessionFactory.<init>(SessionFactory.java:93)
at com.example.domain.api.configuration.Neo4jConfig.sessionFactory(Neo4jConfig.java:38)
at com.example.domain.api.configuration.Neo4jConfig$$EnhancerBySpringCGLIB$$bcccfdf9.CGLIB$sessionFactory$2(<generated>)
at com.example.domain.api.configuration.Neo4jConfig$$EnhancerBySpringCGLIB$$bcccfdf9$$FastClassBySpringCGLIB$$e2dbf1bb.invoke(<generated>)
at org.springframework.cglib.proxy.MethodProxy.invokeSuper(MethodProxy.java:228)
at org.springframework.context.annotation.ConfigurationClassEnhancer$BeanMethodInterceptor.intercept(ConfigurationClassEnhancer.java:358)
at com.example.domain.api.configuration.Neo4jConfig$$EnhancerBySpringCGLIB$$bcccfdf9.sessionFactory(<generated>)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:497)
at org.springframework.beans.factory.support.SimpleInstantiationStrategy.instantiate(SimpleInstantiationStrategy.java:162)
I use Bolt driver in order to connect to Neo4j.
In order to solve this situation I have to restart my Neo4j server and also I have to restart my application(restart Tomcat server).
Is it possible to configure my Bolt driver/datasource.. etc in order to get my application up and running with no needs to restart the application itself.. only restart neo4j server ?
Not sure this is related to OGM, it rather looks a problem on the db side.
Maybe report this on the neo4j gitub with relevant db logs.
Disabling index checks at application startup might help.
This can be done by removing indexes.auto entry from ogm.properties file (or equivalent java config).
see http://neo4j.com/docs/ogm-manual/current/reference/#reference:indexing
I have setup a master on Ubuntu machine and want to create a salve on Windows 10. While launching the agent I am facing following issue. Can someone please help.
just before slave javed_pc gets launched ...
executing pre-launch scripts ...
[2017-04-21 10:26:54] [windows-slaves] Connecting to 172.26.152.23
Checking if Java exists
java -version returned 1.8.0.
[2017-04-21 10:26:56] [windows-slaves] Copying jenkins-slave.xml
[2017-04-21 10:26:56] [windows-slaves] Copying slave.jar
[2017-04-21 10:26:56] [windows-slaves] Starting the service
ERROR: Unexpected error in launching an agent. This is probably a bug in Jenkins
org.jinterop.dcom.common.JIException: Service Logon Failure
at org.jvnet.hudson.wmi.Win32Service$Implementation.start(Win32Service.java:149)
Caused: java.lang.reflect.InvocationTargetException
at sun.reflect.GeneratedMethodAccessor206.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at org.kohsuke.jinterop.JInteropInvocationHandler.invoke(JInteropInvocationHandler.java:140)
Caused: java.lang.reflect.UndeclaredThrowableException
at com.sun.proxy.$Proxy64.start(Unknown Source)
at hudson.os.windows.ManagedWindowsServiceLauncher.launch(ManagedWindowsServiceLauncher.java:342)
at hudson.slaves.SlaveComputer$1.call(SlaveComputer.java:262)
at jenkins.util.ContextResettingExecutorService$2.call(ContextResettingExecutorService.java:46)
at java.util.concurrent.FutureTask.run(FutureTask.java:266)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at java.lang.Thread.run(Thread.java:745)
Using the JENKINS Windows Slaves Plugin, check if one of the reason listed in "Windows slaves fail to start via DCOM" would apply in your case.
It lists a wide variety of reasons, from the Windows account used, to network, registry, security reasons.
Make sure you don't have a proxy issue, where Jenkins would try and use said proxy to access a machine (Windows here) on your LAN: the environment variable no_proxy should be used to exclude your local domain.
The OP Javed Ahmed reports having solve it with:
In 'Configure Global security' settings, when you check 'Enable Security' option, then it allows you to connect via java web start.
Otherwise It was not showing the the option to connect through java web start and connecting via windows service is a pain.
Embarrassingly enough I am one page into Jenkins Continuous Integration Cookbook and I'm already stuck on this command:
Java -jar jenkins.war --httpsPort=8443 --httpPort=-1
On my Mac, this throws up with:
Running from: /home/NAThompson/jenkins/war/target/jenkins.war
webroot: $user.home/.jenkins
Feb 22, 2015 7:37:24 PM winstone.Logger logInternal
INFO: Beginning extraction from war file
Using one-time self-signed certificate
Feb 22, 2015 7:37:24 PM winstone.Logger logInternal
INFO: Winstone shutdown successfully
Feb 22, 2015 7:37:24 PM winstone.Logger logInternal
SEVERE: Container startup failed
java.io.IOException: Failed to start a listener: winstone.HttpsConnectorFactory
at winstone.Launcher.spawnListener(Launcher.java:209)
at winstone.Launcher.<init>(Launcher.java:149)
at winstone.Launcher.main(Launcher.java:354)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:483)
at Main._main(Main.java:293)
at Main.main(Main.java:98)
Caused by: java.lang.NoClassDefFoundError: sun/security/x509/CertAndKeyGen
at winstone.HttpsConnectorFactory.start(HttpsConnectorFactory.java:100)
at winstone.Launcher.spawnListener(Launcher.java:207)
... 8 more
Caused by: java.lang.ClassNotFoundException: sun.security.x509.CertAndKeyGen
at java.net.URLClassLoader$1.run(URLClassLoader.java:372)
at java.net.URLClassLoader$1.run(URLClassLoader.java:361)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.findClass(URLClassLoader.java:360)
at java.lang.ClassLoader.loadClass(ClassLoader.java:424)
at java.lang.ClassLoader.loadClass(ClassLoader.java:357)
... 10 more
What can I do to get around this? As extraneous info, the server starts just fine using http.
This looks like a known issue with trying to use HTTPS directly from the jenkins.war. Some have suggested running Jenkins from within Tomcat and letting Tomcat handle SSL (I've not tried this personally yet, however).
I fixed this issue for myself by setting Jenkins to run using Java 7. I am running it as a service so I did this by editing the jenkins-runner.sh file. I added the following line:
export JAVA_HOME="/Library/Java/JavaVirtualMachines/jdk1.7.0_25.jdk/Contents/Home"
and then modified the last two lines to:
echo $JAVA_HOME/bin/java $javaArgs -jar "$war" $args
exec $JAVA_HOME/bin/java $javaArgs -jar "$war" $args
I also made sure to set the httpsKeyStore and httpsKeyStorePassword properties after creating a selfsigned certificate (instructions here under Using SSL: Installing and Configuring Jenkins)
First, I would not recommend running Jenkins within a Mac environment unless of course you are developing for the Mac/IOS. In that case, you have an error with Java installation and/or configs. The real error is ClassNotFoundException: sun.security.x509.CertAndKeyGen. You should verify your version of Java with the requirements of the version of Jenkins you are using. I read a few blog articles that hinted that it is likely a discrepancy with the Java version you (Mac OS) is running.
Secondly, it is highly unlikely that you will ever use Mac for your CI needs. You should really look into running local virtual machines that will mimic your CI environments. You can get started easily with open source tools like VirtualBox and Vagrant.