Good suggestion. Another alternative is that the AtLeastOnceDelivery actor rejects new incoming messages when there are too many unconfirmed messages. That means that the original producer must deal with acknowledgments and rejections. The AtLeastOnceDelivery actor becomes a safe-handoff point and until it has acknowledged that it will take care of delivery of a message it's the senders responsibility, e.g. return error response to a client.
On Wed, Aug 10, 2016 at 10:46 AM, Eric Yomi <ericy...@gmail.com> wrote: > Hi Tal, > Thanks for your reply. Your suggestion to use a PersistenceQuery actor > seems like a good one. I'll look into that and let you know. > > On Wednesday, August 10, 2016 at 7:57:12 AM UTC+1, Tal Pressman wrote: >> >> Hi, >> >> From what I know, you can't do this using just a single PersistentActor, >> since you have no control of the incoming message rate (even if you just >> persist the messages and don't keep them in memory after that, they could >> arrive faster than the journal can persist them). >> >> If we assume that you can persist the messages quickly enough, then you >> can achieve something similar to what you are looking for using a >> PersistentActor that just persists the messages as they come in and a >> persistence-query stream that reads and sends the messages out. This way >> the stream provides back-pressure, so you won't read messages from the >> persistence layer unless previous messages were acknowledged. >> >> Hope this helps, >> Tal >> >> >> On Tuesday, August 9, 2016 at 4:59:56 PM UTC+3, Eric Yomi wrote: >>> >>> We are using a AtLeastOnceDelivery persistent actor. We are getting a >>> huge volume of unconfirmed messages and this is causing an OutOfMemoryError >>> if this number is too large. >>> >>> >>> Is there a way we can configure the AtLeastOnceDelivery actor to keep >>> the unconfirmed messages on disk rather than keeping them all in memory >>> until they are confirmed? >>> >>> Or better is there an alternative to AtLeastOnceDelivery that gets >>> around this limitation? >>> >>> >>> Also we have played around with the max number of unconfirmed messages >>> setting. Although reducing this value prevents an OutOfMemoryError it does >>> however results in subsequent messages being discarded. >>> >>> We would like to have a solution where the unconfirmed messages are not >>> kept in memory, but constantly flushed out to file without any loss of >>> messages. >>> >>> >>> -- > >>>>>>>>>> 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 akka-user+unsubscr...@googlegroups.com. > To post to this group, send email to akka-user@googlegroups.com. > Visit this group at https://groups.google.com/group/akka-user. > For more options, visit https://groups.google.com/d/optout. > -- Patrik Nordwall Akka Tech Lead Lightbend <http://www.lightbend.com/> - Reactive apps on the JVM Twitter: @patriknw -- >>>>>>>>>> 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 akka-user+unsubscr...@googlegroups.com. To post to this group, send email to akka-user@googlegroups.com. Visit this group at https://groups.google.com/group/akka-user. For more options, visit https://groups.google.com/d/optout.
