Skip to main content

Glassfish V3 as a Service on Windows Server

18 replies [Last post]
Anonymous

Hi all.

Just a quick question: When I tried to find a solution for installing
Glassfish V3 as a Service on a Windows Server 2003 R3, Standard x64
edition, Service Pack 3, I stumbled across the create-service command.

Unfortunately the output is as follows:

C:\glassfishv3\bin>asadmin create-service domain1
Error while trying to install GlassFish as a Windows Service.
The return value was: 128.
STDERR:
STDOUT:
Usage: asadmin [asadmin-utility-options] create-service [--name ]
[--serviceproperties ]
[--dry-run[=]] [--domaindir ]
[-?|--help[=]] [domain_name]
Command create-service failed.

Any one with an idea on how to move on from here?

Thanks.

Thomas.

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@glassfish.dev.java.net
For additional commands, e-mail: users-help@glassfish.dev.java.net

Reply viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
pranabsharma
Offline
Joined: 2011-01-13

I also faced the same problem while creating glassfish service in a Windows 2003 server. This problem came because of not having the .net framework installed in my Windows 2003 server. I installed .net framework 3.5 sp1 and after that I succeeded in creating glassfish service.

bnevins
Offline
Joined: 2005-03-28

Winsw == Windows Service Wrapper == a Kenai project. It is a .NET C# project that is located here:

http://projectkenai.com/projects/winsw

=====================================

"Allow service to interact with Desktop" is almost always a bad idea. We don't need or want it in V3. It is **not** used in V2 either.

=====================================

The V3 service is using this:

asadmin start-domain --verbose

V2 service uses this:

asadmin start-domain

There is a huge difference. When verbose is on, the asadmin JVM starts the server JVM. The asadmin JVM hangs around like a watchdog and also echoes server log messages. When the asadmin JVM is killed the Server dies. If the server is killed, the asadmin JVM is killed. They live together. They die together. They are like the two musketeers.

Try it in a console window -- start the domain with verbose. Kill the server from a different window. Watch what happens. Try running "asadmin restart-domain" from another windows and see even more amazing results!

In V2 the asadmin JVM fires off the server and promptly dies.

As a result in V2 -- Windows Services has no clue if the server dies.
In V3 Windows Services detects it immediately. Try it. Start V3 as a Service. Then kill the server from a command prompt (asadmin stop-domain) -- note that Windows detected it.

==================

-Xrs ought to work. This is a JVM & System level setting. I'll try to free up some time next week to experiment with it. You may want to try setting the logon to YOU rather than "Local System"..

bnevins
Offline
Joined: 2005-03-28

Actually I think you have a point! It isn't good enough to have just the server ignore logouts. The asadmin JVM ALSO needs to ignore logouts. Remember if one goes down, it takes the other down with it. I'll bet that's the problem.

The solution is documented here:
http://blogs.sun.com/foo/entry/how_to_make_v3_platform

In a nutshell do this:

1) set -Xrs in domain.xml
2) add "-Xrs" to the java command inside the asadmin script

Message was edited by: bnevins

NBW

Hi Byron,

Thanks for the detailed response! My comments are inline.

On Sat, Feb 13, 2010 at 5:07 AM, wrote:

> Actually I think you have a point! It isn't good enough to have just the
> server ignore logouts. The asadmin JVM ALSO needs to ignore logouts.
> Remember if one goes down, it takes the other down with it. I'll bet
> that's the problem.
>
> Work-around -->
>
> in <>/bin edit the Service.xml file and add "-Xrs"
> as a parameter (it will be obvious how to do that).
>
>
So in looking at the file it was not obvious to me where/how to add the JVM
parameter and here's why. The file points the service wrapper at asadmin.bat
and there's a bunch of startup parameters which get passed along to the bat
file. The business in asadmin.bat gets done with the following:

%JAVA% -jar "%~dp0..\glassfish\modules\admin-cli.jar" %*

Now, I'm no BAT file ninja and I haven't looked at the source to the service
wrapper, but I am guessing that all the in
domain1Service.xml are going to be passed into %*. So if I were to add -Xrs
as a it would end up at the tail of that java command. The
man page for the java command specifies that options, -X args included, need
to preceed the -jar arg. With that in mind it wasn't obvious how I could
modify that XML file to have -Xrs passed in as needed.

