4

I am not sure how to phrase this, but any ideas about how to achieve the below behavior would be great.

I have web server that makes long running calls to a command line program. I want the server to handle multiple long running calls, but not return a given request until the call is complete. This is not a website, so it is okay that the calls run a very long time, and the client will not timeout either. Any ideas about how to achieve this?

Is this link relevant? writing a multiplexing server in clojure?

user1559027
  • 343
  • 2
  • 13

2 Answers2

7

Given that Luminus generates a war file (which I assume it does, because it runs on top of ring and compojure) then it is already "multi-threaded" in that when you run that war file in tomcat or jetty, each request will get its own thread.

Clients can set their socket read timeout to infinite and they'll wait forever.

Kevin
  • 24,871
  • 19
  • 102
  • 158
  • Thanks for your response. Right now, I just run the uberjar. Is using tomcat or jetty necessary for this behavior? I am just trying to keep complexity down if possible. – user1559027 Jul 02 '14 at 01:21
  • 1
    I think uberjar creates an embedded jetty server, so its fine. I'm not sure if you can tune the number of request threads when you run that way, however. – Kevin Jul 02 '14 at 15:45
3

If your calls are long for any reason other than CPU usage, your best option will be to use http-kit or aleph in an uberjar. Unlike the other servers, http-kit and aleph use a thread pool rather than a thread per request, and if you have any bottleneck other than CPU usage (for example an arbitrary sleep time, network or disk io, etc.), than a thread pool will perform much better than a thread per request would.

http-kit client / ring server
aleph client / ring server

noisesmith
  • 20,076
  • 2
  • 41
  • 49
  • I found this useful information, but it is actually CPU usage that causes that causes requests to wait. It might be great to know this later though. – user1559027 Jul 02 '14 at 18:09