users@glassfish.java.net

[gf-users] Re: [3.1.2.2] Protecting from 404 during startup

From: Pawel Veselov <pawel.veselov_at_gmail.com>
Date: Wed, 4 Jun 2014 16:58:38 -0700

Hi Steven,

On Wed, Jun 4, 2014 at 4:29 PM, Steven Siebert <smsiebe_at_gmail.com> wrote:

> A terrible thought popped into my head that would probably be simple
> to implement:
>
> create/modify the GF startup script you use to first disables the HTTP
> network listeners you don't want running (ie keep the admin listener
> port up if you use it) in the domain.xml file by adding/changing the
> <network-listener> enabled attribute to "false". Then start normally.
> You wouldn't need to worry about graceful/unscheduled shutdowns
> because you would first change the attribute before starting up every
> time. Then, after startup is complete, you can use the asadmin
> command to enable the network listeners.
>

That's a great idea, thank you!
I'll definitely give it a try. Should be easy considering that I
already have shell wrappers for starting/stopping the server.

-- Pawel.


>
> S
>
> On Wed, Jun 4, 2014 at 6:38 PM, Pawel Veselov <pawel.veselov_at_gmail.com>
> wrote:
> > On Wed, Jun 4, 2014 at 2:53 PM, Oleksiy Stashok <
> oleksiy.stashok_at_oracle.com>
> > wrote:
> >>
> >> Hi Pawel,
> >>
> >> unfortunately it's not possible to do in general, but AFAIR it should
> work
> >> fine for AJP listener (not HTTP).
> >> So if you put Apache as a front-end and redirect requests to Glassfish
> via
> >> AJP protocol - it should not report 404 error during startup.
> >
> >
> > Unfortunately, we had serious performance issues with Apache HTTPD, and
> > ha-proxy doesn't speak AJP....
> > I'll just have to manually exclude the instance from ha-proxy then,
> until it
> > fully starts-up...
> >
> > Thank you.
> >
> >>
> >>
> >> Thanks.
> >>
> >> WBR,
> >> Alexey.
> >>
> >>
> >>
> >> On 04.06.14 13:27, Pawel Veselov wrote:
> >>>
> >>> Hi.
> >>>
> >>> Is there a way to avoid the GF server open it's HTTP listener until all
> >>> of the applications have been started? Otherwise, the request bounce
> back
> >>> with 404, until the start-up phase finishes...
>
>