Home » Language IDEs » ServerTools (WTP) » Tomcat and remote debugger configuration problem(can't stop server if remote debugger port is configured over VM arguments in server launch configuration)
| |
| Re: Tomcat and remote debugger configuration problem [message #1097442 is a reply to message #1096554] |
Thu, 29 August 2013 18:32   |
 Larry Isaacs
Messages: 1354
Registered: July 2009 |
Senior Member |
|
|
On 8/28/2013 11:53 AM, Anton Meller wrote:
> Hello!
>
> I am trying to configure tomcat 7 server in eclipse to be able to
> connect remote debugger to running web application. In general it is
> really simple and is good described on this page
> hppt_wiki.apache.org/tomcat/FAQ/Developing#Q2. So I have edited launch
> configuration linked on the server settings view and added following VM
> arguments "-Xdebug
> -Xrunjdwp:transport=dt_socket,address=8000,server=y,suspend=n" to other
> automatic generated parameters. It works basically so the server can be
> started, the application runs as expected, and I can attach remote
> debugger to the application if I need it and detach if later. The only
> problem is I can't stop the server using the stop button on the Servers
> view or with the stop command from the server context menu. If I click
> on "stop" than some seconds later small message box with the text
> "Server <servername> is not responding. Do you want to terminate this
> server? Click OK to terminate the server or click Cancel to continue
> waiting" opens up. At the same time I can see following error in the
> console view:
> FATAL ERROR in native method: JDWP No transports initialized,
> jvmtiError=AGENT_ERROR_TRANSPORT_INIT(197)
> ERROR: transport error 202: bind failed: Address already in use
> ERROR: JDWP Transport dt_socket failed to initialize, TRANSPORT_INIT(510)
> JDWP exit error AGENT_ERROR_TRANSPORT_INIT(197): No transports
> initialized [../../../src/share/back/debugInit.c:690]
>
> I have searched the web for solutions or explanation why this error
> happens and the best description was here
> hppt_stackoverflow.com/questions/1096642/tomcat-failed-to-shutdown/8216921.
> But this thread in not eclipse related and the suggestion is to set
> desired VM parameters using CATALINA_OPTS instead of JAVA_OPTS and in
> eclipse server settings or launch configuration I can't find any
> equivalent thing to CATALINA_OPTS.
>
> Do anybody know a way to configure Tomcat in Eclipse so that remote
> debugging works and the server can be stopped without errors or killing
> the server process?
>
> P.S. I am aware of the possibility to start Tomcat in debugger mode but
> this is not what I need for different reasons.
>
> Thank you.
I believe the problem in your use case is that the Tomcat support
launches separate processes to start and stop Tomcat. This causes an
issue because there isn't support for adding separate startup and
shutdown VM arguments to the launch. All extra VM arguments you add are
preserved, but are used for both startup and shutdown. So it would seem
that with your added arguments, you are unintentionally trying to debug
the stop process and failing due to "Address already in use".
After trying to stop Tomcat and getting an error, you should be able to
switch to the Debug perspective and in the Debug view, see the launch
instance for the "stop" request. Right-click on the first child of the
"stop" launch and select Properties. That will display a dialog that
shows the full Java command the launch tried to execute. You may be
able to handcraft some other launch that duplicates this Java command,
minus the extra arguments. Running that launch would command Tomcat to
shutdown, letting it shutdown gracefully. When the process executing
Tomcat terminates, I believe that Eclipse Servers view would detect that
and show the server in the "stopped" state.
The only other way I can think of to address this is to patch the Tomcat
plug-in to filter your extra arguments from the "stop" command. This is
currently being done for some "com.sun.management" properties to avoid
this kind of problem when using JMX. HTH.
Cheers,
Larry
|
|
|
| Re: Tomcat and remote debugger configuration problem [message #1097979 is a reply to message #1097442] |
Fri, 30 August 2013 12:26 |
Anton Meller
Messages: 3
Registered: August 2013 |
Junior Member |
|
|
Larry Isaacs wrote on Thu, 29 August 2013 14:32
I believe the problem in your use case is that the Tomcat support
launches separate processes to start and stop Tomcat. This causes an
issue because there isn't support for adding separate startup and
shutdown VM arguments to the launch. All extra VM arguments you add are
preserved, but are used for both startup and shutdown. So it would seem
that with your added arguments, you are unintentionally trying to debug
the stop process and failing due to "Address already in use".
Yes, this is exactly what happens. Sorry for not have provided short summary from the linked stackoverflow-thread in my original post.
Larry Isaacs wrote on Thu, 29 August 2013 14:32
After trying to stop Tomcat and getting an error, you should be able to
switch to the Debug perspective and in the Debug view, see the launch
instance for the "stop" request. Right-click on the first child of the
"stop" launch and select Properties. That will display a dialog that
shows the full Java command the launch tried to execute. You may be
able to handcraft some other launch that duplicates this Java command,
minus the extra arguments. Running that launch would command Tomcat to
shutdown, letting it shutdown gracefully. When the process executing
Tomcat terminates, I believe that Eclipse Servers view would detect that
and show the server in the "stopped" state.
Thank you! Your suggestion works. Basically it is how we stops OC4J now, but I had no idea how to identify right main class or program arguments for Tomcat.
Larry Isaacs wrote on Thu, 29 August 2013 14:32
The only other way I can think of to address this is to patch the Tomcat
plug-in to filter your extra arguments from the "stop" command. This is
currently being done for some "com.sun.management" properties to avoid
this kind of problem when using JMX. HTH.
Larry
I would try to make a patch, but have no idea where to start. I have already installed source-versions of some plugins as describer here: http://wiki.eclipse.org/WTP_FAQ#How_do_I_install_WTP_Source.2C_after_I.27ve_installed_the_Eclipse_IDE_for_Java_EE_Developers.3F, but don't know where I can see that sources. Than I have downloaded an archived p2 repository of WTP code from here: http://download.eclipse.org/webtools/downloads/drops/R3.3.2/R-3.3.2-20120210195245/ (this is the right version for our eclipse installation), but than again I have no clue what to do with it. There is a short note on the site to install it instead of simply unzipping, but how and where to install???
Darryl Miles wrote on Thu, 29 August 2013 11:36
Check "netstat -p tcp -na" (on windows) for an existing TCP service on that port, maybe a left over Tomcat instance still running from a previous session ?
Or maybe you have 2 JVMs running in debug mode (like testing between 2 networked containers) and so that port is already in use for one of those JVMs ?
Try changing the address=8000 part, it is arbitrary, a common agreement between Tomcat JVM process and Eclipse IDE debugger UI.
Usually you start tomcat from Views -> Servers with the "Debug" and Eclipse automatically adds the options for -Xdebug and -Xrunjdwp. I would hope Eclipse is smart enough to either check for an available free TCP port number or know it has 2 JVMs running inside the same IDE and automatically use 8001 for the 2nd JVM that is started.
Thank you for your help, but in this case your assumptions was wrong. Larry have provided the right explanation. And as already mentioned I know how to start the server in debug mode but it is not always practical because this debug mode can not be arbitrary switched on and off as it is possible with remote debugger. In practice my local server is often running for a hour or two because I am testing some things before I wish to debug some special case. With your suggestion I would need to stop the server first and than restart it in debug mode and with our application it takes over 2 minutes because of relatively slow network connection to remote database server.
[Updated on: Fri, 30 August 2013 12:27] Report message to a moderator |
|
|
| Re: Tomcat and remote debugger configuration problem [message #1098978 is a reply to message #1097979] |
Sun, 01 September 2013 00:49 |
Larry Isaacs
Messages: 1354
Registered: July 2009 |
Senior Member |
|
|
On 8/30/2013 8:26 AM, Anton Meller wrote:
<snip/>
> Larry Isaacs wrote on Thu, 29 August 2013 14:32
>> The only other way I can think of to address this is to patch the
>> Tomcat plug-in to filter your extra arguments from the "stop"
>> command. This is currently being done for some "com.sun.management"
>> properties to avoid this kind of problem when using JMX. HTH.
>> Larry
>
> I would try to make a patch, but have no idea where to start. I have
> already installed source-versions of some plugins as describer here:
> http://wiki.eclipse.org/WTP_FAQ#How_do_I_install_WTP_Source.2C_after_I.27ve_installed_the_Eclipse_IDE_for_Java_EE_Developers.3F,
> but don't know where I can see that sources. Than I have downloaded an
> archived p2 repository of WTP code from here:
> http://download.eclipse.org/webtools/downloads/drops/R3.3.2/R-3.3.2-20120210195245/
> (this is the right version for our eclipse installation), but than again
> I have no clue what to do with it. There is a short note on the site to
> install it instead of simply unzipping, but how and where to install???
<snip/>
These are the steps to install the WTP source in a way that is useful
for the "patching" process that follows:
1. Execute Help -> Install New Software...
2. Select "The Eclipse Web Tools Platform (WTP) software repository"
3. Expand "Web Tools Platform SDK (WTP SDK) 3.3.2"
4. Select the "JST Server Adapter Plug-in Developer Resources" whose
version begins with "3.3.2.v20111010" and proceed with finishing the
installation. It's Id on the Install Details page needs to be
"org.eclipse.jst.server_adapters.ext.sdk.feature.feature.group", noting
the "ext" present in this string. The wrong "JST Server Adapter Plug-in
Developer Resources" has an Id string that doesn't have the "ext".
The following gives the basic steps to make the patched plug-in. There
are a number of steps, but they are all fairly straightforward.
Phase 1: Create a plug-in project for the plug-in you need to patch.
1. Create a new workspace (recommended) or open an existing one.
2. Select File -> Import...
3. Expand "Plug-in Development", select "Plug-ins and Fragments", then
click Next>.
4. In the "Import As" section, select "Projects with source folders",
then click Next>.
5. Enter (or copy & paste, no quotes)
"org.eclipse.jst.server.tomcat.core" into ID field at the top and click
"Add All->". This should move this one plug-in to the right pane.
6. Click Finish to import the "org.eclipse.jst.server.tomcat.core"
plug-in source into a project.
7. Expand the root of the project and ensure it contains a folder named
"src". You will only get the "src" folder if you have the correct "JST
Server Adapter Plug-in Developer Resources" installed.
Phase 2: Apply the changes needed to fix the plug-in.
1. Open
org.eclipse.jst.server.tomcat.core.internal.TomcatServerBehaviour.java
in an editor window.
2. Near the top of the file there is a JMX_EXCLUDE_ARGS string array.
Add the VM Arguments you need to exclude to the list, i.e. "-XDebug" and
"-Xrunjdwp:transport=".
3. Find where the JMX_EXCLUDE_ARGS is used in the stop() method. You may
have to debug the code to ensure that the mergeArguments() method
correctly excludes the "runjdwp:transport" value and yields a valid list
of arguments. You can debug the changes by right-clicking on the
project and selecting Debug As -> Eclipse Application. Hopefully no
additional changes will be needed.
Phase 3: Create the replacement jar. Due to the approach in Phase 1, the
name of this jar will be identical to your current jar, which simplifies
updating the Eclipse installation.
1. Right-click on the "org.eclipse.jst.server.tomcat.core" project in
the Project Explorer or other navigator view and select Export...
2. Expand "Plug-in Development", select "Deployable plug-ins and
fragments", then click Next>
3. Click the Browse... button next to the Directory selection in the
Destination tab followed by OK. This will set the output directory to
be the same as your workspace.
4. Click Finish to build the replacement plug-in jar. It will appear in
a "plugins" folder under the root of your workspace.
Phase 4: Replace the installed plug-in jar with the fixed version.
1. Exit Eclipse if it is running.
2. Under the "plugins" folder of your Eclipse installation, move or
rename the org.eclipse.jst.server.tomcat.core_1.1.301.v20111010_1242.jar
if you don't want to overwrite it with the patched version. If you have
a different version, it means you aren't using Indigo SR2 and hopefully
you installed the JST Server Adapter Plug-in Developer Resources" that
matched your version.
3. Copy the
org.eclipse.jst.server.tomcat.core_1.1.301.v20111010_1242.jar from the
"plugins" folder under your workspace and paste it to the "plugins"
folder of your Eclipse installation.
You should be able to run Eclipse now with the patched plug-in. Because
the patched jar had the same version number, no additional changes are
needed. The steps above are pretty brief. Also note that the steps
above were copy and pasted from another post I did. I believe I have
updated everything necessary for your use case, but it's possible I
overlooked something. Let me know if something above doesn't make sense.
Cheers,
Larry
|
|
| |
| Re: Tomcat and remote debugger configuration problem [message #1101447 is a reply to message #1100529] |
Wed, 04 September 2013 13:17 |
Larry Isaacs
Messages: 1354
Registered: July 2009 |
Senior Member |
|
|
On 9/3/2013 4:16 AM, Anton Meller wrote:
> Thank you very much for your help, Larry!
>
> With your step by step instruction I had no difficulties creating
> patched plugin. And it works as expected. So we can switch from OC4J to
> Tomcat in our team without much adjustments in our daily development
> process.
>
> The next step would be to fill bug report in eclipse bugzilla. But first
> I have some other tasks to finish I am working on.
>
> The last thing - is it somehow possible for me as a non committer to
> checkout the plugin sources from official source code repository so I
> can see what the pristine version was, can do revert on changed classes,
> and create a patch using eclipse so every other can apply it to the
> same checked out project? With the approach from above the imported
> project has no connection to subversion and it was not really a
> straightforward process to create the patch. And at the end the patch
> can't be applied in a simple manner, because it starts with:
> --- C:/Workspaces/TomcatAdapter/TomcatServerBehaviour_orig.java Fri
> Feb 10 21:47:56 2012
> +++ C:/Workspaces/TomcatAdapter/TomcatServerBehaviour_modified.java
> Mon Sep 02 13:17:46 2013
>
> With best regards,
> Anton
Once upon a time you could fetch the source from the repository when
importing the plug-in. It used to work when CVS was the repository, but
last I checked, it didn't work now that Git is used as the repository.
For fetching current sources, see if
http://wiki.eclipse.org/WTP_Git_Workflows is enough to see how to fetch
source from the Git repo. The repo you would need is
"git.eclipse.org/gitroot/servertools/webtools.servertools.git" and I
assume use the "git" or "http" protocol instead of "ssh".
Bug 153680 already references the need for separate start and stop
parameters, which I've not yet found cycles to address. Overall, it has
been tough to find cycles to work on the Tomcat support. At this time,
all available WTP cycles are being put toward adding Tomcat 8 support
for WTP 3.6.
Cheers,
Larry
|
|
|
Goto Forum:
Current Time: Fri Apr 19 02:50:48 GMT 2024
Powered by FUDForum. Page generated in 0.02230 seconds |
] 
Search
Help
Register
Login
Home
