These are chat archives for akkadotnet/akka.net

19th
Feb 2016
Vagif Abilov
@object
Feb 19 2016 06:56
Good morning! When using persistent actors (in my case in F#) can the state be an option type? I am getting a null reference exception when trying to update a state with F# None value.
actor <! UpdateState None
[ERROR][19-Feb-16 6:54:17 AM][Thread 0007][akka://system/system/akka.persistence.journal.inmem] Object reference not set to an instance of an object.
Cause: System.NullReferenceException: Object reference not set to an instance of an object.
at Akka.Persistence.Journal.WriteJournalBase.AdaptToJournal(IPersistentRepresentation representation)
at Akka.Persistence.Journal.WriteJournalBase.<CreatePersistentBatch>b__4_1(IPersistentEnvelope e)
at System.Linq.Enumerable.WhereSelectArrayIterator2.MoveNext() at System.Linq.Buffer1..ctor(IEnumerable1 source) at System.Linq.Enumerable.ToArray[TSource](IEnumerable1 source)
at Akka.Persistence.Journal.AsyncWriteJournal.HandleWriteMessages(WriteMessages message)
at Akka.Persistence.Journal.AsyncWriteJournal.Receive(Object message)
at Akka.Actor.ActorBase.AroundReceive(Receive receive, Object message)
at Akka.Persistence.Journal.AsyncWriteProxy.AroundReceive(Receive receive, Object message)
at Akka.Actor.ActorCell.ReceiveMessage(Object message)
at Akka.Actor.ActorCell.Invoke(Envelope envelope)
Should I create a GitHub issue for this?
Bartosz Sypytkowski
@Horusiath
Feb 19 2016 07:03
@object AFAIK null is not a valid message, and F# None may be optimized to null in some cases.
Vagif Abilov
@object
Feb 19 2016 07:14
Yes, I can see that None is optimized to null, and this causes exception. Bottom line: an event can't be an option type.
But that leads to a design question: what if I want to unassign/erase a state from an entity actor?
In my case whole state is just a string value that in some cases can be reset to empty or None in F#. Option type made perfect sense, now it looks like I'll need to replace it with ugly String.Empty.
Perhaps a better approach is to avoid using "naked" data such as strings and wrap them into something more descriptive (and safer for messages).
Vagif Abilov
@object
Feb 19 2016 07:19
Yes I believe using just strings (or string option) as state is a design smell in this case.
Another observation: I noticed that updating a state of a persistent doesn't affect anything until I query its state. I have the following commands:
| Update e -> mailbox.PersistEvent (update state) [e]
| Query -> mailbox.Sender() <! state.LastEvent
| TakeSnapshot -> mailbox.SaveSnapshot state
If I send a persistent actor Update message and then TakeSnapshot I don't see any snapshots created in a "snapshots" folder. I don't even see that Update has been executed (when using debugger). But once I send Query message to an actor, Update is executed and TakeSnapshot generates snapshot files.
Vagif Abilov
@object
Feb 19 2016 08:15
Hello again, noobie question: if I use persistence with built-in file-based persistence store, will it survive the Akka system restart or all snapshots are gone on system shutdown? It looks so, just want to confirm it.
Arjen Smits
@Danthar
Feb 19 2016 08:17
file-based persistance saves your snapshots in files on disk. So yes it will survive actorsystem restart :)
Vagif Abilov
@object
Feb 19 2016 08:32
Hmm, then I need to re-test. Thank you for clarification.
Vagif Abilov
@object
Feb 19 2016 08:59
What I see is that SnapshotOffer event is never received in my apply function. I wonder if I need to trigger it somehow after the system restarts. From what I've read the actor should start recovery process without any extra push.
Vagif Abilov
@object
Feb 19 2016 09:45
Found the problem with SnapshotOffer. The apply function signature didn't like strongly typed event. I used to have it this way:
let apply (mailbox: Eventsourced<Command,string,string list>) state (event:obj)
Then it was never called. Once I changed it to (mailbox: Eventsourced<Command,obj,string list>) state (event:obj), it worked fine.
sgulci
@sgulci
Feb 19 2016 12:29
hi all, is there any sample app that does crud operation with microservice cluster app? besides crawler sample
alexgoeman
@alexgoeman
Feb 19 2016 14:40
Persistence: "To avoid killing persistent actors on recovery failure, a PersistentActor must handle RecoveryFailure messages". When I handle the message RecoveryFailure, indeed my supervision strategy is not called, but messages sent to actor seem not te be getting processed ? Do I need to call some function to switch the actor in some receiving state ?
alexgoeman
@alexgoeman
Feb 19 2016 15:24
Persistence: found following piece of code with interesting remark: else if (message is ReplayMessagesFailure)
{
var failure = (ReplayMessagesFailure)message;
OnReplayFailure(failure.Cause, message: null);
// FIXME what happens if RecoveryFailure is handled, i.e. actor is not stopped?
base.AroundReceive(recoveryBehavior, new RecoveryFailure(failure.Cause));
}
probably missing something like this: ChangeState(ProcessingCommands());
nrgonzalez777
@nrgonzalez777
Feb 19 2016 16:12

Hello! If anyone has a moment, I have a question about configuring cluster seed nodes. I have a very simple test instance of two nodes (both which are seed nodes), one which is hosted on port 8081 and one on 8082. Each has the following seed node HOCON config:

seed-nodes = ["akka.tcp://ClusterSystem@localhost:8081", "akka.tcp://ClusterSystem@localhost:8082"]

However, I've noticed some strange behavior. If I start up the console app using 8081 first, everything works fine. 8081 starts up, tries to connect to 8082 and fails, then goes on to create a cluster which 8082 then joins. Unfortunately this same behavior doesn't occur if I start up 8082 first. 8082 will sit there and try to connect to 8081 forever, without ever coming to the conclusion that it is also a seed node and it can start up its own cluster. Can anyone shed some light on this? Is there something I'm not understanding about cluster config?

Arjen Smits
@Danthar
Feb 19 2016 16:12
@alexgoeman Good find. Can you create an issue for this on the repo so we can track this ?
alexgoeman
@alexgoeman
Feb 19 2016 16:21
@Danthar : sure, but can you give me a pointer to where I can create issues ?
Bartosz Sypytkowski
@Horusiath
Feb 19 2016 16:55
@alexgoeman @Danthar I'm not sure, but this case may be covered by #1717
@sgulci not sure what you mean by CRUD app? Maybe someone have different opinion, but for me CRUD is essentially stateless design, while actors are statefull
Bartosz Sypytkowski
@Horusiath
Feb 19 2016 17:00
@Aaronontheweb do you ever encountered @nrgonzalez777 problem? Maybe you could help.
Aaron Stannard
@Aaronontheweb
Feb 19 2016 17:46
@Horusiath which problem is that?
oh
nevermind, I see it
@nrgonzalez777 do you have auto-down turned on?
if so, turn that off
but this sounds like a possible bug to me
where the order of the seed nodes matters when it should not
could you please file a bug?
nrgonzalez777
@nrgonzalez777
Feb 19 2016 17:50
@Aaronontheweb actually yes, I do have auto-down-unreachable-after set to something, because I do want the nodes to be registered as down after a certain period of time. I'm new to clustering, so I could definitely not be understanding some consequence of setting that flag.
How does that flag affect the cluster startup sequence?
Aaron Stannard
@Aaronontheweb
Feb 19 2016 18:17
eh, you're right
it probably doesn't
a node can't be unreachable if it was never up
good point
Aaron Stannard
@Aaronontheweb
Feb 19 2016 18:24
@/all We've paused the Akka.NET CI service temporarily - we're migrating our data across Azure accounts right now and will resume builds once that's finished.
just an FYI
well, technically it's Azure support migrating the data
but you know what I mean
nrgonzalez777
@nrgonzalez777
Feb 19 2016 19:08
@Aaronontheweb ok I will file an issue with a test application on Github. Thank you for your time.
Aaron Stannard
@Aaronontheweb
Feb 19 2016 19:11
welp, Windows Azure support has changed a lot since I used it last
job's already done
and without any issues
turned the build queue back on
yep, just saw a build agent get launched by TeamCity
we're set
man - silly me for thinking that would take like 24 hours
they've really gotten their act together
Aaron Stannard
@Aaronontheweb
Feb 19 2016 19:22
@nrgonzalez777 thanks for doing that
nrgonzalez777
@nrgonzalez777
Feb 19 2016 19:24
No problem, the issue is here along with a test application to showcase the issue: akkadotnet/akka.net#1719.
Also just want to say I'm very impressed with this framework so far. I've quite enjoyed using it.
Kamil Wojciechowski
@aph5nt
Feb 19 2016 21:41
how to create a child actor with F# api ?
Kamil Wojciechowski
@aph5nt
Feb 19 2016 21:47
? spawn mailbox.Context "child" (fun m -> ()) ?
Bartosz Sypytkowski
@Horusiath
Feb 19 2016 21:49
@aph5nt spawn on mailbox itself should be enough
Kamil Wojciechowski
@aph5nt
Feb 19 2016 21:49
@Horusiath let run system (server : IActorRef) =
spawn system "client"
(fun mailbox ->
            let gameProxy = GameEngine.Games.GameProxyActor.run mailbox.Context
ok, thx
ibrahim dursun
@idursun
Feb 19 2016 21:55
@Horusiath @Aaronontheweb I have tried every possible scenario to find out what I am doing with this setup: https://github.com/idursun/akka.cluster.test Any ideas? I am going to try the same set up with JVM akka tomorrow.
Aaron Stannard
@Aaronontheweb
Feb 19 2016 21:57
@idursun known bug with clustered routers
akkadotnet/akka.net#1700
that might be the wrong issue #
akkadotnet/akka.net#1189
ibrahim dursun
@idursun
Feb 19 2016 22:03
@Aaronontheweb thanks for the information. It is kinda relieving to know that it is a bug. Luckily, it's easily reproducible. I was not sure if I was doing configuration wrong.
Aaron Stannard
@Aaronontheweb
Feb 19 2016 22:04
yeah, sorry for making you question your sanity for a moment there :p
it's a bug with group routers I think
I've been able to reproduce it inside of WebCrawler
ibrahim dursun
@idursun
Feb 19 2016 22:05
Yes, I have seen it in the comments just now. I have searched for issues but probably missed this one. I would like to take a look at this bug over the weekend.
You guys are doing a great job.
Aaron Stannard
@Aaronontheweb
Feb 19 2016 22:26
thanks @idursun
voltcode
@voltcode
Feb 19 2016 22:38
@Aaronontheweb I've updated #1670 with a note, can you confirm if not handling Ungate message at all is deliberate ?
Aaron Stannard
@Aaronontheweb
Feb 19 2016 22:49
@voltcode just saw your email with the comment on it!
that's a nice catch - that's probably the bug
I'll have to take a closer look at the source
but that sounds exactly like what is causing the problem
voltcode
@voltcode
Feb 19 2016 22:51
I looked at the scala code and it seems as they have the same hanlder in the same place as .net code
I mean I wanted to see if they have different logic for handling ungate but didn't find any extra bit
Aaron Stannard
@Aaronontheweb
Feb 19 2016 22:53
I might have an idea
of what the issue might be
voltcode
@voltcode
Feb 19 2016 22:55
the first time Ungate is sent during reconnect is actually somewhere else, I'll update github issue with that info
Aaron Stannard
@Aaronontheweb
Feb 19 2016 22:58
so really, really important question for you
logs confirm that it's never handled - I wonder if ignoring ungate is the desired option.
this literally means "ReliableDeliverySupervisor.Ungate was logged as an unhandled message" right?
and could you copy and paste that log message onto the issue?
because if that log message does not appear
voltcode
@voltcode
Feb 19 2016 22:59
one moment
Aaron Stannard
@Aaronontheweb
Feb 19 2016 22:59
it means something else
oh boom
just saw your log message
bad ass
yep, we've found it
well, you've found it
going to wrap up an email real fast and then look through the source
see if we can nip this bug in the bud
voltcode
@voltcode
Feb 19 2016 23:03
I'd love to make a code contribution but fixing this seems a bit too hard for a first timer ;)
Aaron Stannard
@Aaronontheweb
Feb 19 2016 23:03
this is a nasty one haha
so the reason why the Ungate message wouldn't be handled
would be because the RDS is not in a Gated behavior
at the time
Aaron Stannard
@Aaronontheweb
Feb 19 2016 23:12
@voltcode for the rest of the logs
what happens after the unhandled ungate message
connection attempt still gets reported as gated?
voltcode
@voltcode
Feb 19 2016 23:15
I pasted more lines into the issue, let me know if this is sufficient?
further logs just repeat this sequence - unhandled, death (?), restart, etc.
Aaron Stannard
@Aaronontheweb
Feb 19 2016 23:16
yep, this is good
the EndpointWriter should be terminating
but I don't see it die
in the logs you pasted
voltcode
@voltcode
Feb 19 2016 23:17
I can paste logs from the other side, might they be helpful ?
Aaron Stannard
@Aaronontheweb
Feb 19 2016 23:17
that would be great
voltcode
@voltcode
Feb 19 2016 23:17
ok one moment
added another exceprt and also attached full logs
voltcode
@voltcode
Feb 19 2016 23:23
the "console" log is only from reconnection attempt( ie from restarting the nonseed node), it doesnt cover initial join of the nonseed - it all goes fine when first joining.
the "service " log is full , as I never restart that service in bug scenario
I simplified the bug reproduction app a bit - replaced webapp wth a console app for ease of reproduction (no other changes), I'll upload it tomorrow if necessary
if you have any hints, tips, things I could try to help solve this issue let me know, I'm determing to kill this bug! albeit missing some akka internals secret skillz to be effective :)