Skip navigation
Currently Being Moderated

Creating remote servers not working either with CF8 or CF9

Aug 27, 2010 1:53 AM

I actually hads this working and without warning I am now getting this error message in the IDE Console.


Error retrieving server version. Cannot perform the operation. Check if the server is accessible from web browser.


Well it is running fine, I can browse the website I can even enter the administrator. But when I try to stop the server or restart the server this is the error I get.


I have looked at everything, running the IDE as an administrator. Making sure the firewall is off on both machines, and yet nothing I do has worked.


Anyone know how to fix this?

  • Currently Being Moderated
    Sep 10, 2010 11:05 PM   in reply to ascott67

    @ascott67, I hear your frustration, and I hope I can help.


    Let me say first that, though, that I doubt your problem is a bug. I appreciate that something seems broken for you, but I suspect it's a configuration issue for you (in CFB or on your CF server). More on that in a moment.


    Second, I think it's worth clarifying that you ought not presume that Adobe should or will respond to your messages on these forums. They make no guarantee of that.


    Several of us form the community do try to help out here, but even we can't all always see each message. And some problems are relatively less common than others, so the number of people who can help with it may also be reduced. I'm afraid you just have to be patient.


    So, about your problem, I've found your earlier message in the thread (, for those reading these by email) and I see that you're finding that CFB's "server" configuration can't connect to your intended server, such as to do a start or stop. You say also that it happened "without warning". Some might hear that as you saying, "nothing changed". We've all been there before, right?


    You refer in the other message to things you tried, but I have to ask, especially for this problem: have you referred to the CFBuilder docs, which has a section specifically on server configuration? You may find it quite enlightening.


    For instance, you've not said if the CF server is local or remote to your CFBuilder. If it's remote, then you need to communicate over RMI, and for that you need to have done several things, any of which may be the root of your problem (and which may have changed either on the server or in your CFB, if it "was working before"):


    - You need to have set the right port for the RMI server in the CFBuilder Server configuration page. The default is 2910. There's a tab in the Server Configuration page where you set this, if you indicate that it's a remote server. (And you can edit a server configuration by right-clicking on the server in the Window>Show View>Servers view.)

    - You also need to have started the Admin instance (a special instance of CF, not related at all to the CF Admin for those who may wonder), which is what sets its RMI port to 2910.

    - You need to be sure that that remote server exposes that port (2910) in its firewall, at least for you to be able to access it. You can test that from the CFBuilder machine with something like "telnet Re: Creating remote servers not working either with CF8 or CF9 2910", such as "telnet myserver 2910" or "telnet 2910".

    - You may need to update the remote server's (such as c:\coldfusion9\runtime\lib\, to provide either * or the IP address of your CFB machine

    - Finally, along with setting the RMI port in the CFBuilder Server configuration, you also need to set there a valid RMI username/password for the server (not the CF Admin password, but the RMI username/password, whose defaults include admin/admin. More in the docs.)


    These sort of things do trip up a lot of people. I help people solve these sort of problems every week. You're not alone, and while it is frustrating to experience it, I do hope that this roundup of things to look at will help you.


    I do want to repeat, though, that Adobe has done a decent job of documenting all this in the CFB docs. People just tend to presume that the UI should be obvious enough. Sadly, it's not. Maybe they'll work on that for the next release (along with perhaps providing more clear messages about which of these steps need to be corrected if wrong.)


    Let us know if this helps.


    /charlie arehart

    Providing CF and CFBuilder troubleshooting services


    Mark as:
  • Currently Being Moderated
    Sep 11, 2010 1:29 AM   in reply to ascott67

    @ascott, I did miss that you said it was remote in the subject. Sorry. But at least I was headed down the right track in my discussion.


    And I do thing I have the solution for you now.


    I hear that you may not have agreed with my assessment so far, and further that you're feeling you've been experiencing this problem a long time, and that it's intermittent, and that you still feel it's a bug. If you'll be patient with me, I've asserted that it could be a configuration, and I do think now I can prove it, though technically it's not really your fault. Let me explain.


    First, you say "if I RDC to the server and look at the services, the jrun admin and the server instance is still running."


    Well, I'd want to clarify that if you thought that "admin" was the "admin" I've been referring to, it's not. But it may well be at the root of your problem in ways you (and many) never expected.


    The admin instance referred to in the CFB docs is NOT(!) the JRun Admin instance, but rather a "new" admin instance that's provided in CF9 (or needs to be added, for CF 8 or 7). This instance is started manually using the adminstart.bat (or .sh) file found in the /runtime/bin (for Standard or Enterprise Server mode deployments) or /bin (for Multiserver deployments). Again, this is covered in the docs within builder, or specifically at: -38317734121cdfd5fd3-7ffd.html


    So if you've not started that Admin instance, that would be a first real problem. It's that which has the stuff in it for acting as a proxy for CFB to watch your "real" CF server(s).


    But before you go starting it, hold on. It will probably not start for you, and I think I now know why, and I think it's the answer to your problem (and it has to do, in fact, with you running the JRun Admin instance).


    First, let me take a moment to clarify for readers that this JRun Admin instance is something that one would only see if they were running CF in the Multiserver (multiple instances) mode. It's really what I call the "appendix" of CF (like that on the human body), in that it's vestige of the pre CF7 days that we no longer generally need. It was needed back then when the only way to create new instances was to launch the JRun Administration Console. 


    CF 7 added the Enterprise Manager in the "main" CFusion instance (usually at port 8300), and THAT's how one is told in the CF docs to create new instances (though some still "like to do it the old way"). So I point out that for most people, they can simply stop and disable that JRun Admin instance, with no loss of functionality and indeed a gain in the memory that it was using. But I see now that doing that gains something else. Back to your problem.


    So, you go on to say, "yes I can telnet to the port, yes it is indicated as remote and that port with the right user name and password."


    Well, that would certainly indicate that something on that server is listening on port 2910, but it isn't necessarily the CFBuilder Admin instance above, and of course, if you didn't start the instance, then it can't be, right?


    So what else could it be? Well, I was about to tell you that you should look through your CF runtime logs (Re: Creating remote servers not working either with CF8 or CF9\logs in Multiserver, Re: Creating remote servers not working either with CF8 or CF9\runtime\logs in Standard/Server), because if a CF server opens a port like that, it reports it. And guess what: I can see in some old logs from before I stopped my Admin instance that in fact the Re: Creating remote servers not working either with CF8 or CF9\logs\admin-out.log does in fact show:


    "JRun Naming Service listening on *:2910"!


    So THAT's what was responding to your telnet request. That JRun Admin instance (that vestigial appendix that I say should be disable) was opening that port.


    Now, someone may wonder how it's configured to use that port. It's in the Re: Creating remote servers not working either with CF8 or CF9\servers\admin\SERVER-INF\ file, specifically these entries:





    And BTW, it's in that same directory that this JRun Admin instance has also its own jrun-users.xml file, and it has the same default values (like admin/admin) that the CFBuilder Admin instance has, which is why you didn't get a failure due to that.


    I will say that it is certainly too bad if the CFB team didn't give thought to these possible conflicts, both about naming their instance "admin" when there was this long-existing other " admin" instance (for JRun, on multiserver deployments, which many don't understand), and most of all about this conflict of the 2910 port in each of them.


    I'm sure this has burned a lot of people, if I've figured it out correctly for you. Though to be clear, it's only those who are running Multiserver, who DO have the Admin instance started (many know they can turn it off), and who DO try to configure CFB to connect to it as a remote server. That really does bring the number of people affected to a pretty small percent even of the total number of people just reading this forum.


    I hope it proves to help. Do let us know. If it does, I'll write a more condensed version of this for people (and I'll blog all the details later).



    Mark as:
  • Currently Being Moderated
    Sep 11, 2010 1:48 AM   in reply to ascott67

    @ascott67, boy, someone didn't have their cheerios this morning.


    The CFBuilder help does "actually have help information...within this application when it comes to itself".


    I don't know what's happening for you, but there should be a "ColdFusion Builder Help" item in the CFBuilder Help menu. Do you not see one? If not, that would seem to be a bug. If it's there and you missed it, I hope it serves your desire to stay within the app. That's certainly its intention. (I only point to URLs because they're easier than telling people what section to find within the online help inside CFB.)


    And that CFBuilder help is in fact the full "Using Adobe ColdFusionBuilder" document I've been referring to, and also the "Installing ColdFusionBuilder" document, which we should all read for sure.


    I hope I'm helping with your challenges. I certainly don't mean to be hitting you when you're down, but instead I'm trying to help you up.



    Mark as:
  • Currently Being Moderated
    Sep 11, 2010 1:53 AM   in reply to ascott67

    Wait, you say at the top that this is from a JRun log (though you don't say which: is it the cfusion-out.log? something else?)


    But then the last line says " If it helps I stop the jrun admin service and ran the bat file that Adobe tell me to run, from the console and I am seeing this message."


    Did you mean to give another message? Or do you mean you see the exact same messages as above?


    And to be clear, where are you running the adminstart from?



    Mark as:
  • Currently Being Moderated
    Sep 11, 2010 7:37 PM   in reply to ascott67

    Hey @ascott97, I've seen your subsequent messages in the thread. Good to hear that you're making progress toward a solution.


    As for the below, I'll say that I see now you're right that the Admin instance is indeed the same (with a caveat). It was very (very) late when I wrote last night. I was really intrigued about this problem so stayed up working on things to offer a response, especially since you and several others here had been struggling. I wanted to understand the problem and help if I can.


    What I've come to realize is that, yes, the Admin instance itself that's started from the AdminStart.bat (or .sh) file, which is new in CF9, is in fact the same JRun Admin instance that is already there (the one I described, and that I suggested that I recommend people stop as a service).


    In fact, that’s where some confusion comes in. Because if people DO run the adminstart script, they cause that Admin instance to be started with its own jvm.config (admin_jvm.config, also new in CF9--or both it and the script can be downloaded from Adobe for those on CF 7/8). That's what I was doing.


    But if people already have the Admin instance running as a service, they will get an error about it already running when they try to start it.


    And it won't be "wrong" to have that Admin instance running, but there are some minor differences in the special jvm.config (uses smaller heap sizes). Most important, though, as you found out later, it would NOT share the same jvm.config with your real CF instances, such that if you made changes to those (like enabling the debugging), that wouldn't affect this Admin instance (since it wouldn't have those settings in its jvm.config).


    As for your wondering why a local vs remote server is different, it's because in a local server, you tell CFB where the CF installation is, and it can therefore run the jrun cmds itself to stop/start the server. For a remote server, instead, that command has to be sent over the network to the listening admin instance, which then can stop/start its own instances (and only its own, by the way--you can't ask the Admin instance in a remote multiserver deployment to also stop a Server mode deployment of CF on the same box. Each will need their own Admin instance, listening on their own JNI port, and a separate remote server configuration in CFB.)


    There are quite a few other interesting things I've discovered and started to document as I work through all this. Lots of other interesting challenges that people can hit. Just a quick one: people should beware in trying to stop a multiserver instance from CFB, if in fact they had configured it (at instance creation time) to run as a service with the "autostart" option (offered in the CF Admin Enterprise Manager when adding an instance). If so, then while CFB will stop the instance, you'll find that it comes right back up because the jrunsvc.exe is watching it to detect that it went down, and it starts up. But I find that CFBuilder just shows it with a status of "stopping", though it has in fact restarted, and that's not updated.


    Anyway, it sounds like you're on the way with your own challenge, and that's great. Eventually I'll share more of what I've found (but I'll be out of pocket much of this next week, so will instead try to help where I can until I can do the larger writeup.)


    As for your comments about the CFB help, it sounds like your concern is with the new AIR app that they use. Fair enough. It wasn't clear that was your beef. You just said, "And if the ColdFusion Builder Help actually had help information would be nice too, there is no help within this application when it comes to itself".


    So to be clear, you don't like the popup AIR app, and you wish that the "Using ColdFusion Builder" guide showed up in the Eclipse help window (Window>Show View>Other>Help>Help). Fair enough. I'd never noticed that it wasn't there.


    And for me, that's because while I agree with your concern about accessing help within the IDE, my concern would be more about help on tags, functions, etc. And let's clarify for other readers who may not have noticed: those DO show up in that help window (also accessible by cursoring over the tag/function and pressing F1). So you're really only talking about the CFB user guide, right? Well, I see your point, but it seems one wouldn't be looking at that user guide too much on a day to day basis, I'd think. But sure, I can see wishing it was in the normal help window. Perhaps in the next release.


    Finally, as for your remaining concerns, I hear you. I don't work for Adobe, so I can't help, and I know there are some others who feel as you do. Most people I talk to or hear from seem otherwise happy with it, though they may run into occasional snags. Still, you're perfectly in your rights to vote with your pocket book and skip updating. I'm confident that the next release will address a lot of the problems that have been raised. I'll understand that some won't share that confidence.


    I'll look forward to hearing how things go for you with the things you observed in the later thread (and I have a couple thoughts to share there in response to some questions you raised). Again, though, please keep in mind that I'm just here, as a fellow CFB user, trying to help. If I sometimes press back against arguments that "something's broken", it's only because I spend my days helping people solve CF and CFB problems, and rarely are things really "bugs" but just misunderstandings--no doubt often because, as you note, some of the docs may not be as clear on some things as they could be. Fortunately, the docs do permit comments to be shared, and Adobe generally addresses those in subsequent doc updates.



    Mark as:
  • Currently Being Moderated
    Sep 11, 2010 7:58 PM   in reply to ascott67

    I'm glad to hear that you're making progress, and you ask some questions and I hope I can help answer them.


    I'm curious first, though, about you saying, "somehow the service for ColdFusion is now the JRun administrator" and "I now can't run ColdFusion 8 as it too wants to start the JRun Admin server." If these problems remain for you, can you elaborate a little?


    As for your question 1, it would help if you would clarify: are these CF 8 and 9 implementations both instances on a single Multiserver deployment (not common, but possible)? Or is one perhaps Standard/Server and the other is Multiserver?


    The reason I ask is that, as you noted, in a Multiserver deployment, all the instances will by default share one JVM.config. That's definitely a problem when you try to use the step debugger feature, because if one instance starts and grabs the port (defined in the JVM.config), the other instance cannot.


    This wouldn't be a problem if your CF8 was Server/Standard and the CF9 was Multiserver, as those instead do each have their own jvm.config (at least as long as you're careful also to specify a different debugger for the different deployments).


    The solution when you want to debug multiple instances to create a separate jvm.config for each instance, but that's complicated because if you run the instances as Services, then you need to modify the Service definition (using jrunsvc to remove and recreate them, and have the new service for one instance point to its own jvm.config). There are lots of blog entries out there (and even some coverage in the docs) on resolving that.


    I also address the problem in my 25-page chapter on the Debugger, in the CF9 Web App Construction Kit book, which fortunately is online (my chapter, and 2 others), as offered here: gger_CFWACK_chapter_online


    As for your question 2, you ask "how do I set up these services to also report the info back to CFB so that I can see the info in the CFB console." I wonder if this is related to something I referred to in my last note (just sent tonight, long after your note below, of course). If those instances (or CF Server/Standard deployments) that you're trying to stop with CFB are in fact setup to run with Services, then they are by default configured to "autorestart", meaning the jrunscv.exe that's watching them (also listed in task manager on the server) will detect if the instance it's watching goes down, and if so, it restarts it.


    And when CF instances run as Services, they report their console output to the respective -out log (either in \runtime\logs (for Server/Standard) or \logs (for Multiserver). As such, they will not report their console information in the console view/tab of CFB.


    Does that help?



    Mark as:
  • Currently Being Moderated
    May 26, 2012 4:19 AM   in reply to ascott67


    i am new to CF enviroment, and while i try to connect CFB 2 with CFServer 10 it through up this massage..

    " Error retrieving server version. Cannot perform the operation. Check if the server is accessible from web browser."


    "Unable to find JNDI port. Ensure that you have provided correct server information."


    what its cure..


    thanks .

    Mark as:
  • Currently Being Moderated
    Apr 11, 2013 9:54 AM   in reply to Jaiswal.PK

    CFB 2 and CF 10 and CANNOT get connected either.  Been trying for 6 months now.  Using IIS 7 and I put all my files in a folder under C:\Scripts.  Pointed the server at C:\Coldfusion10.  How absolutely frustrating this is.  I cannot use the debugger, I cannot explore CFC's, I cannot explore Web Services... I might as well use Dreamweaver which connects to my localhost immediately and easily.  Why doesn't CFB 2 work just like Dreamweaver if DW actually connects and works, it makes absolutely no sense at all.... the one that should doesn't, the one that you would think should be problematic is a piece of cake.


    [localhost]:Error(04/11 at 11:51:04) Error retrieving server version. Cannot perform the operation. Check if the server is accessible from web browser.

    Mark as:
  • Currently Being Moderated
    Apr 11, 2013 10:16 AM   in reply to Nick_KC

    I got mine working by providing the actual IP name of the computer I am using.  "localhost" and "" did not work in the "Host Name" field when setting up the server.  But my computer IP works using Port 80.  So far so good.....     

    Mark as:

More Like This

  • Retrieving data ...

Bookmarked By (0)

Answers + Points = Status

  • 10 points awarded for Correct Answers
  • 5 points awarded for Helpful Answers
  • 10,000+ points
  • 1,001-10,000 points
  • 501-1,000 points
  • 5-500 points