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.
Created attachment 107454 [details] NetBeans log files in zip file I cannot start GlassFish anymore (most of the time) via the IDE. This worked before, on the same day. Stopping NetBeans, killing all java process, Starting NetBeans - nothing helps. Sometimes, (rarely) it works. My computer is a single core 2GHz PC, which is possibly factor 2 to 3 slower that a new fast one. But should this not be acceptable?
Created attachment 107455 [details] GlassFish server log in zip file
which buil of the IDE are you using?
NetBeans IDE 7.0 RC1 (Build 201103280000) Could you make any timeout configurable in the server properties?
it is really hard to correlate the multiple nb log files against a single gf log file... Can you do the following: stop the the gf server stop the ide delete the ide's message.log file delete the gf server.log file. start the ide attempt to start the server from inside the ide if that last step 'fails', send the log files to me... if it takes multiple attempts to cause the start to fail, please include info on how many start attempts were successful BEFORE the failed start.
it looks like G1_W is a monster of an app that may be contributing to the startup problems. DojoExamples is fairly large, too. The combined wait of these two apps getting started may be related to your problem. I have seen a couple start sequences in the server log that appear to have been stopped before they finished... did you use the TM to kill the server process or did the IDE kill the server for you?
Created attachment 107524 [details] GlassFish and NetBeans log files Fresh log files both server and IDE. The server failed to start on the first attempt. I waited for the IDE to become completely idle before starting the server. Refreshing the server node did not help. Often in the past, the server node showed the started icon a few minutes after the IDE popped up the dialog that the server could not start, and all was ok. After this failure, the failure that is recorded in the logs, after re-starting the IDE, the server started ok. To me it looks like, and I am guessing, I am approaching a situation where computer resources are just enough to get started sometimes, may be if I add more load eg more deployed applications, then I will not be able to start.
In the above last case, attachment 2011 [details]-04-05 19:22,I did not kill anything. The dojo app has one servlet and 4,300 web files. G1_W does not look like a monster app to me. It has 700 classes and 300 other files. It does some database work on wicket (servlet) initialisation, but I cannot see that happening on startup failure, where it appears that the wicket app is not started at all.
Created attachment 107529 [details] GlassFish and NetBeans log files, success This time, success, again a fresh IDE start after all log files were deleted. I stopped the server via the IDE and then shut down the IDE before copying the log files. Just in case if this is indeed a timing issue, or a capacity issue or a CPU speed issue or whatever we may want to call it, please consider a configurable timeout value or a configurable re-try count. Otherwise the computer should tell me what the problem is. It is frustrating to see this type of thing happening again and again only because of some assumptions, and then being told that something is too big or too slow. The software should not fail even with the combination of too big and too slow. I don't mind letting the computer work hard once a day while I am doing some other routine such as making a drink.
Regarding your question what killed the server process, I would think that the IDE killed it, although I cannot rule out that I did it because once or twice I killed all Java processes after closing the IDE to have a clean start. It is confusing because I also said that the server is sometimes ok from the IDE perspective even after the IDE pops up the error dialog.
I think I found a way to replicate the behavior... and also found a partial solution. The diff is actually pretty small. When you see a note in this issue from 'quality', please download the latest dev build and let me know if the change is helpful. If it is, we can try to get it pushed into the release70 branch for inclusion in an RC build (and the 7.0 release).
*** Bug 190651 has been marked as a duplicate of this bug. ***
Integrated into 'main-golden', will be available in build *201104070400* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress) Changeset: http://hg.netbeans.org/main/rev/2d375706ec07 User: Vince Kraemer <vkraemer@netbeans.org> Log: #197375 : Timeout while starting GF
BHT: get the build that is linked below.... (In reply to comment #12) > Integrated into 'main-golden', will be available in build *201104070400* on > http://bits.netbeans.org/dev/nightly/ (upload may still be in progress) > Changeset: http://hg.netbeans.org/main/rev/2d375706ec07 > User: Vince Kraemer <vkraemer@netbeans.org> > Log: #197375 : Timeout while starting GF
Vince, thanks for the fix. This build looks good to me so far.
Created attachment 107633 [details] Log files with timeout The files are from a start failure with the new Build 201104070400. I think it is essential for this timeout to be configurable, if it isn't already. Just a note at the side: Unfortunately for web developers, voluminous JavaScript libraries such as dojo live in the application space and cannot be banned from there. And users want a high number of dynamic web pages. With the use of modern frameworks like Wicket this translates into a lot of classes eg inner classes for events etc. A lot of people including Oracle make a lot of money in the process selling hardware and software , even with applications of modest size such as mine. Do we really want to limit their profits by telling developers to write smaller apps? :)
(In reply to comment #15) > Created an attachment (id=107633) [details] > Log files with timeout > > The files are from a start failure with the new Build 201104070400. > > I think it is essential for this timeout to be configurable, if it isn't > already. > Hmm. the exception probably should not break out of the loop that is trying to collect the location data on the first attempt. That is an easy fix. Making the timeout configurable is a new feature, so it will need to wait for 7.1 development... I have some changes that address the 'break' from the loop and adds some more diagnostic info to the message. I hope these changes will close this bug (or provide more info about the 'cause') Please try the dev build again, after the notification from quality... similar to https://netbeans.org/bugzilla/show_bug.cgi?id=197375#c12
Integrated into 'main-golden', will be available in build *201104200000* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress) Changeset: http://hg.netbeans.org/main/rev/6de5bef77b00 User: Vince Kraemer <vkraemer@netbeans.org> Log: #197375 : a bit more change and and some additional diagnostics
> Making the timeout configurable is a new feature, so it will need to wait for 7.1 development... If a particular UI change/enhancement is required to fix a bug, then I'd say it's acceptable for 7.0.1. 7.0.1 will undergo the full QA cycle including community acceptance, so testing is well covered.
*** Bug 186806 has been marked as a duplicate of this bug. ***
using netbeans 7.1 with glassfish 3.1.2 (b22) having Liferay installed, and starting glassfish from NetBeans 'Servers', I get part way through the startup (which takes a fair while with Liferay installed) and it then announces that the attempt failed, and kills off the glassfish process. there is no indication in the log that there actually was a failure, it just took longer than what NetBeans has chosen to allow. I can start glassfish in a distinct command prompt, and hit the 'refresh' on the server item, and it correctly shows the badge that indicates the ide has determined the server to be running.
oh, by the way, I'm using windows 7 x64 with jdk 7u2 (x64).
please attach the server log and the ide log. it will help me diagnose the problem... especially if it is a different problem with a similar symptom.
Created attachment 115909 [details] glassfish and ide log files I've attached a zip (bug1.zip) of my glassfish server.log and netbeans 7.1 var/log/messages.log file to help diagnose the issue of glassfish being killed off by the ide part way through the startup process.
for what it's worth: if I start glassfish using a command prompt and manual asadmin start-domain command, it takes about 2 minutes for glassfish to complete the startup. however, this is just one example. If the mechanism for determining whether glassfish has failed to start involves timeouts, the GUI *must* allow us to configure what those timeouts are. perhaps there is another mechanism that should be used.. eg: does jmx come up early in the startup process? or perhaps something at the osgi layer?
Same problem appears with 7.1 (Build 201112071828). In the log I see the deployment timeout message. Glassfish needs some more time but is ok after that. Please add functionality to enter timeout manually.
I find this as well now. It is quite irritating. It is not the business of the IDE to kill a server. I wonder whether that is part of the specification. Timeout is one thing. Killing a proccess that the user requests while there is no error in it is something else.
Created attachment 117177 [details] IDE log There is no point attaching the server log because the server behaves normally.
If you combine this bug with the glassfish bug that makes apps deploy slowly this is even more frustrating. http://java.net/jira/browse/GLASSFISH-16560 I can start glassfish fine from the command line, and it appears to start up fine from inside Netbeans, but then times out and kills the server. My ear is taking 90 seconds to deploy on GF 3 and in 2.1 it took 10-20 seconds. Can somebody from the glassfish team and somebody from the netbeans team link up on these two issues?
(In reply to comment #26) > I find this as well now. It is quite irritating. It is not the business of the > IDE to kill a server. I wonder whether that is part of the specification. > > Timeout is one thing. Killing a proccess that the user requests while there is > no error in it is something else. A big +1 to this comment. Netbeans should not be killing Glassfish. Let me figure that out, and at the very least ask me first. "Do you want to kill the Glassfish process?" or "Do you want to wait longer?" If it asked one of those questions the problem would be solved because I could say "no don't kill it" or "wait longer" and let things finish.
There is a pause between when the server starts accepting connections and when it actually starts being able to process requests. The is a slight change in 3.1.2 compared to 3.1.1 during this pause. prior to 3.1.2, an http adapter command would timeout on the server side after 20 seconds (and return an 'I am not ready yet' kind of response). 3.1.2 does not return... it just keeps the accepted connection and responds when it is good and ready.
http://hg.netbeans.org/web-main/rev/31b432d2abc4 wait for the nightly build bits to confirm
Integrated into 'main-golden', will be available in build *201204200400* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress) Changeset: http://hg.netbeans.org/main-golden/rev/31b432d2abc4 User: Vince Kraemer <vkraemer@netbeans.org> Log: #197375 : ide kills GF server 3.1.2 during long startup
I just checked the nightly and the start does not time out. The start took about 7 minutes on my Windows laptop. marking as fixed.