I'm using the latest release of Akka (2.3.2) and I've been playing around with the Tcp Api a bit, trying to get familiar with how it works. In doing so, I've been writing a little Memcached binary client. This usage of Tcp is a little different then the examples in the docs in that the connection is kept alive and never closed (unless the peer closes the connection in which a reconnect will happen). In my little prototype, I'm using the Ack based back-pressure solution. I also recently switched to pullMode for reads because I found that when I didn't, so many reads were coming when I was hammering it with load that it took forever to receive the write ack thus delaying the next write and slowing throughput down. When I switched to pullMode, things sped up, but now I'm running into a strange issue where I eventually do not receive an Ack for one of the writes that I made which pretty much kills the flow as it's the acks that keep data flowing from my memcached node actor into the connection actor. I enabled trace logging and more often then not, when this happens, I see this is the log as the last log message from the selection handler:
[DEBUG] [04/11/2014 14:11:02.281] [couch-akka.actor.default-dispatcher-22] [akka://couch/system/IO-TCP/selectors/$a/0] Wrote [0] bytes to channel I can post my code if need be, but I just wanted to first see if anyone else has ever seen this behavior. -- >>>>>>>>>> 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.
