Setting remote debugging in WC 10.1 stops method server on start up

[CJL]

Following the information in eclipse_project.help I added the following to site.xconf:

<property name="wt.manager.cmd.MethodServer.debug.args" overridable="true"&lt;span" style="font-size:" 13px;&quot;=">targetFile="codebase/wt.properties" value="-Xnoagent -Xdebug -Xrunjdwp:transport=dt_socket,address=9000,server=y,suspend=n"/>

When I remove the property from site.xconf, run xconfmanager and restart Windchill everything is fine.

Thanks in advance,

[VivekMadhav]

<property name="wt.manager.cmd.MethodServer.debug.args" overridable="true"&lt;br"/>targetFile="codebase/wt.properties" value="-agentlib:jdwp=transport=dt_socket,address=8000,server=y,suspend=n"/>

Thanks,
Vivek

[jessh]

You've applied the same debug args to multiple method servers
(foreground and background) but only used a single fixed port.

This will result in the first method server getting the port and all
others dieing.

There are a couple of techniques one can apply here. You can vary the
address by start # or such -- a necessary technique if you want multiple
foreground method servers ready for debugging. Alternatively, if you
only have 1 foreground method server you can use the extra.args
variations to apply distinct debug arguments to foreground and
background method servers.

[CJL]

Thanks Jess, I am running 3 foreground method servers. I am unsure on how to specifify the start number in the property. Also is the start number zero based?

[jessh]

You can specify start # by {0}, which starts at 1.

If using transport=dt_socket for debugging -- as you must on UNIX (and
with Eclipse even on Windows as I recall), then you have to take care
that the resulting TCP/IP socket makes sense -- and if you restart too
many times it inevitably won't.

See Javadoc for wt.manager.BaseServerLauncher regarding {3} -- as this
provides a rotating sequence in a configurable range, which can be used
to addressing this issue at least in part. I say "at least in part"
because if you kill enough method servers and some hang indefinitely
then you'll run into issues when the rotation comes back to the ports
held by the hung method servers. That should be less of an issue in the
next MORs -- as the code goes to much greater lengths to kill
unresponsive method servers before trying to start a replacement.

If you're using transport=dt_shmem, which is only available on Windows,
then the address is a symbolic name, so you don't have to worry about
the size of the number generated by {0} and can use something like
"ms{0}" as the address.

--
Jess Holle

[CJL]

I am working with another developer who is on a UNIX box and I switch between UNIX and Windows so dt_socket is our option.

Thanks for the additional information. The Javadoc was most helpful. I setwt.manager.cmd.MethodServer.seq.1.min andwt.manager.cmd.MethodServer.seq.1.max then used {3} with the port number.

We have noticed that method servers get orphaned so generally monitor the results of windchill stop with process explorer then kill any that get left behind.

I am now able to attach a debugger. I am guessing which port I need to attach to may veri after each restart.

Thanks for all your help!

Chris