expressions being properties of serialized objects won't work with it
ah, that should probably be possible to solve using the surrogate mechanism now. eg. FSExpressionDecider (containing expressions) -> FSExpressionDeciderSurrogate containing expressions pre serialized by fs pickler and stored as a string base64 or whatever in the surrogate., then the other way around, turn the base64 string into expressions and recreate the FSExpressionDecider
@Aaronontheweb @rogeralsing @Horusiath @HCanber @stefansedich The DI patch is working even with the AutoFac. Currently I am putting together some examples using the containers. Currently I have implement examples with HashPool and one with Child Actors for @tomstaijen. I want to add a few more examples and clean things up a bit before putting in a proper PR. @tomstaijen If you are interested or can't wait for the PR you can check out the latest here
/all are we really handling supervision correctly when it comes to restarting children? e.g. lets say we have the structure a -> b -> c where c is stashable. and actor c throws, b supervises but escallate to a.. A decides to restart b, b will now recreate c and thus we loose any stashing as it is no longer the same c.. is this the behavior in jvm akka too?
@Aaronontheweb Do you think I should add more examples or do you think this is enough? Any Advice before I put in my PR. Thanks
Not saying this is wrong, just checking if that is the expected behavior. It could be suprising if you have stashing and the actor throws and you loose all messages because the exception was escalated
F# API, 40 lines to create actor system, define and create parent/child actors and define custom supervisor strategy
@nvivo check out this (example)[https://github.com/jcwrequests/akka.net/blob/dev/src/contrib/dependencyInjection/Examples/BasicAutoFacUses/Actors.cs]. I will be putting in a PR shortly.
do you think, we should do so with our implementation?
and have it use the status API
just changed it on the PR build configuration
it'll still comment on dev and master at the moment
going to see what it actually does :p
hahaha wow... every time we run the full SandCastle build we get about 110mbs worth of artifacts
that's a lot
going to have to dick around with the configuration on TeamCity some more when I get back
I am working on an async socket connection handling code using akka (somehow inspired from akka-io). What's the best way to communicate with the actor from a socket operation callback? For example, I want to inform the actor from socket callback when data was read or when connection broke.
PR is has now been submitted to patch the DI implementation. akkadotnet/akka.net#733. I tried using the new Git For WIndows application for pull request. Seems to work nicely. @Aaronontheweb @rogeralsing @Horusiath @HCanber if I need to make any other changes or you need additional documentation just let me know.
@robertmircea I think your question is too general. Depending on what you want to get done, different solutions applies.
I was trying to port Akka.IO from JVM to .NET - I remember, that I've got serious problems with integrating akka threading model with async sockets (first tried a way similar to cannonical Akka, but Java NIO cannot be reflected directly in .NET) and that @Aaronontheweb already encouraged them when he was creating Helios, but I don't remember specifics
@Horusiath I have this async socket receive code:
//this code is part of the actor
var receiveSaea = new SocketAsyncEventArgs();
receiveSaea.Completed += ReceivedCompleted;
receiveSaea.AcceptSocket = socket;
socket.ReceiveAsync(receiveSaea);
[...]
//later, this callback is called when socket read is completed
private void ReceivedCompleted(object sender, SocketAsyncEventArgs e)
{
var connectionInfo = e.UserToken as ConnectionInfo;
if (connectionInfo == null)
throw new InvalidOperationException("Could not find a reference to ConnectionInfo");
if (e.SocketError != SocketError.Success)
{
log.Error("IO error while receiving data over socket: " + e.SocketError);
//TODO: I need to tell the calling actor to shutdown itself, but I cannot use Context.Stop(connectionInfo.Sender) here
return;
}
Basically I need to have somehow access to Context in order to stop the actor, but inside the callback Context is not available
ConnectionInfo contains an ActionRef to the actor.
I've skipped the instantiation code
There are a few options, 1) .net async api for a taskbased, (if socket does not have that, TPL provides helpers to convert old async events to task), and then use
.PipeTo(Self) on that task.. 2) use a closure that binds a copy of Context in a local var.. 3) download the latest source and use our new TPL support
var context = Context;
var receiveSaea = new SocketAsyncEventArgs();
receiveSaea.Completed += ReceivedCompleted;
receiveSaea.AcceptSocket = socket;
socket.ReceiveAsync((sender,e) => {
var connectionInfo = e.UserToken as ConnectionInfo;
if (connectionInfo == null)
throw new InvalidOperationException("Could not find a reference to ConnectionInfo");
if (e.SocketError != SocketError.Success)
{
log.Error("IO error while receiving data over socket: " + e.SocketError);
Context.Stop(connectionInfo.Sender)
return;
}
});
This message was deleted
This message was deleted