I think I want to simplify some things. Normally, client/server async is implemented by the client/server framework. What happens is the interchange of messages between the client and server through the http connection on the socket is made non-blocking. But the entire request/response still happens within the context of a single http connection.
This often allows for the server to take in many more requests, and for the client to overlap other processing while waiting. That's because open IO operations are cheaper then open threads. So modern hardware support many more concurrent open connections on a socket then it does open threads. If that's what you want, you need to move to a different client/server framework that supports non-blocking exchanges, such as Netty in the Java world. If you want to avoid moving framework, or your operations are going to be really long, or you want to survive network drop outs. Then you can go for something more like what you were trying to go for. In that case, you need to choose between push and pull. If pull, you want a distributed map as I said, which is often known as a database. A sql table can do, a nosql key/value store also works. I'm a fan of DynamoDB for this. Ideally, you want your distributed map to have equal scaling capability as your server APIs will, otherwise it will become a bottleneck. You can also go with a distributed queue, like RabbitMQ or AWS SQS. This allows the client to use a reactor evented response handling. Instead of having the client poll your get API to know if a response is availaible. You will put a message on the queue saying GUID-X is now done. And your client will work through the queue, and for every msg in it, it will poll you for the result. If you want Push, you need the client to expose an endpoint to be contacted on when done. You can do this easily with AWS SNS for example. This could mean the client exposes a call-when-done(guid, result) API. It tells your server about it, and when you are done, you send a request to that API to notify the client. It allows the client to know right away that its done, and saves it the CPU work of having to poll. But it gets complicated if you fail to reach the client's endpoint, what happens? So with push, you can often miss a response. To avoid that, people often offer both pull and push. So my practical recommendation to you would be to first look into a non-blocking client/server framework like Netty. Maybe that's all you need. If not, then look into using DynamoDB or SQS or SNS or similar products. -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups "Clojure" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
