nikore on master
updating readme for the newst r… (compare)
nikore on v0.4.2
scottcarey on master
Adding in the ability to specif… Merge pull request #37 from nik… (compare)
wye, since they have to deal with the fact that data is getting shuffled around
[error] Could not run test scalaz.netty.NettySpecs: java.lang.NoSuchMethodError: scalaz.stream.Process$.Process0Syntax(Lscalaz/stream/Process;)Lscalaz/stream/Process$Process0Syntax;
async.boundedQueue. This queue serves as a gateway to scalaz-stream turning the push based api to a pull based one. The result of this is that the processing speed depends on how fast my stream can consume this queue, which will run on the implicit execution context threads. Is this correct?
@djspiewak Another thing related to this. I see that the backpressure is implemented here: https://github.com/RichRelevance/scalaz-netty/blob/master/src/main/scala/scalaz/netty/Client.scala#L82
Should we have many clients, this will block the netty-worker thread as soon as a client's queue is full and by doing that it will also block the other clients. Should not the back-pressure be separated for the different clients?
Nondeterminisb.bothit works. See here. Another thing is that using the same worker thread for the client and the server is probably not a good idea in such use cases as their back pressure will clash. Give me some time and I will figure this out. :-)