CDV ❯ DSO NIO setup inteferes with Glassfish NIO use

• Type: Bug
• Status: Resolved
• Priority: 2 Major
• Resolution: Won't Fix
• Component/s: DSO:L1
• Labels:

• Assignee: teck
• Reporter: teck
• Created: April 17, 2007
• Votes: 0
• Watchers: 0
• Updated:

  September 06, 2013
• Resolved:

  September 06, 2013

Description

Since the DSO client starts up very early in the VM boot process, we have the side effect of calling into NIO before Glassfish can have it’s way with it. In particular when we setup our comms stuff, we cause some of the static NIO classes to be initialized (ie. SelectorProvider, etc). There is code in glassfish that wants to some custom initialization there, but it can’t since DSO has already called into NIO and initialized stuff.

The net effect of this is that you’ll get a BindException trying to start a duplicate RMI listener when glassfish boots and DSO is in the mix. The current solution to this is to disable Glassfish’s “quickstart” mode which will bypass any of the fancy NIO customization it wants to do. This implies special setup to glassfish to make it run with DSO, in particular you need to add -Dcom.sun.enterprise.server.ss.ASQuickStartup=false to your domain.xml

It’d be nice if either we could all play nice somehow, or if we could disable this feature automagically. Doing the latter should only be done if we find out exactly if there are any unacceptable consequences of disabling “quickstart”

According to people at Sun, this feature is not going to be present in glassfish V3, so we probably shouldn’t spend much effort to develop automagic workarounds

Comments

Fiona OShea 2007-04-23

is this already resolved?