1

In my J2EE web app, I have to send a count for every Web API call to an isolated thread for counting the number of calls. Possibilities include:

a) Use an atomic long. I think that would cause contention in case I have millions of calls in a minute. As, all the threads will try to update a single variable.

b) Use a shared queue. Every request processing thread will insert into the queue, and the dedicated counter thread will dequeue from that queue and increment the count.

c) Use actor model, say using Akka library. Send an asynchronous message to the actor, and that will add it up to the count.

My question is how does method (b) compare to (c). What are the pros and cons, and how they are different at low level?

ptntialunrlsd
  • 794
  • 8
  • 23
  • How many milllions of calls in a minute will you have? – V G Oct 15 '15 at 10:05
  • 2 million calls for now. Going ahead, it may be required that some more metrics other than the count, are also stored. So, the design should be scalable. – ptntialunrlsd Oct 15 '15 at 10:28
  • If it's just a count, use a LongAdder. Millions per minute is not that many. – Viktor Klang Oct 15 '15 at 13:47
  • Also, in the case when the performance of the web app is very crucial, and going ahead I can have many counts like this? Won't this clutter the application with too many shared variables and contention among threads? – ptntialunrlsd Oct 15 '15 at 20:15

1 Answers1

1

In your case I believe Actor model should be a better option. Pros with Akka-

  • Actor Model with Akka will take care of the thread management and it is easy to implement
  • Further, in future if you want to implement counter for different kind of request, you can simply add a new actor for that.

There is a similar question at- When to use actors instead of messaging solutions such as WebSphere MQ or Tibco Rendezvous?

Community
  • 1
  • 1
Radioguy
  • 23
  • 4