So, what I did do is add it to the asadmin.bat file like so:

%JAVA% -Xrs -jar "%~dp0..\glassfish\modules\admin-cli.jar" %*

This did the trick, however, I don't really like it because it will affect
not only the service's use of the bat file but everyones use of the bat file
but at least it proved the theory.

On a related note, you mentioned that winsw is on Kenai - since Oracle has
announced that Kenai is going away (at least to the general public) will
this project be moved elsewhere that will continue to be publicly available?

Also, you mentioned that v3 uses -verbose and v2 does not (when run as a
service). v2 has the --versbose option available. Does it behave the same
way as you described it in v3?

Lastly, what role does the ProcessLauncher play in all this. There's the
processLauncher.xml file whose comments indicate that 's can
contain non-settable JVM options as it indicates too that settable ones are
to come from domain.xml. This would imply that the options in
processLauncher.xml are combined with the JVM options in domain.xml and used
by the ProcessLauncher to launch the server JVM. If that is the case then
what isn't clear to me is why there are reports that to solve the -Xrs
problem under v2, on some platforms (server 2003 I think) it only worked if
they added -Xrs to both the domain.xml and the processLauncher.xml.

Thanks again, your feedback has been very helpful!

-NBW
[att1.html]

bnevins
Offline
Joined: 2005-03-28

1. Yes -- the solution is putting "-Xrs" in asadmin.bat file. I independently discovered that after I had already posted the bum steer about domain1Service.xml. It's in my blog:

http://blogs.sun.com/foo/entry/how_to_make_v3_platform

I would not worry about having -Xrs in asadmin.bat because in the typical case it only runs for a few seconds doing a command. What are the chances of it running when a Logout is done AND you don't want asadmin to ignore the Logout. If it was a concern -- simply copy the asadmin script, modify it and then refer to that copy in domain1Service.xml

2. Yes Winsw will not go away. It will move over to dev.java.net eventually.

3. Verbose mode on V2 has the same behavior on V2 and V3. If it was used on V2 for services -- the "DOS box" would remain and clutter up the screen.

4. processlauncher.xml is history. There were messy complicated reasons for why it was needed in V2 -- which I don't remember anymore. One key reason for it to exist is that Node Agent has no other way of getting JVM options set.

tmpsa
Offline
Joined: 2010-02-01

1. Why isn't this the default in the Glassfish install kit?

2. I run GF 3 as a Windows Service using appservService.exe (which I think was included in the GF2 kit, but not in the GF3 kit!?). Perhaps I could just add --noverbose to the part of the command line that invokes asadmin?

Cheers,
Per Lindberg

NBW

Hi Byron -

Here's my log as well, as you can see there's -Xrs and things still aren't
working properly:

