0

Environments:

  • Operating system: Mac 10.13.6
  • Java-8
  • Tomcat-7
  • Intellij Community 2019.3
  • Gradle 5.2.1

Command line outputs:

$ export GRADLE_OPTS="-agentlib:jdwp=transport=dt_socket,server=y,suspend=address=5005"
$ ./gradlew myproj-web-java:tomcatRunWar
Listening for transport dt_socket at address: 5005
Starting a Gradle Daemon, 2 incompatible and 2 stopped Daemons could not be reused, use --status for details

Run/Debug Configurations:

Debugger Mode: Attach to remote JVM
Use module classpath: myproj-parent:myproj-web-java:main

Start debugging, and Intellij outputs:

Connected to the target VM, address: 'localhost:5005', transport: 'socket'

I added breakpoint in controller and visit the page via browser. The page rendered correctly, I can see the log outputted in console, but the break point doesn't hit.

If I pause program in Intellij, I can see the stack of main thread:

kevent0:-1, KQueueArrayWrapper (sun.nio.ch)
poll:198, KQueueArrayWrapper (sun.nio.ch)
doSelect:117, KQueueSelectorImpl (sun.nio.ch)
lockAndDoSelect:86, SelectorImpl (sun.nio.ch)
select:97, SelectorImpl (sun.nio.ch)
select:101, SelectorImpl (sun.nio.ch)
read:179, SocketConnection$SocketInputStream (org.gradle.internal.remote.internal.inet)
fill:139, Input (com.esotericsoftware.kryo.io)
require:159, Input (com.esotericsoftware.kryo.io)
readInt:308, Input (com.esotericsoftware.kryo.io)
readSmallInt:120, KryoBackedDecoder (org.gradle.internal.serialize.kryo)
read:139, DefaultSerializerRegistry$TaggedTypeSerializer (org.gradle.internal.serialize)
read:36, Serializers$StatefulSerializerAdapter$1 (org.gradle.internal.serialize)
receive:80, SocketConnection (org.gradle.internal.remote.internal.inet)
receive:75, DaemonClientConnection (org.gradle.launcher.daemon.client)
receive:35, DaemonClientConnection (org.gradle.launcher.daemon.client)
monitorBuild:211, DaemonClient (org.gradle.launcher.daemon.client)
executeBuild:179, DaemonClient (org.gradle.launcher.daemon.client)
execute:142, DaemonClient (org.gradle.launcher.daemon.client)
execute:93, DaemonClient (org.gradle.launcher.daemon.client)
run:52, RunBuildAction (org.gradle.launcher.cli)
execute:207, Actions$RunnableActionAdapter (org.gradle.internal)
execute:402, CommandLineActionFactory$ParseAndBuildAction (org.gradle.launcher.cli)
execute:375, CommandLineActionFactory$ParseAndBuildAction (org.gradle.launcher.cli)
execute:37, ExceptionReportingAction (org.gradle.launcher.cli)
execute:23, ExceptionReportingAction (org.gradle.launcher.cli)
execute:368, CommandLineActionFactory$WithLogging (org.gradle.launcher.cli)
execute:298, CommandLineActionFactory$WithLogging (org.gradle.launcher.cli)
doAction:36, Main (org.gradle.launcher)
run:45, EntryPoint (org.gradle.launcher.bootstrap)
invoke0:-1, NativeMethodAccessorImpl (sun.reflect)
invoke:62, NativeMethodAccessorImpl (sun.reflect)
invoke:43, DelegatingMethodAccessorImpl (sun.reflect)
invoke:498, Method (java.lang.reflect)
runNoExit:60, ProcessBootstrap (org.gradle.launcher.bootstrap)
run:37, ProcessBootstrap (org.gradle.launcher.bootstrap)
main:23, GradleMain (org.gradle.launcher)

There is no my code in main thread or other threads. However, if I check process list, it seems there is no standalone jvm process for tomcat.

And when the program is paused, I can still visit the page while the output in console is paused.

user1633272
  • 2,007
  • 5
  • 25
  • 48
  • Is there a little green 'tick' mark on the breakpoint's circle? It could be that the source code has been updated and no longer matches the class file running in the VM. – BeUndead Mar 09 '20 at 10:56
  • @BeUndead There's only red circle, no green 'tick' mark. The intellij and gradle are running under the same directory, I rebuild the sub project, and Intellij pops up "Loaded classes are up to date, Nothing to reload". – user1633272 Mar 09 '20 at 11:04
  • The lack of a green tick mark means it's not recognising that breakpoint in the VM you have selected. This can be because the class has not been loaded yet, or because the source code does not coincide with what _has_ been loaded into the VM (there are other reasons, for example your code base has multiple files with the same name, but not being loaded into the same VM... But don't do that). – BeUndead Mar 09 '20 at 11:38
  • If you have access to the war/jar/class files which are running on the VM, it might be worth decompiling the class where this breakpoint is to see if it matches. – BeUndead Mar 09 '20 at 11:38
  • @BeUndead maybe GRADLE_OPTS is for gradle itself, not the tomcat plugin. I will try to figure out if it is the case. – user1633272 Mar 09 '20 at 12:03
  • 1
    @BeUndead they are matched, since I changed the log, and the console log show the updated log. – user1633272 Mar 09 '20 at 12:42

1 Answers1

2

With GRADL_OPTS set as such - you are launching debug process for the Gradle daemon itself not for the forked Java process where the Tomcat server actually runs.

You can use Gradle Run/Debug Configuration for starting Tomcat server where you specify the JVM options for the forked process:

enter image description here

The screenshot is taken from this article: Debugging a spring-mvc web-app with the gradle-tomcat-plugin and IntelliJ IDEA

Andrey
  • 15,144
  • 25
  • 91
  • 187