On Wed, Feb 8, 2017 at 11:58 PM Simone Bordet <
sbordet@xxxxxxxxxxx> wrote:
Hi,
Hey, Simone.
On Wed, Feb 8, 2017 at 11:15 PM, Travis Spencer
<travislspencer@xxxxxxxxx> wrote:
> What about leaving the old one up and doing a permanent redirect to the new
> port and/or listening address? That's the only graceful way I can think of
> in light of long polling clients like you mentioned.
The application must do that.
Our app that embeds Jetty, you mean? If so, sure. That's fine.
>> We completely disable JMX.
>
> How would you access the server from remote without JMX or something similar
> ?
>
>
> Ya, something similar (and better IMHO) we have instead. Requires us to
> cycle Jetty though to change the thread count :( Would be very nice to avoid
Well, with JMX you could.
Jetty and our server are in the same address space and we provide a tailored configuration and management service in that same box. Requiring admins to use our API for all things except changing thread count where they must use an alternative API, JMX, isn't an option because of UX, security, etc. reasons. So, Jetty requiring us to use this API isn't desirable and I really don't see why that is a requirement from the Jetty side. Can the mbean be used directly from within our app that is embedding Jetty while the JMX server remains disabled? If not, some low level API is needed from Jetty IMO because pushing the requiment for JMX on apps isn't always reasonable, as in our case.
