This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.
I installed an external Tomcat 5. I used the Add New Server dialog box to add it to the IDE. It set the port to 8080, which is the same port number for the internal Tomcat, so I decided to change the port number for the new server using the property sheet. It wouldn't let me, saying I had to stop the server first. So I right-clicked the server node, choose Start / Stop server and clicked the Stop button. The Server Status Dialog Box appeared and the progress bar stopped at about 80% complete. 100% of my CPU is being used (it is now 5 minutes or more after the freeze of the box). Note that I added and removed the external Tomcat once before this incident.
Created attachment 13277 [details] ide.log
Are you sure that the internal tomcat was not running at the same time? The IDE cannot detect which of the servers is running if they run on the same port (it could detect if they have different version but that is not implemented now, see #38586). In this case it will not be able to stop the new server if it started the bundled server. This general problem should be solved for 3.6. The easiest solution would be to prevent the user to have 2 servers with the same ports, even if they are not running. We could also try to remember that one server is started and make it impossible to start the other one if they have the same port. I am afraid either is impossible with existing j2eeserver api. I agree with P2 since we do not even warn the user and the default leads to this bug. Fixing 39431 will make this a little better.
I am pretty sure the internal server was not running. I agree that the port numbers should not be the same. However the wizard did that. The wizard did not give me an opportunity to set the port number. That is how I ended up with two server instances with the same port number, and that is why I wanted to change the port number. Here is the sequence of steps (a catch 22) Add new instance. Wizard adds instance with same port number as internal tomcat. Try to edit server port property for new instance. It tells me I have to shut the server first. I try to shut the server. It hangs because, as you propose, there are two servers with the same port number. Perhaps the new server wizard should not create an IDE server node with an already used port number. Also note that, when I added this server, I made it a shared server with a base directory. I encountered many problems when I did this that went away when I removed it and added a non-shared server.
What would you expect from the wizard ;O) ? Should it display warning, or change ports automatically, or do not allow adding such instance? I agree that is a problem, I just don't know what's the best way to solve it.
Ann, do you have suggestions?
I was too quick with my comment. When testing now I can add tomcat with 8080 and change the ports when no tomcat is running. The test that disallows you to change the ports is based on checking the server port for any response so if no server is running it should work. Also, I was actually able to start one server and stop the other one with the same port. This is weird and there will definetely be other problems, but I wonder what exactly happened in your case. Please try to reproduce that and let me know. Thanks.
When Martin and I were looking at this dialog, I had the understanding that the dialog would pick a port number not already in use. From Chris' description, this isn't the case. It seems that the best thing would be to allow the user to see and modify the port number on the dialog itself. This could be populated with a default port number which is not in use.. BTW, The S1AS "register wizard" allows user specify the port for "user defined servers". If this is too much of a UI change late in the release.. then having the wizard pick the port silently is acceptable. The port will show prominently as part of the node name, so the user should be able to pick that up. Also, they can change it via properties. Let me know if these options don't address the issue fully. BTW, has anyone addressed the issue of Tomcat and AppSvr using 8080 as the default port number?
see "Default port is set to 8080", #39431, it is on my plate. It requires a bit of rewrite bcs of implementation issues (does not allow to add one more thing to be changed in server.xml;-) ). This will be done for 3.6.
Here was my situation: When I installed the external tomcat on my PC, the server was started (its icon showed up in the bar on the bottom of the desktop). I started NetBeans and added the server using the Add New Server dialog. I checked the box about being a shared server and browsed to and selected an empty directory under my home directory (and that, I think is the cause of the problem as Pavel B tells me it must have certain contents in order to be a base directory) Because the server was already running, it wouldn't let me change the property sheet values and told me to turn the server off. When I tried to turn the server off, that is when I got the 100% CPU. So, in the end it is a user error but it will be difficult for users to diagnose the consequences. This may be a duplicate of 39674.
There can be some situation when the port change is not possible. For example if an user adds non-shared installation of tomcat on an unix system without having a write access to the server configuration files.
This relates to the default port number (issue 39431), which was changed. So can this be downgraded to a P3?
downgrading, it is less likely to happen with the #39431 fixed In future we should prevent the user in adding servers with the same ports. I will attach sketches of screens for that (from Ann).
Actually there is an issue for the change in dialog (#39708) and I added the dialog sketches there. I am leaving this open only to check if we can somehow prevent the deadly situation even with two servers with the same port number.
I filed the remaining problem as a separate issue #46514. The rest is resolved.
VERIFIED