Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [jetty-users] Equivalent of HandlerList for Servlets
Bill,

Jetty has Proxy and Middleman components that can be used for load balancing.   Using jetty for balancing will never be as efficient as dedicated balancers, however it can be a good idea if:
 + the decision of what back end to use is complex and needs to inspect the request
 + if processing/transformation is to be done in the load balancer of either request/response
 + the application is much more of a load than running the protocol, so that any extra inefficiencies of app space balancing would be outweighed by the gains from reducing load on the app servers themselves.

regards
 

On Sat, 14 Dec 2019 at 11:25, Bill Ross <ross@xxxxxxxxxxxx> wrote:
> But the question would be, how is the correct handler going to be picked from that list?  

Out of curiosity, would it be efficient/maintainable to use Jetty as a load balancer, such that each handler would manage load for a given back end, and they'd be chosen by sorting handlers (hanglers once you can misspell) according to load?

Bill

On 12/13/19 3:07 PM, Greg Wilkins wrote:

Note also that if you have a need, there is nothing preventing you from having a HandlerList within a ContextHandler.

But the question would be, how is the correct handler going to be picked from that list?    

For ContextHandlerCollection, the context path (and some virtual host stuff) is used to pick which ContextHandler the request is given to.
For a normal HandlerList, each listed handler is called in turn until one of them handles it.
A ServletHandler picks a servlet by the pathInfo and will always handle a request - if only with a 404, so a HandlerList of normal ServletHandlers makes little sense.

But if you have some other criteria to select between different ServletHandlers, then you can have a custom HandlerList within a context that could apply that criteria.






On Fri, 13 Dec 2019 at 23:55, Karel Goderis <karel.goderis@xxxxxx> wrote:
Thanks Joakim

That’s clear.

The stages do in fact respond to the same URL endpoint; I will have quick look if Filters (that filter based on some PDU bytes) can be a solution for this kind of situation

Thanks
K

On 13 Dec 2019, at 12:03, Joakim Erdfelt <joakim@xxxxxxxxxxx> wrote:

Since you haven't details what your ServletHandler are actually trying to do ("stage 1, stage 2, stage 3" means nothing), this reply is generic.

A ServletContextHandler belongs to a single context Path.

It manages the ServletContext for all Servlets and Filters and Listeners belonging to that ServletContext.

Each Servlet has a url-pattern it can belong to
Each Filter has a url-pattern it can participate in.

If you have multiple ServletHandlers, and expect them to respond on the same url-pattern, then you have a problem.

You should only have 1 "endpoint" to a HTTP resource.
You *can* have that single "endpoint" respond differently depending on request details (such as method, Content-Type, existence of request body content, Accept headers, Cache headers, etc...)
But that difference isn't handled by multiple servlets, it's handled by a single servlet, with logic to produce different responses accordingly.

If you have multiple ServletHandlers because some handlers respond on different url-patterns, then great!  You just use different url-patterns when you add them to the ServletContextHandler.

If you have multiple ServletHandlers because each handler does some subset of actions, then you are abusing ServletHandlers.
Use Filters for subsets and Servlets for "endpoint" logic.

Joakim Erdfelt / joakim@xxxxxxxxxxx


On Fri, Dec 13, 2019 at 4:37 AM Karel Goderis <karel.goderis@xxxxxx> wrote:
Yes, 

I am using a ServletConextHandler, however the question is : can you do the equivalent of HandlerList but with Servlets. AFAIK it is impossible to register different Servlets using the same Context path

Tx
K

On 13 Dec 2019, at 11:33, Joakim Erdfelt <joakim@xxxxxxxxxxx> wrote:

Use a ServletContextHandler.

Don't use ServletHandlers, those are internal structures not meant for direct usage.

Use ServletContextHandler.addServlet() and ServletContextHandler.addFilter()
You can add the Servlet as a Class reference, or as a Servlet instances (via a ServletHolder).

Joakim Erdfelt / joakim@xxxxxxxxxxx


On Fri, Dec 13, 2019 at 2:36 AM Karel Goderis <karel.goderis@xxxxxx> wrote:
Hi,

I have the practical need of splitting up a protocol implementation in 3 “parts”, because the protocol does a kind of “staged” setup whereby a connection goes through these steps in order. I also need the benefits of Contexts to maintain some state. Ideally, I would like to have the equivalent of a HandlerList but for Servlets being added to a ServletContextHandler. How could this be achieved?

Wrt to this question, I am confused about the ServletHolder.setServletHandler(). What is its purpose? Does it replace the handle() methods of the Servlet.class that is fed to the ServletHolder? Obviously, I tried to use setServletHandler() with a HandlerList, but that does not work. It is a bit lacking in the documentation and examples of how to used embedded Jetty.

My first attempt was something along the lines of

        HandlerList setupHandlers = new HandlerList();
        setupHandlers.addHandler(new StageOneHandler());
        setupHandlers.addHandler(new StageTwoHandler());
        setupHandlers.addHandler(new StageThreeHandler());

        ServletHandler setupHandler = new ServletHandler();
        setupHandler.setHandler(setupHandlers);

        ServletHolder setupHolder = new ServletHolder(DefaultServlet.class);
        pairSetupHolder.setServletHandler(setupHandler);

But I clearly missed something from an architecture point of view

The (IMO) ugly workaround is to put the 3 stages in a regular Servlet, and do an if-then based on some bytes of the protocol payload, but I prefer the more beautiful solution ;-) Any help is welcome

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

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

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


-- 

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


--
Greg Wilkins <gregw@xxxxxxxxxxx> CTO http://webtide.com

Back to the top