Re: [akka-user] Akka Stream - Framing silently swallows exceptions?

I apologise if my last line came out sarcastic. It absolutely wasn't meant to be - my respect for Lightbend's work is second to no-one else's. Concerning the issue, I had messed things up and therefore my confused message. The link doesn't work as I had deleted the post on Stackoverflow, and

Re: [akka-user] Re: Akka Http memory leak suspect

If the names are StreamSupervisor- I think it can be that a new Materializer is created for each request. I don’t know if that is done by your application or by Akka Http. Does that ring any bells? Do you have any creation of stream materializers in your code? /Patrik mån 25 sep. 2017 kl. 21:51

Re: [akka-user] Akka Stream - Framing silently swallows exceptions?

On 26 September 2017 at 10:47:44, Fabio Tiriticco (fabio.eur...@gmail.com) wrote: Hi all, I noticed that the Framing flow of Akka Streams tends to stop the stream without letting the outer world know. In essence, the stream just stops and supervision is not triggered. It propagates errors

[akka-user] Akka streams question

I have a Kafka topic where messages have an account field, as well as a payload of decimal values. I would like to save the decimal values to an s3 file for each account. I would like to preserve at least once message semantics and only commit the offset once I'm sure the contents of the file

[akka-user] Akka Stream - Framing silently swallows exceptions?

Hi all, I noticed that the Framing flow of Akka Streams tends to stop the stream without letting the outer world know. In essence, the stream just stops and supervision is not triggered. The details of my findings are here:

Re: [akka-user] [akka-cluster-sharding] Create shard entity actors based checking some condition.

Thank you понеділок, 25 вересня 2017 р. 21:36:08 UTC+3 користувач Justin du coeur написав: > > Sure, but I think you're thinking about it incorrectly. Don't worry about > creating the Sharding entity itself, which has no lasting effect -- > instead, focus on not *persisting* anything unless

[akka-user] Re: Akka Http memory leak suspect

Hi Johannes, I can share the heap dump. I will try uploading it to Google Drive. I'm still suspecting Akka Http. A few days ago I was forced to migrate to HTTP4S in emergency. After the migration of endpoints (no single other change applied) the heap dump utilisation is stable. Bartosz On

Re: [akka-user] [akka-cluster-sharding] Create shard entity actors based checking some condition.

Sure, but I think you're thinking about it incorrectly. Don't worry about creating the Sharding entity itself, which has no lasting effect -- instead, focus on not *persisting* anything unless the wallet is already valid. The preStart idea isn't bad, but probably expensive (assuming the external

[akka-user] Re: Cluster: Loosing messages when rebalancing

Absolutely clear. Many thanks for your reply. I'll check the persistence feature. Best regards. El lunes, 25 de septiembre de 2017, 15:02:40 (UTC+2), johannes...@lightbend.com escribió: > > Hi Eduardo, > > cluster sharding has at-most-once delivery (as most of Akka) so losing > some messages

[akka-user] [akka-cluster-sharding] Create shard entity actors based checking some condition.

Hello I'd like to implement cluster sharding enabled service with following scenario # *Wallet *service manages users' wallets # Each *wallet* is represented as persistent actors / shard entity # Shard clients are sending deposit / withdraw commands to wallets # Wallet creation is a dedicated

[akka-user] Re: Cluster: Loosing messages when rebalancing

Hi Eduardo, cluster sharding has at-most-once delivery (as most of Akka) so losing some messages is to be expected. Persistent actor can opt-in to at-least-once delivery (see http://doc.akka.io/docs/akka/current/scala/persistence.html#at-least-once-delivery), for other actors, you need to

[akka-user] Re: Akka Http memory leak suspect

Hi Bartosz, I can look into the heap dump. You can send it to me privately. If that's not possible could you post an histogram? It would be great if that could be filtered once for subclasses of `Actor` (which will probably be dominated by `ActorGraphInterpreter`) and once filtered by

Re: [akka-user] Akka Http memory leak suspect

Please share a reproducer if you indeed think it’s a leak in here. Investigate *which* cells are, and *what* they contain; very likely it’s not “akka leaks”, but somewhere you’re starting and not stopping things. — Konrad `kto.so` Malawski Akka @ Lightbend

Re: [akka-user] Akka Http memory leak suspect

Precisely - I simplified the solution to eliminate all possible causes. As mentioned, I don't use actors anywhere except for this endpoint and instances of ActorCell pollute the heap. I've tried profiling and the observation is the same. On Mon, 25 Sep 2017 at 12:29 Konrad Malawski

Re: [akka-user] Akka Http memory leak suspect

This code seems unlikely to be the cause, likely somewhere else - run your app while profiling to find the leak. On Mon, Sep 25, 2017 at 7:26 PM, Bartosz Jankiewicz < bartosz.jankiew...@gmail.com> wrote: > Indeed, this is what it looks like :) > > The only place where I use actors is in Akka

Re: [akka-user] Akka Http memory leak suspect

Indeed, this is what it looks like :) The only place where I use actors is in Akka Http routes. The service I'm using returns a future. The only clue I had was that the Future results returned from my service never evaluate could cause the stream workers to stack. But in such case I should

Re: [akka-user] Akka Http memory leak suspect

What are you doing in the app ;-) Sounds to me like you’re starting tons of things that are never stopped. — Konrad `kto.so` Malawski Akka @ Lightbend On 25 September 2017 at 17:38:57, Bartosz Jankiewicz ( bartosz.jankiew...@gmail.com) wrote: I have been

[akka-user] Akka Http memory leak suspect

I have been running an app with Akka Http 1.0.9. It had only single endpoint respoding with JSON. The service returned the value as future therefore I used onComlete semantics. The app was consistently running into OoM issues. Heap dump analysis has led me to 1,536,693 instances of