Setting up each coldfusion server instance as a Windows service using its own jvm.config. Using the debugger with multiple coldfusion server instances causes errors unless you specify a separate debugger port in a unique jvm.config file for each instance.
First Note: If you can live with having no server instances running when you initially start windows, you can just start your cf server instance using the command line, with the -config option pointing to a custom config. The rest of this article focuses on setting up multiple jvm.configs, each coldfusion instance having a different jvm.config, and setup as a Windows services that can automatically start in windows.
jrun -config jvm.config_new_server -start default
After getting the following error repeatedly, I decided to stop putting up with running multiple coldfusion instances from one jvm.config file.
FATAL ERROR in native method: JDWP No transports initialized,
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
This error stemmed from me having multiple Coldfusion server instances, and every time I started one it would throw errors that a port was already in use (The debugger port). All my instances were setup to use the same debugger port, since they all used the same jvm.config file. I got sick of remembering to stop debugging services, or edit the JVM.config to not run the debugger each time I started a different CF Instance. Obviously there are many reasons for using separate jvm.configs, notably for allocating memory resources and settings to be shared more efficiently. Here is my step-by-step process for setting up multiple coldfusion server instances to run with multiple jvm.config xml files.
Note: If you use debugging with the default server, but do not change the default server instance to use its own jvm.config, from what I can tell, it still starts up fine, even though a port in use error shows up. I think this is because the admin server and the default instance server are both using the default jvm.config, but the admin server must not really cause enough of a clash to prevent the default instance from starting, since the admin server probably does not do that much with the debugger port. I need to explore what exactly the admin instance does. It is not as full blown as the other instances, and it must just serve as a shell or base that manages the other instances.
1)Go to Windows Admin Tools -> Services. Locate the name of Coldfusion Instances that are running as services. On my computer, these services show up as “Macromedia JRun Admin Server”, “Macromedia JRun CFusion Server” (The default instance, which for me was called cfusion) and “Adobe Coldfusion 8 AS cfusion2” (I set up another server instance called ‘cfusion2’). You need to remove all services for which you want to have a debugger. This way, you can remake the service with the option to use a specific and custom JVM. For example, you could have all instances use the default jvm.config, except for one.
2)Remove the non-default services that aren’t configured to use a custom JVM (unless you want the services already installed to just use the default JVM). Do this by using the jrunsvc.exe from the command line. Same folder as the default jvm.config. For me this was c:\JRun4\bin. So once you know the name of the services you want to remove, the command goes like this:
jrunsvc -remove “Adobe Coldfusion 8 AS cfusion2”
Don’t forget the quotes if there are spaces in the Service Name.
3)Install the instances as services, each one using the -config option to point to a custom JVM.config of your creation. Here are the commands I issued:
I left the default instance alone, and made the default JVM config contain the settings I wanted for the first and default instance (jvm.config). Here is the command for installing the second coldfusion instance as a service with a config file cfusion2.jvm.config:
the coldfusion server instance cfusion2” -config C:\Jrun4\bin\cfusion2jvm.config
And if you had a third instance, you could do
the coldfusion server instance cfusion3” -config C:\Jrun4\bin\cfusion3jvm.config
I know, very original naming. The install option is followed by 3 namings for the new service of my server instance. I think these are 1)service name 2)service display name 3)service description. These are arbitrary names and descriptions that the jrunsvc command has you set.
Note: I originally had the config option point to -config cfusion3jvm.config, but my service wasn’t getting my debugger port started, and I think it may have been using the jvm.config instead of the custom one. I changed -config cfusion3jvm.config to -config C:\Jrun4\bin\cfusion3jvm.config and it worked fine. Maybe I didn’t need to do that and I was just missing something though.
Note: If you try and start the service and get the ‘Windows could not start the service … review the System Event log … refer to service-specific error code 4″, or windows does not start the service, look in the event log (Admin Tools -> Event Viewer->System) and you’ll see the error from the Service Control Manager. The service-specific error is less than useful, but for me this meant that I did not get the path or the filename correct to the config file when I created the service.
4)If you specify different debugger ports for each CF instance, setup up a different debugger in your IDE for each CF instance, since one debugger can’t run on two ports (I would assume). This goes for anything else. If you configure different things in each JVM, you have to configure anything using the different instance settings to correspond.
Of course, if you don’t want to deal with all these services, and no server instances are running when you initally start windows, you can just start your cf server instance using the command line, with the -config option pointing to a custom config.
I think it is nice to have my 2 instances (soon 3 or 4), one for each dev environment, start up on their own when windows loads, each using a different port for a debugger. Too many instances running can really eat resources though.