Cannot start additional MethodServer/BackgroundMethodServer

[bbailey]

Hi All,

I am attempting to add additional MethodServers and one
BackgroundMethodServer to an VM running 10.1 M030 under Windows Server 2003
on an ESX cluster. This VM has been cloned from a different cluster and
the WC instance re-hosted by an ant script. As long a single MS is used,
all is well. However, when I attempt to add multiple MS/BMS's, the first
MS starts OK, but any others briefly flash a window and die. No logs are
written for the failed MS/BMS instances. The server manager log shows a
time out and attempts to restart the failed MS/BMS repeatedly.

Interestingly, there appears to be a race condition. If a BMS instance
starts first, the BMS lives and the MS dies. If the MS invokes first, the
BMS, WC comes on up.

I dug through the PTC Knowledge base and saw some similar behavior related
to Java libraries, but in those cases, no MS/BMS seemed to invoke at all.
Has anyone seen anything similar?

Thanks,

Ben

[pyalavarthi]

Hi Ben,
Check the memory heap settings and see if there is enough memory to
bring up 3 servers. Most common issue I have seen when MS doesn't come
without any log is insufficient memory.
wt.method.maxHeap,wt.method.minHeap

Regards,
Prathap <">http://goo.gl/LuT5>

[bbailey]

In Reply to Prathap Yalavarthi:

Hi Prathap,

Good suggestion. Actually, there was plenty of RAM. Turns out the WC instance was set up to allow a remote Java debugger to attach. Seems that when this is the case, only one MS and no BMS is allowed. The details can be found in CS96048. The offending property setting was:

Once I commented that out, all was well.

Ben

Hi Ben,
Check the memory heap settings and see if there is enough memory to
bring up 3 servers. Most common issue I have seen when MS doesn't come
without any log is insufficient memory.
wt.method.maxHeap,wt.method.minHeap

Regards,
Prathap <

[jessh]

Actually it's simpler than this. If you configure for debugging you
have to ensure that each process you configure for debugging gets its
own unique debugging address (socket or shared memory block, depending
on the debug transport you've selected).

There are a variety of ways of achieving this through use of {0} or {3}
substitutions. See Javadoc for wt.manager.BaseServerLauncher for more
details.