dev@glassfish.java.net

Re: deployed war not showing up after server restart

From: Ken Cavanaugh <Ken.Cavanaugh_at_Sun.COM>
Date: Wed, 27 Feb 2008 13:26:57 -0800

Jeanfrancois Arcand wrote:
>
>
> Jerome Dochez wrote:
>> Ok but then u end up blocking everyone.
>
> Not sure I understand why you would block everyone. You will block
> only the asadmin commands that cannot yet be executed for some reason.
>
> How can you discriminate
>> applications at the Tcp level before loading at least the deployment
>> actifacts ?
>
> Yes. Grizzly ARP just need a matching 'token' to use when a TCP
> request comes in. So if we say that all requests that matches
> 'XXX-ttt&A=B' cannot yet be executed, ARP will suspend the request,
> release the thread and resume the request only when some 'external'
> services notify ARP that they can now serve the request. This is what
> the open-esb/httpbc use since v1 and it seems to work fine :-). I
> suspect we can do the same for v3 at tcp/udp/tls level.
> A+
>
Should this be part of the whole request unification framework (maybe it is,
but I don't know what you already have). For example, if we accept a new
connection on which the first request begins with the characters "GIOP",
we should start up the EJB container if its not already running, suspending
further processing of that connection until the EJB container is
initialized.
Then we need to give that connection to the ORB's ProtocolParser to
handle incoming messages.

Is port unification a committed feature for GFv3? If so, we may want to
consider
adding IIOP to the protocols handled for port unification, now that we
have the
ORB running on Grizzly.

Thanks,

Ken.