1
votes

Today I stopped/started my GlassfishV3 instance and now I cannot access the addmin console located at http://servername:4848/. The screen says: "The admin console is loading..." This is going on forever now.

I have tried as follows:

  • I have tried adding the following entry to my domain.xml located at /glassfishv3/glassfish/domains/domain1/config as suggested in another Stack Overflow Q&A but after restarting the server still no luck.

    <java-options>-Dcom.sun.enterprise.tools.admingui.NO_NETWORK=true</java-options>

  • I have also installed glassfishv3 on my local machine and cannot recreate the problem.I can go to http://localhost:4848 without any problem.

  • I have also looked at the server.log and jvm.log files located under the /glassfishv3/glassfish/domains/domain1/logs and nothing there that shed some light.

Any help would be very much appreciated

5

5 Answers

2
votes

I had similar symptoms, and I tried some of what Dario had suggested as well, but it didn't work. It could be that I had a unique configuration for my dev env: I'm running Glassfish 3.1 on a VirtualBox Ubuntu 11.04 64-bit guest on a Windows 7 64-bit host. Quite by accident, I discovered an additional symptom: if I turned off the network on the Ubuntu guest, the console would load successfully on a localhost browser instance. That is, on the Ubuntu guest with the network off, I could successfully navigate to http://localhost:4848 and show the Glassfish admin console as expected. However, if the Ubuntu guest's network was on, I had the exact behavior suggested by the original poster: http://localhost:4848 would just sit forever on the inial loading page.

To make a long story short, I found that adding the following argument to the JVM options for server-config fixed the problem: -Djava.net.preferIPv4Stack=true

When I made that change and restarted the Glassfish server, everything worked.

(Note that I also had in place some of the other settings recommended above, i.e., NO_NETWORK=true, and I'd adjusted the JVM memory footprint and set it to -server instead of -client. It could be that these settings are required as well, though they weren't sufficient on their own in my case.)

2
votes

I was having this exact same problem. I could deploy in run mode, but it would hang forever in Debug mode. IntelliJ was hanging on the breakpoints. I muted the breakpoints, and glassfish3 worked good as new. I didn't have to change any domain.xml settings. Check your breakpoints!

2
votes

I found a solution to my problem. Setting the java-option to NO_NETWORK to true did not work so I upgraded from 3.0.1 to 3.1 and it got fixed. Not immediately though, I had to stop/start the Glassfish server a couple of times before I got into the admin console without any really long delays.

Solution

The solution was to upgrade from the command line using the pkg utility.

You can find the steps in this link: http://download.oracle.com/docs/cd/E18930_01/html/821-2437/gkthu.html#gktjf

Or do as follows:

  1. Go to as-install-parent/bin
  2. ./pkg image-update
  3. as-install-parent/glassfish/bin/asadmin start-domain --upgrade domain-name
  4. as-install-parent/glassfish/bin/asadmin start-domain domain-name

UPDATE I had peformance issues again and I found this other solution in Joshi's tech blog: http://joshitech.blogspot.com/2009/09/glassfish-application-server.html

Basically add the following jvm options in the domain.xml. It should increase Glassfish boot up and deployment performance:

<jvm-options>-server</jvm-options>
<jvm-options>-Xms3000m</jvm-options>
<jvm-options>-Xmx3000m</jvm-options>
<jvm-options>-XX:MaxPermSize=192m</jvm-options> 
<jvm-options>-XX:NewRatio=2</jvm-options> 
<jvm-options>-XX:+AggressiveHeap</jvm-options>
<jvm-options>-XX:+AggressiveOpts</jvm-options>
<jvm-options>-XX:+UseParallelGC</jvm-options>
<jvm-options>-XX:+UseParallelOldGC</jvm-options>
<jvm-options>-XX:ParallelGCThreads=5</jvm-options>
1
votes

I don't know if you are referencing this answer, but there is a second step described (disabling update module).

Two more ideas:

  1. Check if the NO_NETWORK=true option really works (there should be no ads in GF admin console)

  2. Watch the server.log (glassfish-install-dir/glassfis/domains/domain1/logs) during startup and look for the last log entry before the delay occurs. This could be a hint for the source of the delay.

0
votes

Beware of blindly following Dario's example unless you've lots more RAM than most do.

-Xms3000m gives 3gb to Glassfish. Do YOU have that much spare RAM?

I tried this on my 4gb Mac with 1gb for Glassfish. Made no discernable difference at all...performance still sux.