java update 1.7.0_21 deleted jrunsvc.exe. what replaces it?

[bmuzzy]

I have CF 9.0.0.0 and tried to update from java 1.6.0_14 to java 1.7.0_21 at the request of my security department.  CF 9 Application Server used to run with "C:\ColdFusion9\runtime\bin\jrunsvc.exe" but now there's no jrunsvc.exe on the system.  What replaced jrunsvc.exe or was the error mine in trying to update java?

thanks,

Bob

[Carl Von Stetten]

Updating the Java JDK should not have any effect on stuff in C:\ColdFusion9\runtime\bin, unless you have done some manual replacement of the files.  The safest way to upgrade the JVM from the version delivered with ColdFusion to another version is to install the JDK in a separate directory from ColdFusion (usually in C:\Program Files\Java or C:\Program Files (x86)\Java depending on whether you are running a 32-bit or 64-bit version and the OS version), then update the JVM path settings in ColdFusion administrator to point to the newer JDK.  Alternatively, you can edit manually edit the JVM path in the jvm.config file buried in C:\ColdFusion9\ (can't remember exactly where, and I'm on CF10 now so I can't check it easily).

If you deleted the JVM from inside the ColdFusion directory and replaced it with the Java 7 one, you may be out of luck unless you can restore the folder structure from a backup or the Recycle Bin.  Otherwise, you may have to reinstall ColdFusion and then configure it as I outlined above.

-Carl V.

[Charlie Arehart]

In addition to Carl’s sage observations, I’ll note as well, Bob, that unless you have applied 9.0 CHF3, then your CF 9.0 deployment does not formally support Java 1.7. It might work, but some things might not. (Still, as Carl said, just updating the JVM should not affect the operations of files like jrunsvc.) To get the CHF, see http://helpx.adobe.com/coldfusion/kb/cumulative-hotfix-3-coldfusion-900.html.

As for your seeming problem with jrunsvc, I’m curious what you mean. You say, that CF “used to run with "C:\ColdFusion9\runtime\bin\jrunsvc.exe" but now there's no jrunsvc.exe on the system”.

So are you saying that when you try to start the CF service, it doesn’t stop, but gives an error saying that the jrunsvc does not exist? To be clear, the service runs that jrunsvc, and that in turns starts the instance, so that we see jrun.exe listed as the running process for CF9 and earlier. Assuming you’re running CF Standard or the Enterprise Server edition, you’ll find If you look in the services panel that the properties for the CF service show it listed as trying to execute C:\ColdFusion9\runtime\bin\jrunsvc.exe. If you’re running an Enterprise Multiserver deployment, the location for the service executable is C:\JRun4\bin\jrunsvc.exe.

Are you saying you see the CF service pointing to one of those files, but you don’t find the file to exist?

/charlie

[bmuzzy]

In CFIDE/administator it lists CF9 is running:

Java Version 1.6.0_14

Java Home C:\ColdFusion9\runtime\jre

I'm required to upgrade to Java 1.7.  I read online somewhere that installing the client JRE won't work, the JDK is required.  So I installed JDK 1.7.0_21 to C:\ColdFusion9\runtime\jre.  This created a redundant path of C:\ColdFusion9\runtime\jre\jre.  So I reverted to the previous snapshot of the VM and reinstalled JDK to C:\ColdFusion9\runtime.   this had the effect of removing jrunsvc.exe from the system.  And yes, the properties of "CF9 Application Server" service list the "path to executable" as C:\coldfusion9\runtime\bin\jrunsvc.exe"

I'll start by installing CHF3.  I note it refers to {coldfusion-home} which it defines as "For Server installation: {ColdFusion-Home}".  Is that the same as "Java Home", i.e.; C:\ColdFusion9\runtime\jre?  "coldfusion-home" doesn't appear in any text file under c:\coldfusion9 so I'm unclear.

Assuming I get CHF3 installed, I'll reinstall JDK to c:\program files\java\ and point jvm.config to that.

Thank you for your suggestions!

EDIT:

I think I figured out that {coldfusion-home} in my case is C:\coldfusion9

[bmuzzy]

I 99% sure I followed the CJF3 installation instructions correctly, including those in the link for using JDK 1.7.

I edited jvm.config to read:  java.home=C:\\Program Files\\java\\jdk1.7.0_21\\jre

CF fails to start and the only log entry I see is from coldfusion-out.log:

Error loading: C:\Program Files\java\jdk1.7.0_21\jre\bin\server\jvm.dll

However, that file does exist:

Directory of C:\Program Files\Java\jdk1.7.0_21\jre\bin\server

06/13/2013  11:32 AM         5,369,728 jvm.dll

I installed jdk-7u21-windows-i586.exe from http://www.oracle.com/technetwork/java/javase/downloads/jdk7-downloads-1880260.html.  I have windows 2003 SP2, 32-bit edition.

Any suggestions?

[Anit_Kumar]

Hello Bob,

Can you try the following:-

1. Launch Command prompt as Administrator
2. Browse to C:\ColdFusion9\runtime\bin and run the following command jrun.exe -start cfusion
3. Try to access the CF admin/website, once the services are started.

Please share the error message, if it fails.

Regards,

Anit Kumar

[bmuzzy]

I reverted the VM to a working CF9 with java 1.6 and very carefully installed the CHF3.  I now get the same error in coldfusion-out.log that I got at the command line with jrun.exe -start cfusion, "Error: no known VMs.  (check for corrupt jvm.cfg file)

there are 4 jvm.cfg files on this:

c:\coldfusion9\jnbridge\jre\lib\i386

c:\coldfusion9\runtime\jre\lib\i386

c:\coldfusion9\solr\jre\lib\i386

c:\java\jdk1.7.0_21\jre\lib\i386    (I installed it there vs in the default "program files" to avoid a space in the path

All 4 files are identical 

-client KNOWN

-server KNOWN

-hotspot ALIASED_TO -client

-classic WARN

-native ERROR

-green ERROR

Do I need to specify an "arbitrary location" to point to my JDK in c:\java\jdk1.7.0_21?

[Anit_Kumar]

Hello Bob,

Can you go to C:\ColdFusion9\runtime\bin\ and rename the jvm.config to jvm_old.config. Then, create a new jvm.config and add the details mentioned below to the same file. Once done, try to start the services.

# VM configuration

#

# Where to find JVM, if {java.home}/jre exists then that JVM is used

# if not then it must be the path to the JRE itself

#java.home=C:/ColdFusion9/runtime/jre

java.home=C:/java/jdk1.7.0_21/jre

#

# If no java.home is specified a VM is located by looking in these places in this

# order:

#

#  1) bin directory for java.dll (windows) or lib/<ARCH>/libjava.so (unix)

#  2) ../jre

#  3) registry (windows only)

#  4) JAVA_HOME env var plus jre (ie $JAVA_HOME/jre)

#

# Arguments to VM

java.args=-server -Xmx512m -Dsun.io.useCanonCaches=false -XX:MaxPermSize=192m -XX:+UseParallelGC -Xbatch -Dcoldfusion.rootDir={application.home}/../ -Djava.security.policy={application.home}/../lib/coldfusion.policy -Djava.security.auth.policy={application.home}/../lib/neo_jaas.policy -Dcoldfusion.classPath={application.home}/../lib/updates,{application.home}/../lib,{application.home}/../gateway/lib/,{application.home}/../wwwroot/WEB-INF/cfform/jars,{application.home}/../wwwroot/WEB-INF/flex/jars -Dcoldfusion.libPath={application.home}/../lib

#

# commas will be converted to platform specific separator and the result will be passed

# as -Djava.ext.dirs= to the VM

java.ext.dirs={jre.home}/lib/ext

#

# where to find shared libraries

java.library.path={application.home}/../lib,{application.home}/../jintegra/bin,{application.home}/../jintegra/bin/international,{application.home}/../lib/oosdk/classes/win

system.path.first=false

#

# set the current working directory - useful for Windows to control

# the default search path used when loading DLLs since it comes

# before system directory, windows directory and PATH

java.user.dir={application.home}/../../lib

# JVM classpath

java.class.path={application.home}/servers/lib,{application.home}/../lib/macromedia_drivers.jar,{application.home}/lib/cfmx_mbean.jar,{application.home}/../lib/oosdk/classes,{application.home}/../lib/oosdk/lib,{application.home}/lib

Regards,

Anit Kumar

[bmuzzy]

I got this in the log:

Error loading: C:/java/jdk1.7.0_21/jre\bin\server\jvm.dll

[Charlie Arehart]

Bob, there could be any number of things amiss, given what you’ve said in your past 4 messages today. I’ll try to share what I can based on them.

First, you said in one of them that you are running on 32-bit Windows 2003, and that you got the 32-bit JVM. Fair enough. But had you installed also a 32-bit version of CF? I suppose so, since you say that you had it running. But the errors you’re getting seem to suggest you are having some conflict like that. But maybe that’s not the issue.

Second, to go back to your first note today, your mistake then was installing the JDK into the CF directory. As Carl said yesterday, the solution is to put it elsewhere, and then point CF to it. But I see in your second note you reverted your VM and did it that way the second time.

Then in your 3rd note today, you refer to there being “4 jvm.cfg files”, and I realize that’s because one of the errors refers to it, but that’s not what CF uses to hold the JVM config files. Rather, it’s jvm.config. In your case, specifically c:\coldfusion9\runtime\bin\jvm.config.

But then you say that in your second note today, when you said “I edited jvm.config to read:  java.home=C:\\Program Files\\java\\jdk1.7.0_21\\jre”.

Indeed, when you make the changes you do to change the JVM location, do edit that jvm.config, rather than use the CF Admin, because if CF can’t come up, then you can’t see the admin any more to see if you made a mistake, or to correct it. Instead, one should edit that file directly, as you did.

But then finally, in your last note today, you report that you get an error:

Error Loading: C:/java/jdk1.7.0_21/jre\bin\server\jvm.dll

So that’s yet another location. Are you saying you reinstalled it, this time not in  C:\Program Files\java\jdk1.7.0_21\jre as you mentioned earlier today, but now in C:\java\jdk1.7.0_21\jre? Note the missing “Program Files” the 2nd time. And can you confirm that the files are there, as you did with the earlier path?

Finally, assuming that is the path, you would in fact want (in the jvm.config java.home line) to point to that path not as the windows path, C:\java\jdk1.7.0_21\jre, but rather with the “java way” of referring to that path, which would be either C:/java/jdk1.7.0_21/jre or c:\\java\\jdk1.7.0_21\\jre (or add in the Program Files, if needed).

Hopefully this will sort you out. I also share some tips on this, and point to other resources with still more, in a blog entry that was written when we were told in 2011 that we could update the JVM in CF 8 and 9 to 1.6.0_24:

http://www.carehart.org/blog/client/index.cfm/2011/10/28/CF911-Have-you-updated-your-ColdFusion-JVM-...

That info would still apply with your attempt to update to 1.7 (given that you have added the CHF 3). That said, while you say you “very carefully installed“ it, still it’s easy to make a mistake, which could be contributing to your problems. I did a blog entry also that year on that problem and some tips to avoid mistakes:

http://www.carehart.org/blog/client/index.cfm/2011/10/21/why_chfs_may_break

Hope all that helps. If things still don’t work, we may be able to help you with back and forth, but if it becomes time-sensitive for you, it may be better to enlist the help of someone to assist you remotely and online. I do that sort or work, as do some others. See cf411.com/cfconsult for a list of alternatives.

/charlie

[bmuzzy]

First, thanks to all of you for your help.

Charlie, I reverted to a previous snapshot of the VM several times that had

a working CF9 w/ Java 1.6, and reinstalled the JDK each time, and re-edited

jvm.config appropriately each time. The only reason I mentioned jvm.cfg

was because I saw the error ""Error: no known VMs. (check for corrupt

jvm.cfg file)" referencing it in coldfusion-out.log.

I'll take a look at your links, including that for the consultant. Thanks

again, all!

On Thu, Jun 13, 2013 at 7:19 PM, Charlie Arehart

[Charlie Arehart]

Sure. But to be clear, about the jvm.cfg reference, I acknowledged that saying “I realize that’s because one of the errors refers to it”.

I hope all the other info may have been more helpful. I’m especially interested in the observation toward the end about the change in your reference to \java vs \program files\java. That may have been the real problem.

Finally, oddly, it seems that the forum software has converted my references to double slashes into linend characters (at least as viewed in the web interface to the forum. We don’t get sent a copy of our own posts when we subscribe to the forum by email, so I don’t know if that appears to those who got an email of my message.) But I noticed you had referred to them in your earlier emails, so I have to think it’s that the forum software accepts them in the web interface, but just converts things when we email a response.

I’ll go edit the message now, in the web interface, but I just wanted to let folks know about the issue.

/charlie

[bmuzzy]

I realized I hadn't replied that jvm.dll was in c:\java\jdk1.7.0_21\jre\bin\server.  and removing "program files" from the path didn't solve anything.  I also tried every combination of \, \\, /, & // in java.home=c:\pathname without success.  also tried quoting the string without success.

Charlie, I note in your blog you mention the need to install hotfixes sequentially.  It was my impresion that CHF3 was a rollup and could be done instead of CHF1, CHF2, CHF3, no?  And good to know your available for hire if we haven't fixed this soon!

thanks!

[Charlie Arehart]

Bob, so what about the bitness, of the OS, the jvm, and CF (32 vs 64)? There HAS to be something amiss. Doing these JVM updates is really simple, but there are a couple of potholes you can hit.

As for the sequential hotfix issue, can you clarify what you’re referring to? I would never say you had to apply CHFs sequentially. What I have said, in different entries, is that:

- even if you DO apply a latest CHF there may be manual hotfixes listed in the earlier CHF that you still need to do after the latest (http://www.carehart.org/blog/client/index.cfm/2010/12/12/cfmyths_cumulative_hotfixes)

- and I had previously blogged that in doing security HFs you ought to them sequentially (http://www.carehart.org/blog/client/index.cfm/2011/12/16/apply_CF_security_hotfixes_in_order_ofoldest_to_newest), but I did update that (in early 2012) indicating that as of the Dec 2011 security fixes, it was no longer required. They too were now cumulative, though the technotes then didn’t clarify it.

Does that help? Or is there still some confusion? If I ever made a mistake in asserting something (or if things have changed since something I wrote), I’d want to know it, acknowledge it, and correct it (as I did in that entry).

Finally, sure, happy to help if you don’t resolve things. It’s what I love to do--and it’s true what they say: do what you love, and the money will follow. To all those who would say CF’s dying, I’d say that my level of activity suggests anything but.

/charlie

[Thixo]

I don't know if this is relavent to your problem. I had what seems to be exactly the same problem outlined here. I fought with it and fought with it. In my case, I am running CF9.02 on a 32bit windows server. Everything was working great until I updated to Java 1.7u25, and then everything went to heck. I read through this thread trying everything everyone has outlined here, to no avail. Finally, I simply updated my system environment variables and path. I set my environment as follows:

     JAVA_HOME=C:\Program Files\Java\jdk1.7.0_25\

Appended my PATH variable with:

     ;%JAVA_HOME%\bin

And ensured my jvm.config had the following java.home defined:

     java.home=C:\\Program Files\\Java\\jdk1.7.0_25\\jre

And now everything is working just perfectly. As a matter of fact, I have even downloaded the Java 1.8 pre-release snapshot (this is a development server with 4 instances) and even the Java 1.8 snapshot is working perfectly after updating all of the above with the correct path of the Java 1.8 jdk & jre.

I hope this information can help someone as I have wasted hours fiddling around with the latest CF 9 hotfixes and getting JVM's updated with lastest u25 updates. I had this same problem on my development servers and several production servers. Now they are all working perfectly.

- Cheers!