windows server 2008 support

25 views
Skip to first unread message

booster94

unread,
May 18, 2009, 9:12:14 AM5/18/09
to FusionReactor
Does anyone know if Fusion-Reactor works on Server 2008 x64? I tried
to install it on a new 2008 server we have and after installation CF
would not start. I had to remove Fusion-Reactor and restart the whole
server in order to get CF functioning again.

I thought when I had installed Fusion-Reactor on my other servers it
automatically detected the CF version and path and auto-populated
those selections so that I just had to click next (maybe I'm wrong
about that), but it didn't this time. I had to manually select them.

Afterword, I noticed on the website the system requirements didn't
show 2008 in the support OS list. I guess I made the assumption based
on the fact that when Adobe added x64 support for CF they added it for
2003 and 2008, so when I saw Fusion-Reactor added 64-bit support that
it worked on both platforms too. Maybe that is not correct.

BTW I'm using Fusion-Reactor 3.01.

Bernd Donath [FusionReactor Team]

unread,
May 19, 2009, 7:05:25 AM5/19/09
to FusionReactor
Hi,

FusionReactor should run on Server 2008 x64 if CF8 is running on it.
It is just a Java application and if there is a JVM available for the
target system FusionReactor does (usually) run on the system. What
could be not working is the native library which depends on the system
architecture and not the JVM. However, the native library is only
required for CPU monitoring and getting stack trace for JVMs < 1.5 and
does not affect the other functionality of FusionReactor.

Thread

http://groups.google.com/group/fusionreactor/browse_thread/thread/585f8dc799c2fdbc

provides some more details about possible problems people have seen
when using FusionReactor on Windows 64. As mentioned in this thread
the support articles

http://www.fusion-reactor.com/support/kb/FRS-199.cfm
http://www.fusion-reactor.com/support/kb/FRS-211.cfm

should provide help. If FusionReactor still does not work on your
system please contact us via support email so that we can have a
closer look what is causing the problem here.

Regards,
Bernd

booster94

unread,
May 19, 2009, 9:57:03 AM5/19/09
to FusionReactor
I have seen those articles but all of them seem to indicate the
referenced issues were a problem on 3.0 and corrected in 3.01. Since
I'm using 3.01 I'm confused as to why they may still apply. Also none
of them mention anything about ColdFusion not being able to start back
up after the Fusion-Reactor installation. That's why I was wondering
if the OS (or IIS7) has something to do with that.

On May 19, 7:05 am, "Bernd Donath [FusionReactor Team]"
<bernd_don...@intergral.com> wrote:
> Hi,
>
> FusionReactor should run on Server 2008 x64 if CF8 is running on it.
> It is just a Java application and if there is a JVM available for the
> target system FusionReactor does (usually) run on the system. What
> could be not working is the native library which depends on the system
> architecture and not the JVM. However, the native library is only
> required for CPU monitoring and getting stack trace for JVMs < 1.5 and
> does not affect the other functionality of FusionReactor.
>
> Thread
>
> http://groups.google.com/group/fusionreactor/browse_thread/thread/585...
>
> provides some more details about possible problems people have seen
> when using FusionReactor on Windows 64. As mentioned in this thread
> the support articles
>
> http://www.fusion-reactor.com/support/kb/FRS-199.cfmhttp://www.fusion-reactor.com/support/kb/FRS-211.cfm
>
> should provide help. If FusionReactor still does not work on your
> system please contact us via support email so that we can have a
> closer look what is causing the problem here.
>
> Regards,
> Bernd
>
> On May 18, 3:12 pm, booster94 <corrig...@rochester.rr.com> wrote:
>
>
>
> > Does anyone know if Fusion-Reactor works on Server 2008 x64?  I tried
> > to install it on a new 2008 server we have and after installation CF
> > would not start.  I had to remove Fusion-Reactor and restart the whole
> > server in order to get CF functioning again.
>
> > I thought when I had installed Fusion-Reactor on my other servers it
> > automatically detected the CF version and path and auto-populated
> > those selections so that I just had to click next (maybe I'm wrong
> > about that), but it didn't this time. I had to manually select them.
>
> > Afterword, I noticed on the website the system requirements didn't
> > show 2008 in the support OS list.  I guess I made the assumption based
> > on the fact that when Adobe added x64 support for CF they added it for
> > 2003 and 2008, so when I saw Fusion-Reactor added 64-bit support that
> > it worked on both platforms too.  Maybe that is not correct.
>
> > BTW I'm using Fusion-Reactor 3.01.- Hide quoted text -
>
> - Show quoted text -

