These are chat archives for akkadotnet/akka.net

4th
Mar 2015
jcwrequests
@jcwrequests
Mar 04 2015 00:05
@Horusiath Writing a post would be a good idea. The code looks really interesting and it would cool to see how you came up with your implementation. If I where in the Poland I would buy you a cold beer 🍺 and we could discuss it but a post will do.😊
Aaron Stannard
@Aaronontheweb
Mar 04 2015 00:33
@jcwrequests here's an example of NrOfInstances:
common-router-settings = {
                        router = consistent-hashing-pool
                        nr-of-instances = 10
                        cluster {
                            enabled = on
                            max-nr-of-instances-per-node = 2
                        }
                    }
(from my latest PR)
jcwrequests
@jcwrequests
Mar 04 2015 01:37
Thanks @Aaronontheweb . I am getting a strange symptom with this config. If I don't specify var pool = new ConsistentHashingPool(config);
pool.NrOfInstances = 10;
pool.NrOfInstances = 10 in the code is does not function. Shouldn't just specifying in the config be enough or am I am missing something?
Aaron Stannard
@Aaronontheweb
Mar 04 2015 01:40
hmmm
not sure
I changed all of that stuff in my latest PR
rewrote consistent hashing routers from scratch basically
so I can't remember how the old stuff is supposed to function :p
however, it should work
jcwrequests
@jcwrequests
Mar 04 2015 01:41
Let me rephrase that if I don't add the pool.NrOfInstances = 10 in the code is does not function but it I do it works fine. Seems like something is not correct. Here is what I have
akka.actor.deployment {
        /router1 {
           router = consistent-hashing-pool
                    nr-of-instances = 10
                    cluster {
                        enabled = on
                        max-nr-of-instances-per-node = 2
                    }

            }
Aaron Stannard
@Aaronontheweb
Mar 04 2015 01:41
ahhh, this is with clustered consistent hashing pools?
jcwrequests
@jcwrequests
Mar 04 2015 01:42
Yup
Aaron Stannard
@Aaronontheweb
Mar 04 2015 01:42
haha.... yeah, that was a fun bug to fix: akkadotnet/akka.net#707
I rewrote all of the ActorOf methods in order to make that work
because they didn't properly chain configs
in that PR they will
should have that merged in soon unless someone sees something they don't like
it's big so I'll give it a couple more days
jcwrequests
@jcwrequests
Mar 04 2015 01:43
No problem. Just wanted to be sure I was not going crazy.
Aaron Stannard
@Aaronontheweb
Mar 04 2015 01:43
no, you're not
I experienced the same problem
when I was working with them
jcwrequests
@jcwrequests
Mar 04 2015 01:44
Otherwise they have been really simple to setup and test.
Aaron Stannard
@Aaronontheweb
Mar 04 2015 01:44
glad to hear it!
jcwrequests
@jcwrequests
Mar 04 2015 01:45
They work perfectly with the IOC extensions.
Aaron Stannard
@Aaronontheweb
Mar 04 2015 01:45
that reminds me, btw - did you get a chance to see this issue about IOC? akkadotnet/akka.net#706
err, DI
jcwrequests
@jcwrequests
Mar 04 2015 01:46
Nope. I will take a look.
Aaron Stannard
@Aaronontheweb
Mar 04 2015 01:46
ty sir
jcwrequests
@jcwrequests
Mar 04 2015 01:46
Actually I brought this up in the google group before I started the project.
Because Props controls everything there is no way to implement a proper release strategey.
Aaron Stannard
@Aaronontheweb
Mar 04 2015 01:47
yeah, I seem to recall that
It's a common problem with frameworks. I believe early editions of MVC had the same issue.
Aaron Stannard
@Aaronontheweb
Mar 04 2015 01:50
I think we added IDisposable support for actors since
which @Horusiath mentions in his answer
not ideal because it's explicit
but still, something
really all three of @Horusiath's strategies are good ones
I thought about using the actor construction pipeline for tackling that, so I'm glad he brought it up
jcwrequests
@jcwrequests
Mar 04 2015 01:55
It's probably a problem as well on the JVM side and since Akka.net is based on it that baggage came along with it.
Aaron Stannard
@Aaronontheweb
Mar 04 2015 01:55
yeah
I have no idea how they do DI
jcwrequests
@jcwrequests
Mar 04 2015 01:56
The same way. I based my code on the implementation.
Aaron Stannard
@Aaronontheweb
Mar 04 2015 01:56
nice
well in that case, it's a buyer-beware thing for akka.net
just like akka
and frankly I think that's an ok place to start
as nice as it would be to have automatic scoping for releasing injected resources
might not be feasible atm
jcwrequests
@jcwrequests
Mar 04 2015 01:57
What would be nice if we could pass a lambda to the actor system that could be used by the supervisor to release references. Basically that is all that is really needed.
Aaron Stannard
@Aaronontheweb
Mar 04 2015 01:57
hmmmm
you know
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
jcwrequests
@jcwrequests
Mar 04 2015 01:58
It's just has to take the actor reference and call something like release(Actor).
Aaron Stannard
@Aaronontheweb
Mar 04 2015 01:59
maybe it can get imbedded into Props by the IndirectActorProducer
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
jcwrequests
@jcwrequests
Mar 04 2015 02:01
Makes sense to me.
If you get that to work you can make the JVM guys jealous. :smile:
Aaron Stannard
@Aaronontheweb
Mar 04 2015 02:03
I think that would be neat. You should propose it - I think it'd be a popular idea.
jcwrequests
@jcwrequests
Mar 04 2015 02:04
If you can point in me in the right direction in the code base I will o just that. It was something I wanted to do the first time but I was not familiar enough with all the inner workings.
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
Håkan Canberger
@HCanber
Mar 04 2015 06:20
@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?
Bartosz Sypytkowski
@Horusiath
Mar 04 2015 06:21
I've already presented my opinion in #706. I think we could build a pipeline plugin for DI frameworks and release disposable resources in it's BeforeIncarnated (it's called just before actor itself is disposed and destroyed/respawned).
@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?
Håkan Canberger
@HCanber
Mar 04 2015 06:23
``` C#
Bartosz Sypytkowski
@Horusiath
Mar 04 2015 06:25
I thought you wouldn't try to release CB more than once ;)
Håkan Canberger
@HCanber
Mar 04 2015 06:27
And the switch statement looks like there could be something hidden in there, but I'm not sure if it actually could cause any errors. One thread think the CB is closed, and then before it's executed it becomes open by another thread.
Bartosz Sypytkowski
@Horusiath
Mar 04 2015 06:28
in my use case you initialize CB one for each action, that need it, then you can call if async from multiple threads and release it when all work is done
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
Håkan Canberger
@HCanber
Mar 04 2015 06:35
I was thinking the same thing.
Bartosz Sypytkowski
@Horusiath
Mar 04 2015 19:42
@nvivo how would your async/await support proposition work with dispatchers not operating on TPL at all?
Bartosz Sypytkowski
@Horusiath
Mar 04 2015 21:14
Persistence tests/debug are so fu**ing hard
Stefan Sedich
@stefansedich
Mar 04 2015 21:26
hey guys just looking at the IoC chat
"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.
Stefan Sedich
@stefansedich
Mar 04 2015 22:07
For those interested updated with my findings of the issues with Mono and the fixes required, akkadotnet/akka.net#636 we are now happily running in Mono using these fixes.