THAT might be doable
depends on what the lambda has to do
if you could put together a little proposal for doing that, @HCanber / @Horusiath / @rogeralsing might have some ideas on how that can be done
and the ActorCell can call it on the actor itself during the restart / shutdown
since the ActorCell sits outside of the
ActorRef
and the actor instance
so it can still be a self-contained concern
done as part of the
Terminate step
If you get that to work you can make the JVM guys jealous. :smile:
Maybe I could use NDepend to help me out with that. It's been something on my back burner for a while and the guy who owns company gave me a free copy and I been meaning to do a blog post on it to repay him for his generosity. I have to sign off but I will start taking a look again and see what can be done. Cheers
@Horusiath Sorry, missed your question. Yes I got started on the CircuitBreaker, as I needed one at work. More important things got in between though, so I haven't finished it. :( I've based mine on Akka's and supports a bit more than yours does (callbacks for example), and I've created a base class so one can add more states (for example the CB is in a BeingInitialized before it's closed for the first time)
Looking at your code, it seems to me that you have a few race conditions. Is your CB intended to be used from inside one actor instance only?
@HCanber it's not an Akka specific, I need it for more general purpose works with projects not using Akka. Where do you see possible race conditions?
any proposed solution? without lock or double check it will be hard to achieve
acutally I don't think that executing closed behavior once/twice while CB is switching to open state it's a bad thing, if something caused CB to open, probably there are already many concurrent requests which already are waiting for their timeout or will fail anyway
one/few more calls which will pass the state check while state itself is changing, shouldn't make a difference
"It's just has to take the actor reference and call something like release(Actor)."
in autofac for example you would not do it that way but instead reslove a lifetime scope or an owned instance and then dispose of that after, there is no release method on the actual container.
@stefansedich The release thing is based on the following post http://blog.ploeh.dk/2014/05/19/di-friendly-framework/ which I think does an excellent job explaining the need plus its an interesting read.
they don't have release in that way instead the request gets wrapped in a lifetime scope which itself is disposed.
Although if using autofac we could resolve an Owned<T> and in the release dispose that
would probably be enough
where T being the actor type
so yeah sorry release is probably enough :)
let actorOfCtor (state : 'a) (fn : 'a -> 'Message -> unit) (mailbox : Actor<'Message>) : Cont<'Message, 'Returned> =
let rec loop() =
actor {
let! msg = mailbox.Receive()
fn state msg
return! loop()
}
loop()
allows the creation of an actor that will have some sort of initial data that is usable by the messageHandler every message
@raymens if you must use some state in F# API, pass it as a rec loop parameter , eg:
type MyState = { X: int; Y: int }
let aref = spawn system "my-actor" <| fun mailbox ->
let rec loop state = actor {
let! msg = mailbox.Receive()
return! loop ({ state with Y = msg })
}
loop ({X = 1; Y = 2})