charlie arehart

unread,
May 19, 2009, 12:53:23 PM5/19/09
to fusion...@googlegroups.com
While you await a reply from Bernd, I'll toss in that if CF doesn't start,
you should be able to find explanations for that in either the Windows Event
log or in the CF runtime logs (if you're running in Standard or in
Enterprise Server mode, they're in the [cf]/runtime/logs directory. If
you're running Multiserver, they're in the [jrun]/logs directory.)

See what they say, when you try to start CF with FR installed. Or if you
still have those from when you did, what do they say?

/charlie

Bernd Donath [FusionReactor Team]

unread,
May 20, 2009, 11:27:05 AM5/20/09
to FusionReactor
You are right, FRS-211 show(ed) Fix Version/s 3.0.1 which is actually
not true ;-(
I have updated this technote so that starting from tomorrow it shows
'PENDING' instead. Sorry for this.

To actually find the reason for the problem you see I can only repeat
what Charlie said before. If CF does not start with FusionReactor
check your CF logs and also the reactor-0.log file of FusionReactor
([fr]/instance/<your instance>/log directory). Maybe the path to its
configuration file in default-web.xml is not correct?

Regards,
Bernd

On May 19, 6:53 pm, "charlie arehart" <charlie_li...@carehart.org>
wrote:

booster94

unread,
May 21, 2009, 8:03:10 AM5/21/09
to FusionReactor
Thanks for checking into that. At least I know am not going crazy
just yet.

I did grab the error from the runtime event log that occured after the
install when CF wouldn't start. I'm not sure what it means though. I
can't really try this again until I get another maintenance window.
When I originally installed it I wasn't expecting any downtime other
then the brief service restart so I tried to get it done quick first
thing in the morning. Now that I know things might not go perfectly
I'll have to wait until an official maintenance windows so as not to
risk disrupting production.

05/18 07:54:52 info Deploying enterprise application
"Adobe_ColdFusion_8" from: file:/D:/ColdFusion8/
05/18 07:54:52 info Deploying web application "Adobe ColdFusion 8"
from: file:/D:/ColdFusion8/
05/18 07:54:53 user FusionReactor: FusionReactor Rev. 3.0.1, Build: FR-
HEAD.1305.11860
05/18 07:54:53 user FusionReactor: Initializing configuration
05/18 07:54:53 user FusionReactor: Loading configuration from C:
\FusionReactor\instance\coldfusion.cfmx8.rocdmzws04\conf
\reactor.conf...
05/18 07:54:53 user FusionReactor: Configuration loaded.
05/18 07:54:53 user FusionReactor: Checking to see whether the
configuration must be upgraded...
05/18 07:54:53 user FusionReactor: Configuration Upgrader:
Configuration version 3 is current; no action.
05/18 07:54:53 user FusionReactor: Initializing history queues.
05/18 07:54:53 user FusionReactor: Initializing native library.
05/18 07:54:53 user FusionReactor: Initializing subsystems.
05/18 07:54:53 user FusionReactor: Live configuration: FusionReactor
(Intergral IS GmbH - Distribution Configuration - R2)
05/18 07:54:53 user FusionReactor: Initialization complete in 577ms.
05/18 07:54:54 info Removing web application service from servlet
engine service: ColdFusion8#wwwroot
05/18 07:54:54 info Unregistering enterprise application:
file__D__ColdFusion8_#Adobe_ColdFusion_8
05/18 07:54:54 error Deployer Service failed to deploy file:/D:/
ColdFusion8/
* null
[3]java.net.ConnectException: Connection refused: connect
at java.net.PlainSocketImpl.socketConnect(Native Method)
at java.net.PlainSocketImpl.doConnect(PlainSocketImpl.java:333)
at java.net.PlainSocketImpl.connectToAddress(PlainSocketImpl.java:
195)
at java.net.PlainSocketImpl.connect(PlainSocketImpl.java:182)
at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:366)
at java.net.Socket.connect(Socket.java:519)
at java.net.Socket.connect(Socket.java:469)
at java.net.Socket.<init>(Socket.java:366)
at java.net.Socket.<init>(Socket.java:180)
at jrun.naming.JRunNamingContext.connectToNameServer
(JRunNamingContext.java:1345)
at jrun.naming.JRunNamingContext.getRemoteContextProxy
(JRunNamingContext.java:1315)
at jrun.naming.JRunNamingContext.getContextProxy
(JRunNamingContext.java:1135)
at jrun.naming.JRunNamingContext.lookup(JRunNamingContext.java:517)
at jrun.naming.JRunNamingContext.lookup(JRunNamingContext.java:495)
at javax.naming.InitialContext.lookup(InitialContext.java:392)
at jrunx.util.EncContextUtil.initializeENC(EncContextUtil.java:78)
at jrunx.util.EncContextUtil.initializeServerENC(EncContextUtil.java:
52)
at jrun.servlet.WebApplicationService.initializeENC
(WebApplicationService.java:1517)
at jrun.servlet.WebApplicationService.postStart
(WebApplicationService.java:279)
at jrun.ea.EnterpriseApplication.start(EnterpriseApplication.java:
203)
at jrun.deployment.DeployerService.initModules(DeployerService.java:
708)
at jrun.deployment.DeployerService.createWatchedDeployment
(DeployerService.java:243)
at jrun.deployment.DeployerService.deploy(DeployerService.java:428)
at jrun.deployment.DeployerService.handleEvent(DeployerService.java:
382)
at jrunx.kernel.JRunServiceDeployer.fireEvent
(JRunServiceDeployer.java:710)
at jrunx.kernel.JRunServiceDeployer.deployServices
(JRunServiceDeployer.java:111)
at jrunx.kernel.DeploymentService.loadServices(DeploymentService.java:
46)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke
(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke
(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at com.sun.jmx.mbeanserver.StandardMBeanIntrospector.invokeM2
(StandardMBeanIntrospector.java:93)
at com.sun.jmx.mbeanserver.StandardMBeanIntrospector.invokeM2
(StandardMBeanIntrospector.java:27)
at com.sun.jmx.mbeanserver.MBeanIntrospector.invokeM
(MBeanIntrospector.java:208)
at com.sun.jmx.mbeanserver.PerInterface.invoke(PerInterface.java:120)
at com.sun.jmx.mbeanserver.MBeanSupport.invoke(MBeanSupport.java:262)
at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.invoke
(DefaultMBeanServerInterceptor.java:836)
at com.sun.jmx.mbeanserver.JmxMBeanServer.invoke(JmxMBeanServer.java:
761)
at jrunx.kernel.JRun.startServer(JRun.java:575)
at jrunx.kernel.JRun.<init>(JRun.java:493)
at jrunx.kernel.JRun$1.run(JRun.java:346)
at java.security.AccessController.doPrivileged(Native Method)
at jrunx.kernel.JRun.start(JRun.java:343)
at jrunx.kernel.JRun.startByNTService(JRun.java:427)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke
(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke
(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at jrunx.kernel.JRun.invoke(JRun.java:180)
at jrunx.kernel.JRun.main(JRun.java:168)
[2]javax.naming.ServiceUnavailableException: The connection to the
remote JNDI server on host localhost at port 2930 has failed (as have
all backup hosts listed, if any) - please verify that the server is
running and the NamingService is available [Root exception is
java.net.ConnectException: Connection refused: connect]
at jrun.naming.JRunNamingContext.connectToNameServer
(JRunNamingContext.java:1349)
at jrun.naming.JRunNamingContext.getRemoteContextProxy
(JRunNamingContext.java:1315)
at jrun.naming.JRunNamingContext.getContextProxy
(JRunNamingContext.java:1135)
at jrun.naming.JRunNamingContext.lookup(JRunNamingContext.java:517)
at jrun.naming.JRunNamingContext.lookup(JRunNamingContext.java:495)
at javax.naming.InitialContext.lookup(InitialContext.java:392)
at jrunx.util.EncContextUtil.initializeENC(EncContextUtil.java:78)
at jrunx.util.EncContextUtil.initializeServerENC(EncContextUtil.java:
52)
at jrun.servlet.WebApplicationService.initializeENC
(WebApplicationService.java:1517)
at jrun.servlet.WebApplicationService.postStart
(WebApplicationService.java:279)
at jrun.ea.EnterpriseApplication.start(EnterpriseApplication.java:
203)
at jrun.deployment.DeployerService.initModules(DeployerService.java:
708)
at jrun.deployment.DeployerService.createWatchedDeployment
(DeployerService.java:243)
at jrun.deployment.DeployerService.deploy(DeployerService.java:428)
at jrun.deployment.DeployerService.handleEvent(DeployerService.java:
382)
at jrunx.kernel.JRunServiceDeployer.fireEvent
(JRunServiceDeployer.java:710)
at jrunx.kernel.JRunServiceDeployer.deployServices
(JRunServiceDeployer.java:111)
at jrunx.kernel.DeploymentService.loadServices(DeploymentService.java:
46)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke
(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke
(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at com.sun.jmx.mbeanserver.StandardMBeanIntrospector.invokeM2
(StandardMBeanIntrospector.java:93)
at com.sun.jmx.mbeanserver.StandardMBeanIntrospector.invokeM2
(StandardMBeanIntrospector.java:27)
at com.sun.jmx.mbeanserver.MBeanIntrospector.invokeM
(MBeanIntrospector.java:208)
at com.sun.jmx.mbeanserver.PerInterface.invoke(PerInterface.java:120)
at com.sun.jmx.mbeanserver.MBeanSupport.invoke(MBeanSupport.java:262)
at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.invoke
(DefaultMBeanServerInterceptor.java:836)
at com.sun.jmx.mbeanserver.JmxMBeanServer.invoke(JmxMBeanServer.java:
761)
at jrunx.kernel.JRun.startServer(JRun.java:575)
at jrunx.kernel.JRun.<init>(JRun.java:493)
at jrunx.kernel.JRun$1.run(JRun.java:346)
at java.security.AccessController.doPrivileged(Native Method)
at jrunx.kernel.JRun.start(JRun.java:343)
at jrunx.kernel.JRun.startByNTService(JRun.java:427)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke
(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke
(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at jrunx.kernel.JRun.invoke(JRun.java:180)
at jrunx.kernel.JRun.main(JRun.java:168)
Caused by: java.net.ConnectException: Connection refused: connect
at java.net.PlainSocketImpl.socketConnect(Native Method)
at java.net.PlainSocketImpl.doConnect(PlainSocketImpl.java:333)
at java.net.PlainSocketImpl.connectToAddress(PlainSocketImpl.java:
195)
at java.net.PlainSocketImpl.connect(PlainSocketImpl.java:182)
at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:366)
at java.net.Socket.connect(Socket.java:519)
at java.net.Socket.connect(Socket.java:469)
at java.net.Socket.<init>(Socket.java:366)
at java.net.Socket.<init>(Socket.java:180)
at jrun.naming.JRunNamingContext.connectToNameServer
(JRunNamingContext.java:1345)
... 40 more
[1]jrunx.util.EnvironmentNamingContextException
at jrunx.util.EncContextUtil.initializeENC(EncContextUtil.java:95)
at jrunx.util.EncContextUtil.initializeServerENC(EncContextUtil.java:
52)
at jrun.servlet.WebApplicationService.initializeENC
(WebApplicationService.java:1517)
at jrun.servlet.WebApplicationService.postStart
(WebApplicationService.java:279)
at jrun.ea.EnterpriseApplication.start(EnterpriseApplication.java:
203)
at jrun.deployment.DeployerService.initModules(DeployerService.java:
708)
at jrun.deployment.DeployerService.createWatchedDeployment
(DeployerService.java:243)
at jrun.deployment.DeployerService.deploy(DeployerService.java:428)
at jrun.deployment.DeployerService.handleEvent(DeployerService.java:
382)
at jrunx.kernel.JRunServiceDeployer.fireEvent
(JRunServiceDeployer.java:710)
at jrunx.kernel.JRunServiceDeployer.deployServices
(JRunServiceDeployer.java:111)
at jrunx.kernel.DeploymentService.loadServices(DeploymentService.java:
46)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke
(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke
(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at com.sun.jmx.mbeanserver.StandardMBeanIntrospector.invokeM2
(StandardMBeanIntrospector.java:93)
at com.sun.jmx.mbeanserver.StandardMBeanIntrospector.invokeM2
(StandardMBeanIntrospector.java:27)
at com.sun.jmx.mbeanserver.MBeanIntrospector.invokeM
(MBeanIntrospector.java:208)
at com.sun.jmx.mbeanserver.PerInterface.invoke(PerInterface.java:120)
at com.sun.jmx.mbeanserver.MBeanSupport.invoke(MBeanSupport.java:262)
at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.invoke
(DefaultMBeanServerInterceptor.java:836)
at com.sun.jmx.mbeanserver.JmxMBeanServer.invoke(JmxMBeanServer.java:
761)
at jrunx.kernel.JRun.startServer(JRun.java:575)
at jrunx.kernel.JRun.<init>(JRun.java:493)
at jrunx.kernel.JRun$1.run(JRun.java:346)
at java.security.AccessController.doPrivileged(Native Method)
at jrunx.kernel.JRun.start(JRun.java:343)
at jrunx.kernel.JRun.startByNTService(JRun.java:427)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke
(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke
(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at jrunx.kernel.JRun.invoke(JRun.java:180)
at jrunx.kernel.JRun.main(JRun.java:168)
[0]jrun.deployment.DeploymentException: Deployer Service failed to
deploy file:/D:/ColdFusion8/
* null
at jrun.deployment.DeployerService.createWatchedDeployment
(DeployerService.java:316)
at jrun.deployment.DeployerService.deploy(DeployerService.java:428)
at jrun.deployment.DeployerService.handleEvent(DeployerService.java:
382)
at jrunx.kernel.JRunServiceDeployer.fireEvent
(JRunServiceDeployer.java:710)
at jrunx.kernel.JRunServiceDeployer.deployServices
(JRunServiceDeployer.java:111)
at jrunx.kernel.DeploymentService.loadServices(DeploymentService.java:
46)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke
(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke
(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at com.sun.jmx.mbeanserver.StandardMBeanIntrospector.invokeM2
(StandardMBeanIntrospector.java:93)
at com.sun.jmx.mbeanserver.StandardMBeanIntrospector.invokeM2
(StandardMBeanIntrospector.java:27)
at com.sun.jmx.mbeanserver.MBeanIntrospector.invokeM
(MBeanIntrospector.java:208)
at com.sun.jmx.mbeanserver.PerInterface.invoke(PerInterface.java:120)
at com.sun.jmx.mbeanserver.MBeanSupport.invoke(MBeanSupport.java:262)
at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.invoke
(DefaultMBeanServerInterceptor.java:836)
at com.sun.jmx.mbeanserver.JmxMBeanServer.invoke(JmxMBeanServer.java:
761)
at jrunx.kernel.JRun.startServer(JRun.java:575)
at jrunx.kernel.JRun.<init>(JRun.java:493)
at jrunx.kernel.JRun$1.run(JRun.java:346)
at java.security.AccessController.doPrivileged(Native Method)
at jrunx.kernel.JRun.start(JRun.java:343)
at jrunx.kernel.JRun.startByNTService(JRun.java:427)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke
(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke
(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at jrunx.kernel.JRun.invoke(JRun.java:180)
at jrunx.kernel.JRun.main(JRun.java:168)

On May 20, 11:27 am, "Bernd Donath [FusionReactor Team]"
> > if the OS (or IIS7) has something to do with that.- Hide quoted text -

booster94

unread,
May 21, 2009, 8:10:44 AM5/21/09
to FusionReactor
One other note. I did get that prompt described in FRS-211 and I did
download it. I don't remember clicking the Locate button and
selecting anything. I thought I just continued on its own after the
download completed , but I guess I don't remeber clearly enough to say
for sure.

Also I see you updated the FRS-211 article to show "Pending: under the
"fixed version" field however the "resolution" field still shows
"Fixed" which may be confusing to others.

On May 20, 11:27 am, "Bernd Donath [FusionReactor Team]"
> > if the OS (or IIS7) has something to do with that.- Hide quoted text -

charlie arehart

unread,
May 21, 2009, 11:56:46 AM5/21/09
to fusion...@googlegroups.com
"Booster", I have some thoughts.

The first error message is the one referring to this:

Connection refused: connect

That means there's a port conflict. In other words, something in the CF
startup wants to point to and use a port, but it can't because it's already
in use.

Now, one "might" presume that this must be related to FR, since that's what
you were changing, but not necessarily. It could just be that any restart of
CF would have experienced this. And it may be that it was just a timing
thing, and that a subsequent restart (with or without the FR update) would
not see the port conflict.

Info later in the log shows more detail:

javax.naming.ServiceUnavailableException: The connection to the
remote JNDI server on host localhost at port 2930 has failed (as have
all backup hosts listed, if any) - please verify that the server is
running and the NamingService is available [Root exception is
java.net.ConnectException: Connection refused: connect

Now, if you were running CF Enterprise in the multiserver (multiple
instance) mode of deployment of CF, I would have asserted that you had
another instance running (even the Admin instance, which many never notice),
and it was still holding that port. But your log shows reference to
c:\Coldfusion8, so that tells us you're running either Standard or
Enterprise in the Server mode, so there couldn't be another "instance"
running.

But, I have seen cases where even though you thought CF was down, it wasn't
completely. It would have been interesting if, in this instance, you could
have looked to see if you had another jrun.exe listed in the running
processes (whether before or after this startup attempt failed). It's too
late to know now. Just keep it in mind for next time.

Frankly, what I'd do if I was in your shoes is, during that scheduled outage
time, first stop and start CF as is (without the FR change), to confirm that
it restarts as expected even without any change. It could be that there's an
issue where your stop doesn't really stop. In that respect, I'd also propose
you stop it however you stopped it that last time (whether stopping the
service, running a command line command, etc.)

If it stops and starts ok, then do the FR upgrade, which will offer to
restart CF, or you can stop it yourself. In fact, this makes a point: if
FR's installation wizard stops it (at your ok), I don't know what mechanism
it uses. Maybe an Intergral rep can speak here. Does it stop the service?
Does it kill the task? Maybe whatever it did was what kept CF from really
coming down. Or maybe it just didn't wait long enough. Maybe they have some
timer where, if it doesn't stop in the given time, it tries to start anyway.

That would certainly explain what may have happened. Can you confirm, when
you did the previous attempt, did you let FR's installer do the restart?

Now that I think of it, I've seen instances on my own where stopping CF
often takes a long time, and when I look in the CF runtime log, it shows
that during the stop it was also conflicting with that same port. It does
eventually go down, if one is willing to wait long enough. Often, when
people are in a hurry to restart it, they will kill it manually. You may
want to look in your logs, "booster", at what went on during the stop that
preceded this restart. That may confirm things.

And maybe this points to an opportunity for improvement in the installer,
whether it waits longer, or it detects and reports to the user if CF
couldn't really stop.

I'm leaning now to this being the explanation. Let's hear what you or they
may have to say. Hope it's helpful.

/charlie


-----Original Message-----
From: fusion...@googlegroups.com [mailto:fusion...@googlegroups.com]
On Behalf Of booster94
Sent: Thursday, May 21, 2009 8:03 AM
To: FusionReactor
Subject: FusionReactor Group: Re: windows server 2008 support

Thanks for checking into that. At least I know am not going crazy
just yet.

I did grab the error from the runtime event log that occured after the
install when CF wouldn't start. I'm not sure what it means though. I
can't really try this again until I get another maintenance window.
When I originally installed it I wasn't expecting any downtime other
then the brief service restart so I tried to get it done quick first
thing in the morning. Now that I know things might not go perfectly
I'll have to wait until an official maintenance windows so as not to
risk disrupting production.

05/18 07:54:52 info Deploying enterprise application
"Adobe_ColdFusion_8" from: file:/D:/ColdFusion8/

<snip>


booster94

unread,
May 21, 2009, 1:31:30 PM5/21/09
to FusionReactor
That actually makes a lot of sense. I've personally had that issue
myself where I stopped the service but it ends up timing out and being
stuck in a stopping state and jrun.exe was still running and I'd have
to manually kill the process. That would explain the port conflicts
and would be a reason why CF couldn't start (because it was already
still running). I didn't think to check that this time when the issue
was occuring, but it sure sounds like what might have happened.

I did let the installer do the stop/start of the CF service. Making
this scenerio even more likely.

Thanks for the input. Maybe I'll give it another shot over the
weekend.

Dan

On May 21, 11:56 am, "charlie arehart" <charlie_li...@carehart.org>
wrote:
> <snip>- Hide quoted text -

charlie arehart

unread,
May 21, 2009, 2:29:50 PM5/21/09
to fusion...@googlegroups.com
Great to hear, Dan.

And again, it may be an opp for the FR folks to consider, regarding the
installer.

Do let us know how it goes. Glad to have maybe helped.

/charlie


-----Original Message-----
From: fusion...@googlegroups.com [mailto:fusion...@googlegroups.com]
On Behalf Of booster94
Sent: Thursday, May 21, 2009 1:32 PM
To: FusionReactor
Subject: FusionReactor Group: Re: windows server 2008 support

Bernd Donath [FusionReactor Team]

unread,
May 22, 2009, 5:19:03 PM5/22/09
to FusionReactor
Hi,

to control a Windows service the installer calls the 'sc' executable
using Javas Runtime.exec method. If 'sc' does not work it calls the
'net' executable. In both cases it can happen that the Setup hangs if
the service hangs - the installer has no timeout built-in to detect
such a situation.

What I can definitely confirm is that we have seen JRun not stopping
(without killing the process) many times.

The next installer will use version 4 of install4j which offers a lot
of improvements and additional functionality (including support for
Windows 64) in comparison to the version used by FusionReactor.

Bernd

On May 21, 8:29 pm, "charlie arehart" <charlie_li...@carehart.org>
wrote:

charlie arehart

unread,
May 23, 2009, 1:38:25 PM5/23/09
to fusion...@googlegroups.com
Good to hear. Thanks, Bernd.

/charlie


-----Original Message-----
From: fusion...@googlegroups.com [mailto:fusion...@googlegroups.com]
On Behalf Of Bernd Donath [FusionReactor Team]
Sent: Friday, May 22, 2009 5:19 PM
To: FusionReactor
Subject: FusionReactor Group: Re: windows server 2008 support

Reply all
Reply to author
Forward
0 new messages