Feb 12, 2010 12:19:53 PM com.sun.enterprise.admin.launcher.GFLauncherLogger
info
INFO: JVM invocation command line: C:\Sun\SDK\jdk\bin\java.exe -cp
C:/glassfishv3/glassfish/modules/glassfish.jar
-XX:+UnlockDiagnosticVMOptions
-XX:MaxPermSize=192m
-XX:NewRatio=2
-XX:+LogVMOutput
-XX:LogFile=C:\glassfishv3\glassfish\domains\domain1/logs/jvm.log
-Xrs
-Xmx512m
-client
-javaagent:C:/glassfishv3/glassfish/lib/monitor/btrace-agent.jar=unsafe=true,noServer=true
-Dosgi.shell.telnet.maxconn=1
-Djdbc.drivers=org.apache.derby.jdbc.ClientDriver
-Dfelix.fileinstall.dir=C:\glassfishv3\glassfish/modules/autostart/
-Djavax.net.ssl.keyStore=C:\glassfishv3\glassfish\domains\domain1/config/keystore.jks
-Dosgi.shell.telnet.port=6666
-Djava.security.policy=C:\glassfishv3\glassfish\domains\domain1/config/server.policy
-Dfelix.fileinstall.poll=5000
-Dcom.sun.aas.instanceRoot=C:\glassfishv3\glassfish\domains\domain1
-Dcom.sun.enterprise.config.config_environment_factory_class=com.sun.enterprise.config.serverbeans.AppserverConfigEnvironmentFactory
-Dosgi.shell.telnet.ip=127.0.0.1
-Djava.endorsed.dirs=C:\glassfishv3\glassfish/modules/endorsed;C:\glassfishv3\glassfish/lib/endorsed
-Dcom.sun.aas.installRoot=C:\glassfishv3\glassfish
-Djava.ext.dirs=C:\Sun\SDK\jdk/lib/ext;C:\Sun\SDK\jdk/jre/lib/ext;C:\glassfishv3\glassfish\domains\domain1/lib/ext
-Dfelix.fileinstall.bundles.new.start=true
-Djavax.net.ssl.trustStore=C:\glassfishv3\glassfish\domains\domain1/config/cacerts.jks
-Dcom.sun.enterprise.security.httpsOutboundKeyAlias=s1as
-Djava.security.auth.login.config=C:\glassfishv3\glassfish\domains\domain1/config/login.conf
-DANTLR_USE_DIRECT_CLASS_LOADING=true
-Dfelix.fileinstall.debug=1
-Dorg.glassfish.web.rfc2109_cookie_names_enforced=false
-Djava.library.path=C:/glassfishv3/glassfish/lib;C:/Sun/SDK/jdk/bin;C:/WINDOWS/system32;C:/WINDOWS/Sun/Java/bin;C:/WINDOWS;C:/Perl/site/bin;C:/Perl/bin;G:/oraclexe/app/oracle/product/10.2.0/server/BIN;C:/Program
Files (x86)/PHP;C:/WINDOWS/system32/wbem;C:/Program Files
(x86)/Vim/vim72;C:/Program Files
(x86)/eclipse;C:/instantclient_10_2;C:/Program
Files/TortoiseSVN/bin;C:/Program Files (x86)/Common Files/Acronis/SnapAPI
com.sun.enterprise.glassfish.bootstrap.ASMain -domainname domain1
-asadmin-args
start-domain,,,--verbose,,,--domaindir,,,C:/glassfishv3/glassfish/domains,,,domain1
-instancename server -verbose true -debug false -asadmin-classpath
C:/glassfishv3/glassfish/modules/admin-cli.jar -asadmin-classname
com.sun.enterprise.admin.cli.AsadminMain -upgrade false -domaindir
C:/glassfishv3/glassfish/domains/domain1 -read-stdin true
Feb 12, 2010 12:19:54 PM com.sun.enterprise.admin.launcher.GFLauncherLogger
info
INFO: Successfully launched in 63 msec.

On Thu, Feb 11, 2010 at 3:09 PM, wrote:

> The issue you are having is at a JDK level. Take a look in server.log
>
> The exact commandline that the JDK is started with is written to the log
> every time the server starts. Is "-Xrs" in there?
>
> Try it without running as a service -- after all the main thing the Service
> does is simply
>
> asadmin start-domain
>
> -- does it work when you start the server manually?
> [Message sent by forum member 'bnevins' (byron.nevins@sun.com)]
>
> http://forums.java.net/jive/thread.jspa?messageID=386229
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@glassfish.dev.java.net
> For additional commands, e-mail: users-help@glassfish.dev.java.net
>
>
[att1.html]

NBW

Hi Brian,

One difference I have noticed between v2.x and v3 with respect to the
Window's service support is that the installer for v2 installs the service
with the "Allow service to interact with desktop" check box enabled. This is
under the "Log On" tab of the service properties. Glassfish v3's service
installer does not do that. On a whim I checked enabled it for my GFv3
service and started the service. A windows cmd shell popped up, empty and
stayed up forever.

This is in contrast to when you start the v2 service and you see a Windows
cmd shell window with stdout going to it that eventually (and quickly)
closes itself. Now, if you close the shell window that is spawned by v3 the
GF process dies. Again, that is in contrast to the v2 behavior where the cmd
shell window comes and goes and the process stays up. The v3 behavior in
this regard feels like a symptom of the underlying issue which is causing GF
to die when you log out of the console, irrespective, of including -Xrs in
both the domain.xml and processLauncher.xml files.

