Please consider below scenario.
I have implemented apache load balancer using mod jk. There are three tomcat behind apache load balancer. They all are in diffrerent machines. Let's say tomcat-1 is serving a request & before completing a request it goes down due to some issue.As Tomcat clustering has been configured, other two tomcat will handle further request. But how to handle that failed request which has already been accepted by tomcat-1. Is there any solution ?
To have your proxy retry your request on another node after a failure, mod jk would need to know that a request was idemopotent.
I do see that adding this knowledge of idemoptency was discussed a long time ago. https://bz.apache.org/bugzilla/show_bug.cgi?id=39692
I doubt that they implemented this functionality.
I have seen other reverse proxy solutions implement an idempotency identifier. I seem to remember Weblogic having this ability. I have also seen it with certain hardware proxies.
Related
I have a system where several (20 or so) web app servers (hosting a website) talk to the same 2 - 4 EJB servers (through a VIP). I'd like to know if it is possible to identify which one of those app servers generated a specific request.
For example: Website example.com works by sending HTTP requests to any of 20 app servers to handle the request. These servers are named (internally) app01 through app20. It is ensured that all requests with the same session ID will be routed to the same app server, thus enabling us to logically track all requests from a single user. Some requests will need some extra data not available directly, for which there is an EJB (2.1) application on another cluster of 3 servers, named ejb01 to ejb03. Connections to the EJB servers are made through a VIP (ejb00), which routes the requests round-robin style to the three EJB serves.
Within the logging (we use Apache Log4J) of the EJB servers, it would be really nice if I could identify which of the 20 app servers a request originated from. The alternative is checking the logs on each server separately - but I don't have a good way to grep through the logs on 20 different boxes.
My question is: is this possible within Standard EJB? I'd be willing to do something non-standard, if there was nothing else, but it's gotta be reliable and work on my system. We use Weblogic 11g, both for the web-app and the EJB servers.
I've seen suggestions to pass the identity of the caller as a parameter, but that would mean an extra parameter for each of 20+ EJB methods, and that's rather unwieldy.
Any solutions, anyone?
There is no standard solution. There was a proposal in JSR 149, but it was withdrawn. Adding an extra parameter to the remote methods is probably your best option. If you're using RMI remote, you might be able to write an ORB interceptor to add a custom context on the client side, receive it on the server side, and set a thread local around the method invocation on the server.
WebSphere Application Server has a non-standard solution called work areas, which does work for remote EJB.
I am not familiar with WebLogic, so I don't know if they have a similar solution. Searching for similar terms finds a WorkContextMap that looks similar, but I don't know if it works for remote EJB since all the examples I can find are for webservices.
Our application currently uses Spring's HttpInvokerProxyFactoryBean to expose a Java service interface, with POJO requests and responses handled by our single Tomcat server. This solution allows us to have a pure Java client and server, sharing the same Java interface. Due to increased load, we are now looking into the possibility of load balancing across multiple Tomcat instances.
It would be nice if we could make this transition while retaining the same Java interface, as this would minimise the additional development required. Googling seems to suggest that the most common solution for Tomcat load balancing is to use Apache http server together with mod_jk, but I presume this would mean using some communication mechanism other than Spring's HTTP invoker? Is there a better solution which would allow us to retain more of our current code? If not, what would be involved in transitioning between what we have now and Apache/mod_jk?
Any help would be greatly appreciated as I don't have any experience in this matter.
We are using Tomcat 7 for our web application. We provide an XML based API so that our customers can communicate with our server in a machine-to-machine way (no web browser needed). The requests are processed by a servlet.
We need to prevent users from sending too many requests in a row. Some of the services we provide involve polling for results and users may make requests in a loop without any pauses, making dozens of requests per second for nothing.
How can we protect ourselves from being flooded with useless requests? Is there a simple way to block requests at the servlet entry level when there are too many requests originating from the same IP? Is there something built-in Tomcat to deal with this problem?
Assuming that you are using an apache reverse-proxy in front of tomcat (if you aren't you should be), use mod_cband on the apache layer.
You could code your own.
Starting points for looking at this would be the Servlet API, in particular the Filter interface and the getRemoteHost() method of the SerlvetRequest interface.
Should be easy enough to write a Filter implementation which stores a count of requests from each host and takes action if a limit exceeded.
Spring Security has a lot of the features of Apache httpd's mod_security if you want a Java-only solution.
Apache's mod_evasive
or mod_security
could cover for your need here. You may consider Cloudflare for more complexly serious attacks that will require hardware protection.
I am developing a simple REST API using Spring 3 + Spring MVC. Authentication will be done through OAuth 2.0 or basic auth with a client token using Spring Security. This is still under debate. All connections will be forced through an SSL connection.
I have been looking for information on how to implement rate limiting, but it does not seem like there is a lot of information out there. The implementation needs to be distributed, in that it works across multiple web servers.
Eg if there are three api servers A, B, C and clients are limited to 5 requests a second, then a client that makes 6 requests like so will find the request to C rejected with an error.
A recieves 3 requests \
B receives 2 requests | Executed in order, all requests from one client.
C receives 1 request /
It needs to work based on a token included in the request, as one client may be making requests on behalf of many users, and each user should be rate limited rather than the server IP address.
The set up will be multiple (2-5) web servers behind an HAProxy load balancer. There is a Cassandra backed, and memcached is used. The web servers will be running on Jetty.
One potential solution might be to write a custom Spring Security filter that extracts the token and checks how many requests have been made with it in the last X seconds. This would allow us to do some things like different rate limits for different clients.
Any suggestions on how it can be done? Is there an existing solution or will I have to write my own solution? I haven't done a lot of web site infrastructure before.
It needs to work based on a token included in the request, as one client may be making requests on behalf of many users, and each user should be rate limited rather than the server IP address.
The set up will be multiple (2-5) web servers behind an HAProxy load balancer. There is a Cassandra backed, and memcached is used. The web servers will be running on Jetty.
I think the project is request/response http(s) protocol. And you use HAProxy as fronted.
Maybe the HAProxy can load balancing with token, you can check from here.
Then the same token requests will reach same webserver, and webserver can just use memory cache to implement rate limiter.
I would avoid modifying application level code to meet this requirement if at all possible.
I had a look through the HAProxy LB documentation nothing too obvious there, but the requirement may warrant a full investigation of ACLs.
Putting HAProxy to one side, a possible architecture is to put an Apache WebServer out front and use an Apache plugin to do the rate limiting. Over-the-limit requests are refused out front and the application servers in the tier behind Apache are then separated from rate limit concerns making them simpler. You could also consider serving static content from the Web Server.
See the answer to this question How can I implement rate limiting with Apache? (requests per second)
I hope this helps.
Rob
You could put rate limits at various points in the flow (generally the higher up the better) and the general approach you have makes a lot of sense. One option for the implementation is to use 3scale to do it (http://www.3scale.net) - it does rate limits, analytics, key managed etc. and works either with a code plugin (the Java plugin is here: https://github.com/3scale/3scale_ws_api_for_java) which pushes or by putting something like Varnish (http://www.varnish-cache.org) in the pipeline and having that apply rate limits.
I was also thinking of the similar solutions a couple of day's ago. Basically, I prefer the "central-controlled" solution to save the state of the client request in the distributed environment.
In my application, I use a "session_id" to identify the request client. Then create a servlet filter or spring HandlerInterceptorAdapter to filter the request, then check the "session_id" with the central-controlled data repository, which could be memcached, redis, cassandra or zookeeper.
We use redis as leaky bucket backend
Add a controller as entrance
google cache that token as key with expired time
then filter every request
It is best if you implement ratelimit using REDIS. For more info please look this Rate limiting js Example.
I have a problem. I need to host many (tens, hundreds) of small identical JAVA web applications that have different loads during one time. I want to use Glassfish V3. Do I need to use a load balancer and clusters or something else? Advise where can I find information about similar problems and their solutions...
I need to host many (tens, hundreds) of small identical JAVA web applications that have different loads during one time.
For hundreds of webapps, you will very likely need more than one app server instance. But this sounds odd to be honest.
I want to use Glassfish V3. Do I need to use a load balancer and clusters or something else?
Right now, GlassFish v3 offers only basic clustering support using mod_jk (i.e. no load balancer plugin, no centralized admin, no high availibility). If you are interested, have a look at this note that describes the configuration steps of GFv3 and mod_jk.
For centralized admin and clustering, you'll have to wait for GlassFish 3.1 (see the GlassFish Roadmap Community Update slides).
You could check out Gigaspaces. I have seen it used in conjunction with Mule for a somewhat similar project. ESBs tend to be overkill in my opinion, but it sounds like you have quite the task to conquer.
Based on your requirements, you cannot do load balancing since the load is predetermined by which client the request is for. Each request has to go to the app handling that client, so it cannot be distributed outside the set of apps dedicated to that client.
You can use multi-threading. you could set up the configuration so that different threads handle different clients. However, it might be better to simply have a server that can handle requests from different clients. Based on the client sent with the request, it would be dispatched to a different database etc.