Created attachment 114535[details]
log file in zip file
The server is running in debug mode.
The EJB/Web application is set Compile On Save, but not deploy on save.
In the Projects window, I use the debug context option to deploy.
NetBeans undeploys and re-deployes as expected.
The application has a few hundred classes, so it is big. I have a lot of problems with debugging, the debugger stops on lines with no code even after undeploying, re-starting the server.
I have tried a whole day to make a testcase for the debugging problems with no success.
But I can report this timeout problem which can be seen in the log.
I am very frustrated with NetBeans and GlassFish - even after having reported many issues that are now fixed, this thing is still not stable.
When I am in a complex scenario having to debug the app, then very often the environment fails.

Created attachment 114542[details]
NetBeans log file
In the future, could you avoid making a zip file for log files and attach them as separate plain text attachments... You will need to change the 'Content Type' since the auto detect feature on bugzilla does not seem to function very well.
Please attach the corresponding GlassFish log in situations like this in the future too (as a separate plain text attachment).
I have been assigned to other high priority tasks within Oracle. Using the limited amount of time I have to convert attachments into a more readable form detracts from the time that I can use to actually diagnose the issue.

I looked through the attached log file.
Is this the message that you are reporting?
INFO [glassfish]: __locations returned from server after 21,382ms. The server is still getting ready
Let me make sure I understand what you are doing in this report...
You
1. have the server started in debug mode
Is the debugger attached to the server or is the server just running in debug mode?
2. Are you using 'right-click Debug' because the server gets restarted in 'normal mode' otherwise?
Please provide step-by-step instruction on how you produce the issue that you are reporting.
It would be nice to have a detailed description of the server's and the IDE's initial state.
Examples of the server's initial state: number of deployed apps, etc.
Example of the IDE's initial state: number of open projects, types of open projects, etc.

The message is informational and is not critical usually.
Here is how it happens...
When the IDE is checking whether the server is running we also update the data about the http port that the is ring used by the server (to help open the browser on the correct port).
To change the port, the server must be restarted. While some folks will do that start and stop with the IDE actions, others may stop the server change the port configuration and restart it with asadmin.
The org.netbeans.modules.glassfish.common.CommonServerSupport.updateHttpPort method is used to detect those kinds of situation and update IDE data structure automatically.
This exception may be a symptom of something bigger, but I do not know what that is at this point.
You may want to note:
You probably do not need to start the server in Debug mode before you 'right-click Debug'

Thanks for the explanation. I am glad this is not a serious issue at this stage.
If I click debug from the projects window with the app already deployed with the most recend action and no source code changes and the server is already in debug mode, then the app gets undeployed and re-deployed for no abvious reason.
Should I report this as a bug?

(In reply to comment #8)
> Thanks for the explanation. I am glad this is not a serious issue at this
> stage.
>
> If I click debug from the projects window with the app already deployed with
> the most recend action and no source code changes and the server is already in
> debug mode, then the app gets undeployed and re-deployed for no abvious reason.
>
> Should I report this as a bug?
No. The IDE is doing the action that you asked it to do.
Note: you may want to try the following workflow.
(assuming the IDE and server are both not running)
start NB
open the project (if it isn't already)
'right-click Debug' the project
make some code changes
'right-click Run' the project.
this will use incremental deployment instead of a complete undeploy/redeploy cycle.
The server shouldn't restart and your IDE will not detach from the server VM.
This may help optimize your workflow a little bit.

What I am seeing is different with a standard ant build file and
Project Properties|Libraries|"Build required Projects (Libraries and WAR content)" unchecked.
Still with no source code changes:
init:
deps-module-jar:
deps-ear-jar:
deps-jar:
library-inclusion-in-archive:
library-inclusion-in-manifest:
compile:
compile-jsps:
Undeploying ...
In-place deployment at <my project path>\build\web
run-deploy:
Browsing: http://localhost:8080
run-display-browser:
run:
BUILD SUCCESSFUL (total time: 1 minute 9 seconds)
I think there cold be a potential time saving if the IDE can skip the re-deployment if the project is up to date. Like when I click in the services window at the deployed app "Open in Browser" but I don't always know whether I made source code changes.
What do you think?

(In reply to comment #10)
> What I am seeing is different with a standard ant build file and
>
> Project Properties|Libraries|"Build required Projects (Libraries and WAR
> content)" unchecked.
>
> Still with no source code changes:
>
> init:
> deps-module-jar:
> deps-ear-jar:
> deps-jar:
> library-inclusion-in-archive:
> library-inclusion-in-manifest:
> compile:
> compile-jsps:
> Undeploying ...
> In-place deployment at <my project path>\build\web
> run-deploy:
> Browsing: http://localhost:8080
> run-display-browser:
> run:
> BUILD SUCCESSFUL (total time: 1 minute 9 seconds)
>
> I think there cold be a potential time saving if the IDE can skip the
> re-deployment if the project is up to date. Like when I click in the services
> window at the deployed app "Open in Browser" but I don't always know whether I
> made source code changes.
>
> What do you think?
That this suggestion needs to get opened as a new enhancement request...
Provide details in that new issue so it can be understood without having to come back to this issue for 'context'.

Significant parts of org.netbeans.modules.glassfish.common.CommonServerSupport and deployment code will be re-written in Tooling SDK library so we should check it again after this will be done.
I'm assigning this to myself. I'll come back when we'll be done with Tooling SDK.

INFO [glassfish]: __locations timed out. 1 of 1
This looks similar to the problem you described in bug# 199099. I missed that this timeout is related to this. Also stack trace is the same - CommonServerSupport.isReady uses __locations call to verify if GlassFish is up and responding.
CommonServerSupport.updateHttpPort method is the same - glassfish admin command, just to retrieve property from server config.
There is 10 seconds timeout and it's still uses original code even in 7.3.
This looks like server did not respond in 10 seconds.
I would like to switch this code to GF Tooling SDK library. Also I would like to come with some way to modify timeout value (together with bug# 19909 changes).

We won't move CommonServerSupport.updateHttpPort() to Tooling SDK in 7.3.
Skipping the re-deployment if the project is up to date will also be considered as 'next release RFE'.
Targeting this to next release.