I was also interested in looking at the source for winsw.exe but I only
found the exe itself checked into SVN. I'm assuming its checked into the v3
svn repo and I am just overlooking it, or is it somewhere else?

-NBW
[att1.html]

NBW

On Sat, Feb 13, 2010 at 12:55 AM, NBW wrote:

> Hi Brian,
>
>
>
Sorry, that should have read Byron not Brian.

-NBW
[att1.html]

stevecz
Offline
Joined: 2010-08-27

So after reading this post and searching around on Project Kenai's website, I found that he used .NET 2.0 to build his winsw.exe program, which is what is used to create the service wrapper.

I then installed the latest .Net 4.0 on my server, and this did not work, but the results were better than not having .Net installed. I then un-installed .Net 4.0 and reverted back to 3.5 SP1 and all of its lovely updates, and re-installed GlassFish, as I am just starting to deploy it at this time (some may not have this option, not sure if it mattered or not). I then ran the "asadmin create-service" and worked like a charm, adding a "domain1 Glassfish Service" to my list of Windows Services. I am able to stop and start the service and log off of the machine, with the service still running. I did add the -Xrs to my java options just to be sure, but things seem to be working nicely.

Steve

bnevins
Offline
Joined: 2005-03-28

Please setup debug output, and post it here.

1. set AS_DEBUG=true
2. asadmin create-service (no need to enter a domain name if you only have one)

What happens when a 32-bit exe runs on 64bit Windows? Doesn't Windows recognize it as 32-bit? Can that be the problem?

nmsakos
Offline
Joined: 2010-02-09

Hi!

I had the same problem. I've set as_debug, and attached file.

Thanks!

nmsAkos

bnevins
Offline
Joined: 2005-03-28

Unfortunately we do not support 64 bit Windows. Perhaps in the next update release?

nmsakos
Offline
Joined: 2010-02-09

> Unfortunately we do not support 64 bit Windows.
> Perhaps in the next update release?

Hi!

I'm sad about it.

I red anywhere that i can disable the function in the AS that listens to windows events, and shuts itself down when the user logs out.

I set in the domain.xml:
-Xrs

but it doesn't help.

Is in v3 any other option?

Thanks
Ákos

NBW

I just posted about this very topic. I'm suffering the same problem on
Windows XP Pro w/GF v3. v2 had this issue and you could set things straight
by adding the -Xrs option to domain.xml and processLauncher.xml files but
that doesn't appear to work with v3. Why this problem has to even exist and
isn't instead solved when you run the create service tool to begin with is
maddening.

-NBW

On Tue, Feb 9, 2010 at 3:33 PM, wrote:

> > Unfortunately we do not support 64 bit Windows.
> > Perhaps in the next update release?
>
> Hi!
>
> I'm sad about it.
>
> I red anywhere that i can disable the function in the AS that listens to
> windows events, and shuts itself down when the user logs out.
>
> I set in the domain.xml:
> -Xrs
>
> but it doesn't help.
>
> Is in v3 any other option?
>
> Thanks
> Ákos
> [Message sent by forum member 'nmsakos' (nmsakos@gmail.com)]
>
> http://forums.java.net/jive/thread.jspa?messageID=385748
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@glassfish.dev.java.net
> For additional commands, e-mail: users-help@glassfish.dev.java.net
>
>
[att1.html]

bnevins
Offline
Joined: 2005-03-28

The issue you are having is at a JDK level. Take a look in server.log

The exact commandline that the JDK is started with is written to the log every time the server starts. Is "-Xrs" in there?

Try it without running as a service -- after all the main thing the Service does is simply

asadmin start-domain

-- does it work when you start the server manually?

nmsakos
Offline
Joined: 2010-02-09

Yes. In the server.log there is the -Xrs option, and cannot see any error.
But in the jvm.log is some error-like rows.

I attach the log file, maybe it has for someone any useful information.

km
Offline
Joined: 2005-10-28