@aachinfiev not in the near feature, we need to wait for all dependencies to support .Net core and then we could work on it
@qwoz yes the ActorRef is still valid, for this case you doesn't need to implement death watch, you need it when you want to see when an actor stops
@aachinfiev yes, I've run it on docker using mono:onbuild container. Exact same code+project as .net4.5.2, trivial
Only don't use
Console.ReadLine :smile:
Hello I would like to know whether the Akka Stream has been fully released yet.
If @Aaronontheweb managed to get everything in place, it should be released today
Hello how can I use mutable messages in Akka? I know by nature it handles well immutable message. However there are times you will need to change the value of a property based upon certain conditions for instance if you are adapting the filter pipe pattern.
@Silv3rcircl3 actually we should not wait for all dependencies, it could take forever. Theoretically we could convert Akka/Persistence/Stream to NetCore right now. But NetCLI is not so stable, as it should be. It would be better to wait when it be stable. But right now we could start adapting code to NetStandard (GetType vs GetType().GetTypeInfo, etc)
@Tochemey you can track 1.1 release here https://github.com/akkadotnet/akka.net/milestones/1.1.0
@Tochemey
or instance if you are adapting the filter pipe pattern.
you still can do this using immutable messages
@alexvaluyskiy sure, if someone wants to port it we wouldn't stop him, but at least for the core team we agreed on the last meeting that this hasn't a high priority for us
@Silv3rcircl3 I can figure out what you suggested
@Horusiath can you please elaborate on this about using the filter pipe pattern and message immutability?
@Tochemey could you explain the case where you need mutability?
@Horusiath I am sending a message to an Actor. The message is an object
public class Message{
public string From{get;}
public string bool Billed{set;get;}
........................
}I have implemented some actors that I have chained together to process the message when the actor receives it. The property Billed will need some change during the handling of the message by one of those child actors. At the end of the day I will have the message with Billed property set to its final processed value.
so can't you send a new message with billed value updated?
Here goes a noob question... I'm trying to figure out why my cluster nodes can't connect to my seed node. In the log of the cluster nodes, I get the following message:
Both seed node and cluster nodes are on the same machine (latitudee7450)
[ERROR][2016-06-30 09:09:00][Thread 0018][akka://mysystem/system/endpointManager/reliableEndpointWriter-akka.tcp%3a%2f%2fmysystem%40latitudee7450%3a4053-1] Invalid address: akka.tcp://mysystem@latitudee7450:4053Both seed node and cluster nodes are on the same machine (latitudee7450)
In the log of my seed node, I can see that remoting has started and listen to
akka.tcp://mysystem@latitudee7450:4053
Interesting
https://github.com/AdaptiveConsulting/Aeron.NET
Akka JVM plans to use it in Akka Remoting 3.0
Could it be that I am using the hostname and not IP as seed node address? I'm pretty sure that this worked earlier, but I have switched over to the nightly build. Has something changed in regards to this? I just tried with the IP and that works
Anyone have issues with Wire 1.0.8.25-beta and Akka.net 1.0.8? I'm getting a system.reflection.targetinvocationexception error when creating an actor system using the Wire configuration sample from the docs.
oops sorry Akka.Serialization.Wire 1.0.8.25-beta Wire 0.0.6
Ok...strange...drilling down it's because it can't load the Newtonsoft JSON.net assemblies...which I removed because I'm using Wire...and my HOCON text is specifically referencing Akka.Serialization.Wire....
I've found that the error about not loading the JSON.net assemblies when I've configured Wire typically means that the my HOCON file doesn't parse for some reason and so it's using the default config
I'm spent a bunch of time tracking down parsing issues in my HOCON file, I kinda wish there was a way to tell Akka to throw a parsing exception rather than just using the default config =/
New console app...add Akka.net create actor system...get warning about Json.net being phased out...Install wire and akka.serialization.wire make HOCON config and uninstall json.net....boom. Reinstall json.net (keeping wire HOCON config intact)...no boom AND no json.net deprecation warning.
although, I also haven't removed the JSON.net assemblies from everything as I'm using it for my own config files
I mean...yeah...I probably don't want to remove it...but I guess wire is just for Binary and Akka.net still uses Json.net for non-binary?
you have to set the serializer for “System.Object” to wire. By default “System.Object” is set to Json.net
When I write out my actorsystemsettings it's configured for Wire...but looks like there is still a json.net requirement for other internals
So anyway...that's a thing I learned today. :)
@aachinfiev I believe @annymsMthd has done some real work with Docker, Mono, and Akka.NET clusters
he'd be the one to ask
@Tochemey have a tiny bit more work to do on fixing a few more bugs with Clustering itself, but we're close. I'm working on one other thing (extracting Akka.Cluster.Metrics out of Akka.Cluster)
might have it all done today; more likely to be tomorrow or Monday / Tuesday
and I think I have to clean up some logging stuff around Akka.Remote
@aachinfiev I'm using akka.net with mono in docker containers atm
@alexvaluyskiy were you able to get that Scala code translation issue sorted?
I'm not sure, just review my PR and make your decision
meant to do it yesterday
but my flight home got delayed by like 3 hours
@alexvaluyskiy I'm working on extracting Cluster.Metrics now
do you need any help debugging those other MNTR specs?
those changes were subtle but I definitely think they'll have an impact on failure detection
so I wouldn't be surprised if you saw a change in behavior on the network instability spec in particular
SurviveNetworkInstability still doesn't work. I've checked it this morning
@alexvaluyskiy have we already done akkadotnet/akka.net#1577 ?
not sure if it really belongs on this milestone or not
we can probably drop some of those issues, like releasing the Cluster.Metrics nuget package - can do that in a later release
planning on doing some compatibility testing tomorrow
going to use the nightlies from today or tomorrow and install them into WebCrawler without modifying any of its code or configuration
see how it performs
"end-user" upgrade testing :p
wow new version is just around the corner! good job, guys! :thumbsup:
yep, almost there
getting the remainder of the multi-node test suite to pass
so far I've found a few bugs, but ironically it's bugs in the code inside Akka.Cluster we use for testing it
the actual stuff being tested is working fine
lol
@Aaronontheweb just wanted to say thanks to you and everyone on the team who contributes to akka.net. In addition to all its benefits, about the biggest praise I can give is that it's made programming enjoyable again for me.
we have a really solid group of core contributors who work really hard - it's a team effort
I'm blown away by what the Akka.Streams and Persistence guys did on this release
and of course there's always the bug reports and issues we get from end-users
wouldn't be much of a project without them to tell us what they need and to ask questions
lol
that's for sure
the thing I'm most excited to play with once 1.1 is out is Akka.Streams - I think that's going to end up being a killer feature.
also worth checking out is the Reactive.Streams specification the Akka.Streams team implemented: https://github.com/reactive-streams/reactive-streams-dotnet
we'll be evangelizing that to see if we can get some other .NET libraries to adopt it - it's already becoming a standard on the JVM
and in Node.JS
I could see technologies like NServiceBus adopting that
and more - who knows
Haha.. I had been creating a .Net port of that off and on since January.
Now I don’t have to :)