Hi Michał, If there was a sufficiently simple / lightweight RS implementation, you could have used that and still provided a library that everyone could use (akka streams, Rx, etc). I don't think you, and everyone else who wants to publish an RS compatible library, should have to (or would enjoy) implementing the RS interfaces directly. What I'd like to know is what would make such a library useful to people besides myself.
Your code looks very clean and nice. (I only spent a few minutes reading it though.) And it doesn't need to implement all possible RS behavior. So maybe you didn't need, or feel the need, for such a library. Even a Publisher as simple as 'call method X to produce each successive element' isn't trivial to implement manually using RS, because you have to manage subscriptions and back-pressure. To be honest I was surprised that you, or anyone, would choose to implement RS directly. I'm pretty sure the RS specification authors didn't intend for that to happen :-) Daniel Armak On Wed, Oct 29, 2014 at 3:02 PM, Michał Kiędyś <[email protected]> wrote: > Hi Daniel, > > I made my anwser below. Your opinion is valuable for me and I would like > you get code review from you. > > Best Regards, > MK > > 2014-10-29 10:18 GMT+01:00 Daniel Armak: > >> Hi Michal, >> >> I'm interested in why you rolled your own RS implementation: was it >> because you didn't want a dependency on akka, or because akka-streams isn't >> stable enough yet, or for some other reason? >> > > > It's actually very good question. Simple anwser is: by just providing > implementation of *Publisher*/*Subscriber* everyone can use it: Akka > Streams, RxJava, vert.x, Reactor, ratpack, etc. > > Longer anwser: > > 1) Exposing AMQP interface requires just *Publisher* & *Subscriber* (and > maybe *Processor* if you want to issue acknowledgements manually) > > I don't need to provide or use any of Akka Streams/other features like > Source/Sink, combinators, AST flatteners etc > > 2) RabbitMQ Java library uses it own thread pool that keeps track of > connection/channel state and is capable of running client callbacks in order > > Adding Akka on top of that means: > a) more resources used (additional ForkJoin pool to RabbitMQ thread pool) > b) more message passing without added value (I discuss potential value > later), > c) more complex configuration. > > Most of the hard stuff is already implemented in Java RabbitMQ client. > > 3) Using Akka Streams would still require me to do almost same amount of > work > > AMQP flow control can be made using these protocol features: > a) basicGet > b) channel QOS > c) flow blocking (consumer asks broker to stop sending messages or > broker asks publisher to stop producing) > d) recover (consumer asks broker to redeliver unacknowledged messages > with or without requeing) > > I still have to play with them by myself. > > >> >> If there was a different library, smaller/more lightweight than akka >> actors, that provided a generic implementation of RS, would you have used >> it? What would you want from such a library? >> > > Using Akka Actor would be beneficial for few reasons: > a) state - for buffering (now: ScalaSTM), > b) synchronization - increaseing and decreasing demand (now: ScalaSTM), > c) distribution - offloading *onNext(t: T)* calls inside *request(n: > Long)* to avoid unbounded recursion (now: Scala Global *ExecutionContext* but > I'm considering switching to RabbitMQ thread pool) > > >> >> Thanks, >> >> -- >> Daniel Armak >> > > -- >>>>>>>>>> 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 http://groups.google.com/group/akka-user. For more options, visit https://groups.google.com/d/optout.
