Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [jetty-dev] Federation/Coordination of a "set" of Jetty instances

Hi,

I hope the following can help a bit more on the big picture:

        config.xml
            |
        Jetty-0
              |
        C1       C2        C3         C4
    Jetty-1  Jetty-2   Jetty-3  Jetty-4


* In above, C-X is a concrete object extract from config.xml that can perform certain operations.
* For each C-X, we configure and start an independent Jetty instance.
* Jetty-0 is able to manage the life cycle of the other Jetty instances such as stop, reload config, and so forth.
* Jetty-0 is able to add a new Jetty instance in case a new C5 appears in config.xml
* Every Jetty-(1-4) can have no affect on the operation of others in case we need to separately make changes to one of them.
* All Jetty-(1-4) provide the same REST API (though on different ports).
* Although all in one JVM, each Jetty instance uses a separate thread pool to serve its requests and as such is able to provide an independent layer of load management.

On the other side, one thing that directly comes to mind is that when for instance 50 instances of Jetty's are started on in one JVM, how would this affect the runtime performance of the single JVM? Any other concerns you can kindly refer based on this idea?

Thanks for mentioning Apache ZooKeeper, however, regarding its definition, it mainly targets "configuration coordination" which is not exactly our case.

The main purpose for me is to validate such an idea and if sensible look for best practices or advice from Jetty developer community.

Thanks,
Behrooz




On Fri, Sep 19, 2014 at 3:10 PM, Joakim Erdfelt <joakim@xxxxxxxxxxx> wrote:
zookeeper comes to mind.

--
Joakim Erdfelt <joakim@xxxxxxxxxxx>
Expert advice, services and support from from the Jetty & CometD experts

On Fri, Sep 19, 2014 at 6:08 AM, Jesse McConnell <jesse.mcconnell@xxxxxxxxx> wrote:
Can you elaborate a bit more about what sort of management you are
look for?  You mention having an abstraction layer over your jetty
instances and then wanting to use rest as well to manage things...are
you looking for an existing technology or project that does what you
need or are you just looking for advice on what that sort of rest
layout would work well?

Conceptually I get what you're looking for but I don't see enough of a
'problem statement' to say much one way or the other.

cheers,
Jesse


--
jesse mcconnell
jesse.mcconnell@xxxxxxxxx


On Fri, Sep 19, 2014 at 5:19 AM, Behrooz Nobakht <nobeh5@xxxxxxxxx> wrote:
> Hi,
>
> First, I'd appreciate your comment if the terminology of the subject of this
> email is not what it should be based on the following question.
>
> I am looking for a possible best practice to be able to manage a set of
> embedded Jetty instances started from another bootstrap application. I have
> an abstraction layer for each concrete instance of which I can start one
> embedded Jetty but yet want to be able to manage their life cycle when
> necessary (and possibly through REST which the bootstrap application
> provides for all of them).
>
> I hope that is enough of the problem statement to start a discussion. And, I
> still prefer not to think of OSGi-based solutions at this moment.
>
> Thanks in advance,
> Behrooz
>
>
> _______________________________________________
> jetty-dev mailing list
> jetty-dev@xxxxxxxxxxx
> To change your delivery options, retrieve your password, or unsubscribe from
> this list, visit
> https://dev.eclipse.org/mailman/listinfo/jetty-dev
_______________________________________________
jetty-dev mailing list
jetty-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/jetty-dev


_______________________________________________
jetty-dev mailing list
jetty-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/jetty-dev



--
-- Behrooz Nobakht

Back to the top