I am guessing nobody knows how to fix this then?
I really wish Adobe fix this bug becuase its is one of the most annoying bugs I have found, and what makes it worse is Adobe says nothing. Would be nice to say yes we know and we are going to fix it soon, or here is what you need to do get it to work.
Come on Adobe, give us a clue on how to fix or if not please fix.
@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 (http://forums.adobe.com/message/3087789#3087789, 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 2910", such as "telnet myserver 2910" or "telnet 192.168.1.2 2910".
- You may need to update the remote server's security.properties (such as c:\coldfusion9\runtime\lib\security.properties), 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.
Providing CF and CFBuilder troubleshooting services
Charlie, I was on the beta this was a problem then and it still is a problem now.
Let me address what you have said, yes I have gone through that information with a fine tooth comb. Secondly the subject of this answers whether I am saying if this is a remote server or not, and yes I have set up the ports and the IP restrictions to no avail.
The only message I get in the console of CFB is this
MultiServer]:Error(09/11 at 04:49:18) Error retrieving server version. Cannot perform the operation. Check if the server is accessible from web browser.
There is the odd time where it says it is stopping and it has stopped, and yet if I RDC to the server and look at the services, the jrun admin and the server instance is still running.
yes I can telnet to the port, yes it is indicated as remote and that port with the right user name and password.
Yes I had this working, and yes it has changed. I removed the isntance and redployed it, and yes I went through the settings again with a fine tooth comb.
There is a bug here, and it is flakey when dealing with remote servers.
And if the ColdFusion Builder Help actually had help information would be nice too, there is no help within this a
pplication when it comes to itself. Which is a right pain in the ***, why because I would prefer to stay within the application to read the help, not go lookin
g for other URL's and applications that provide it external to the IDE that is not productive to me switching windows all the time.
When I look in the Jrun logs when I do try to stop the server instance I am seeing this, yet when you look at the services cfusion is running.
jrunx.launcher.LauncherException: cfusion could not be stopped because it is not running.
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at java.security.AccessController.doPrivileged(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at java.security.AccessController.doPrivileged(Native Method)
Caused by: jrunx.launcher.LauncherException: cfusion could not be stopped because it is not running.
... 20 more
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
@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:
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 (\logs in Multiserver, \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 \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.
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).
@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.
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?
Let me be extremley clear on this, when I stopped Jrun and ran the bat as told by the website docs. That error message is what appeared on the console, as well as in the JRun logs. It is also the same message that I see if Jrun Admin is working.
I want to also point out that if I run the same setup locally on not remotely, I don't need to stop Jrun to start/stop a server in CFB so why is it that remote is any different in this case? I believe there is something more going on than what you think Charlie, and I do not believe that the admin run by the bat is any different to the JRun admin as the console text clearly indicates whether I run jrun.exe / admistart.bat from the console is identical on both counts. So I refuxe to accept your explanation on that part, especially when I don't need to stop Jrun locally to do this.
It doesn't work as you described, no matter what I do if I have Jrun Admin running or the bat file running it is always the same it says it is stopped but the service is not stopped and I am still able to run the /cfide/administrator
So your lenghty explanation although sounded good, it doesn't work either way I try it.
And no the CFB Help is not in the Eclispe help at all, never has and it was removed from the IDE about 3 RC's before final release and was never put back in. Like I said I don't want to go to an external application, nor do I want to swap windows it needs to be in the IDE.
I know the help program you are talking about, and it is a box of ****. Pardon the term there, but I don't want to run something that is as slow as heel, nor do I want anything that is external to my IDE. The point of inline help is that I am not switching applications/windows all the time, I can look read and code at the same time. That is called productivity and something that I know for a fact that Adobe doesn't care about, because if they did they would have read my ticket on this and understood the need of it in the first place.
As shown, I usually have this docked off to the side so that I can just click the icon and expand the view. Adobe never/or refused to think about people wanting to use it this way, I raised it as a bug that they claimed they fixed. Yeah right, and since ColdFusion 9.01 was released the ColdFusion one listed in the image has NEVER been updated either.
My confidence in Adobe is extremly low that they will provide what a developer needs, they don't get anything right. Now as I clearly stated I was on the beta release and both the server problem and this help was reported to adobe around 10 months before release, so let me ask this question why are will still jumping through hoops? And why is it not fixed?
And I am not going to fork out another $199 to have the fixed in a major release either, something else Adobe don;t know about is constant maintenance release schedules, and I say that because look at all the know bugs for CFB and it has been how long before the last update was released. Look don't get me wrong, for 1.0 release it is good enough. but there should have been a lot of bug fixes that have not been fixed as yet. I could list about 50 that annoy the crap out of me on a day to day basis, but I have to put up with it because I spent the money thiking that they would release fixes for these problems, and have they? But if it comes to buying version 2.0 or going elsewhere, I am likely to go elsewhere, one should not have to jump through this much pain to do something that is supposed to be trivial.
I also want to point out that if you actually look inside the admistart.bat file, you will notice that it actually runs JRun.
So that is proof that I am right on this issue.
Ok I think I now know what the problem is, yes it might not be a bug. But it is due to an extreme lack of documentation out there.
This has all stopped working the moment I tried to setup different jvm.configs for ColdFusion 8 and ColdFusion 9, so that I could use different ports for debugging.
The problem is somehow the service for ColdFusion is now the JRun administrator, and if I reboot the machine I am now able to start / stop the server within CFB. Although I now no longer see that information in the CFB Console.
The downside to getting this to work, is that I now can't run ColdFusion 8 as it too wants to start the JRun Admin server.
So my question is now 2.
1) How do I set this up correctly so that both the ColdFusion 8 and ColdFusion 9 can run happily again with different ports for debugging. I think it has something to do with the jvm.config I have for each but as there is a lack of documentation I am not sure I have set this up correctly.
2) how do I set up these services to also report the infor back to CFB so that I can see the info in the CFB console.
Charlie, you got me thinking about what I did around the time this stopped working. And with that I am getting a little closer as to what the problem actually is, just now I am not sure how to fix this.
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.
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: http://www.carehart.org/blog/client/index.cfm/2010/8/15/cfbuilder_debugger_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?
I appreciate the help, and you have also helped me understand things a bit better.
When you point out the help with ColdFusion in the CFB, I will stress this again. When ColdFusion 9.01 was released this help section has not been updated, so it is out of date and I haven't seen a patch/update for this as yet.
Now that will explain why the services are restarted again, I have seen this happen when you do a refresh on the server it shows it restarting. But it does get stuck on the stopping and/or starting a lot in which you have to edit the server and close it again for it to be updated again.
Now this brings me back to the original question about the jvm.config I modified these one for ColdFusion 8 and one fore ColdFusion 9 and removed the services and reinstalled them with the JVM config for each instance. But the problem I have now as I mentioned is that each of the instances seem to want to use the JRun Admin as well, for example try this.
Stop the ColdFusion 9 service
Stop the ColdFusion 8 Service
Stop the Admin service
Now start the Admin server and try to start the ColdFusion 9 or ColdFusion 8 service, you will get an error and if you look in the logs for JRun you will see that the log is saying that the Admin service is already running.
Now Stop the Admin Service and start the ColdFusion 9 service, and try to start the Admin Service. You will again see the exact same message that the Admin Service is already running.
I bet my bottom dollar that if I can fix that issue, I will be on my way to fixing this.
Now before I installed ColdFusion 8, and setup their own jvm configs, I had this working. I would see the console in CFB reporting exactly what it was doing. At the moment if I have ColdFusion 9 Service running, I can start and stop this in CFB but I see none of the reporting in the console like I did before.
Yes getting closer.
That is what I did Charlie, this is a multiple instance, yes I used the jrunsvc to remove and reinstall the configs for each instance.
Did I not actually say that earlier, I thought I had
On a ColdFusion Multiple instance running locally were this was working, is no longer working.
This is now two machines that have just stopped working, when trying to stop/start the Cfusion instance.
This is now a bug as far as I am concerned, the ColdFusion debugger was running and normally this comes back with the fact that the server was restarted or stopped, and yet this is also not happening anymore.
Adobe please help me find a solution to fix this problem, it is either ColdFusion 8 and ColdFusion 9 bug or ColdFusion Builder bug eithr way this is now a bug.
Still looking for a solution here.
The thing is flaky, and buggy. One minute it just works the next it doesn't.
I really wish someone from Adobe would look at this and fix the thing.
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..
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.
I got mine working by providing the actual IP name of the computer I am using. "localhost" and "127.0.0.1" 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.....