I have a service that can easily be expressed as a Flow from Request to
Response ("the service flow"), which I want to accept up to (e.g.) 10
requests at given point in time, rejecting the overflow. I want to model
both service and clients as streams. In order to impose a single buffer
boundary, I need to materialize the service flow once and reuse it for
multiple short-lived client flows. Constructs such as Source.queue or
MergeHub.source help hookup a single materialization to multiple client
flows, but leave open one issue: response correlation.
I'm faced with the following problem: How do I correlate individual
requests to individual responses?
The most elegant solution I've come up with so far was placing the service
flow between MergeHub.source and BroadcastHub.sink, and materializing that
into a Flow.fromSinkAndSource. The service flow is augmented with
correlation ids, and each client flow then filters for its matching
response. This seems inefficient to me, as every client flow's filtering
stage will be processed per each response. Is this a legitimate concern, or
am I overestimating its significance?
A more efficient solution involves promises that upon completion resume
client flow. However, this introduces considerably more boilerplate and
runtime bookkeeping.
It seems like there should be an easier way. Any ideas on a streams-only
approach to model concurrent clients accessing resource-bounded services?
--
>>>>>>>>>> Read the docs: http://akka.io/docs/
>>>>>>>>>> Check the FAQ:
>>>>>>>>>> http://doc.akka.io/docs/akka/current/additional/faq.html
>>>>>>>>>> Search the archives: https://groups.google.com/group/akka-user
---
You received this message because you are subscribed to the Google Groups "Akka
User List" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To post to this group, send email to [email protected].
Visit this group at https://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.
