Sep 9th, 2008, 05:02 AM
Protect application from overloading
I would like to know if Spring Security suitable to this case.
Our application is a online application which have many users. Sometime, during peak hour or occasional events, website traffic will become crazily high. It causes slow response time. Sometimes, back-end system is also crashed by too many traffic sent by our application.
We want to protect our application in this way:
Suppose we have a method: SvcA.updateOrder(), which sends a order message to backend and wait for reply. We want to prevent more than 10 users called this method within a 10 seconds interval.
For example, if we have
Time No. of times called SvcA.updateOrder()
5 9 (<-- normal as <10 times in past 10 secnods)
6 1 (<-- normal as <10 times in past 10 secnods)
7 1 (<-- we want this call will throw an exception or trigger a callback to do something else)
We want to implement this by AOP so that we can easily configure which method is protected by such mechanism. I found this use case is similar to method level security. Am I right?
If I were right, what is the preferred approach for me to store "No. of times called" state? Any interface recommended to implement?
Sep 9th, 2008, 08:33 AM
Why Spring Security... There is nothing preventing you from using just AOP and add it. I believe there is even a sample in the AspectJ book from ramnivas or at least some where on the web.
Also you might want to reconsider your architecture, does it have to be a blocking call? Why not simply use JMS, put the message on the queue and let a Listener put it in the database. Fire and forget, if it is on the queue/topic it is ok. That can really increase your troughput.
Sep 23rd, 2008, 10:15 PM
Why we think of Spring Security is that we think our requirements are just an extended idea of security protection. We are trying to protect method invocations based on some criteria other than authorities / ACLs.
Having said that, we still think the information that Spring Security keeping track are useful. For example, the UserDetails.
Consider a use case: when the system is under heavy load. We may want to permit only administrator to access all methods and deny other users to access some methods. In this case, we need the UserDetails object (or the authentication information in general) to determine the logic we apply in the around advice.
Tags for this Thread