hi how to monitor the actor.remote? I had two remote system in my local machine with port 8080 and 8081
but I can catch the message by wireshark
can't
Basically wireshark cannot capture traffic on the local loopback interface by default.
which is what happens when you run 2 actor systems on the same machine
if you run 1 actorsystem on a different system, it should work.
When you create a supervision strategy can you access the IActorRef of the offending actor?
@frasermolyneux not by default. But you can implement your own.
supervision strategy
check out the OneForOneStrategy https://github.com/akkadotnet/akka.net/blob/master/src/core/Akka/Actor/SupervisorStrategy.cs#L200
You are looking for the Handle method: https://github.com/akkadotnet/akka.net/blob/master/src/core/Akka/Actor/SupervisorStrategy.cs#L324
I'm trying to find out the cause for an association error that is caused by outofmemory exception
```
```
2016-06-09 14:56:54,250 WARN [1003] Fabric : Tried to associate with unreachable remote address [akka.tcp://...@localhost:8001]. Address is now gated for 5000 ms, all messages to this address will be delivered to dead letters. Reason: [Invalid address: akka.tcp://...@localhost:8001] Caused by: [Akka.Remote.Transport.InvalidAssociationException: Association failure ---> System.OutOfMemoryException: Exception of type 'System.OutOfMemoryException' was thrown.
at System.Threading.Thread.StartInternal(IPrincipal principal, StackCrawlMark& stackMark)
at System.Threading.Thread.Start(StackCrawlMark& stackMark)
at System.Threading.Thread.Start()
at Helios.Concurrency.DedicatedThreadPool.PoolWorker..ctor(WorkerQueue work, DedicatedThreadPool pool, Boolean errorRecovery)
at Helios.Concurrency.DedicatedThreadPool..ctor(DedicatedThreadPoolSettings settings)
at Helios.Concurrency.Impl.DedicatedThreadPoolFiber..ctor(IExecutor executor, Int32 numThreads)
at Helios.Net.Bootstrap.ClientBootstrap.get_EventLoop()
at Helios.Net.Bootstrap.TcpConnectionFactory.CreateConnection(INode localEndpoint, INode remoteEndpoint)
at Helios.Net.Bootstrap.ClientConnectionFactoryBase.NewConnection(INode localEndpoint, INode remoteEndpoint)
at Akka.Remote.Transport.Helios.HeliosTransport.NewClient(Address remoteAddress)
at Akka.Remote.Transport.Helios.HeliosTcpTransport.AssociateInternal(Address remoteAddress)
at Akka.Remote.Transport.Helios.HeliosTransport.<Associate>d__27.MoveNext()
I've dotted out actor system names
It's hardly likely that the really is not sufficient RAM on the server when this exception is reported
The machine always reports enough RAM. Association error is correct (the other endpoint is dead) but I don't know why it reports it with OutOfMemory
other times the same InvalidAssociation is reported with HeliosConnectionException -which is expected
Is this something to worry about at all ? Is there a chance some behaviour in Helios can cause memory leak when unable to associate multiple times?
@voltcode I'm not an expert, but it looks more like you cannot connect to remote node, and that OOM raises as result of messages being stacked while waiting for connection to be established
hmm I do send a ping kind of message every minute to that node, maybe I need to control that a bit more
I'm sending that with Ask, maybe that is aggravating the problem
hi Do I need Json.Net with +6.0.0.0 version? I use the Json.Net with 8.0.0.0. It throw exception.
@hidavidpeng I think we use 7x, have you added a redirect into your app.config?
we use 8.0.3 without problems but indeed, the redirect must be there
it means can add assembly 6.0.0.0
can't add assembly 6.0.0.0
I configed with that.
@voltcode so we fixed a bug yesterday in the logging system that caused it to essentially never release any logged messages
a memory leak
you can read the details here akkadotnet/akka.net#1734
that fix will be publicly released in 1.4.1
err
1.1
in the meantime if this is a production issue you can try switching to the nightly builds of Akka.NET
but fair warning - the nightlies are a bit of a moving target right now; still bringing in some changes for 1.1 (which we're running a bit behind on)
if you're in this room, you're probably the sort of .NET developer who would find this interesting: https://qconnewyork.com/system/files/presentation-slides/csysprog-qcon-june2016.pdf
Joe Duffy's talk from QCon NYC this week
I'm just looking through it now
ah snap, looks like there was an issue with these two PRs that broke the compiler
I'll go fix that
BTW, "safe system programming in C#" reminds me of Singularity project that I expected to be released awhile.
I've been using classes for all my messages... based on this, immutable structs are the way to go.
bear in mind - this is the future of how the C# compiler will work
not necessarily how the current one works
but yeah... that's actually a very interesting idea
performance using structs
as long as the memory footprint is small
small meaning "not hundreds of KB"
It logically represents a single value, similar to primitive types (integer, double, and so on).
It has an instance size smaller than 16 bytes.
It is immutable.
It will not have to be boxed frequently.
It has an instance size smaller than 16 bytes.
It is immutable.
It will not have to be boxed frequently.
ouch
what's the size of a pointer in C#? I can't remember off hand
from SO, "The reference itself is basically a pointer. 32 bits on a 32 bit OS, 64 bits on a 64 bit OS."
pointer size == number of bits in a register
been about 10 years since I've taken my computer organization class in college :p
@veblush 1-2 weeks I think
most of the major changes are staged already - either merged into the
dev branch or sitting in PRs
we were able to reproduce a bunch of elusive bugs inside the
EndpointManager reliably, finally
so we're fixing those but it's slow going
and there's a big router PR that just landed - still a work in progress
I'm pretty confident people will be thrilled with the results
the whole thing runs a lot faster with less memory utilization across the board
and is already much more reliable - it'll be even better with the rest of these fixes
and 1.5 will be even better
which is scheduled to land 6-8 weeks after 1.1
and 1.1 will be done when it's done? or do you have a rough date in mind?
1.5 has a different version number because of the serializer change
nice!
people can start using Wire now though
without having to wait for that
and we'll also be introducing TLS support then too, and the much faster
NetworkStreamTransport
@qwoz if we keep up the pace we've been on
BTW. I'm conflused with helios 2.0 itself. was dotnetty the fulture of helios 1.x ?
with some modifications I made for backwards compatibility
in order to stabilize Cluster I had to fix some of the issues with Helios 1.4
but yeah, the code from DotNetty is inside Helios 2.0
:)
I have more stuff I need to contribute back to DotNetty I wrote for Helios 2
benchmarks and some model based tests
but I've been pressed for time
lots of smart people working on it
one poor guy had to go through hell to get TLS to work on Mono
but he did it
to his credit
lol
but DotNetty looked glowing slowly and I thought that it was behind.
it's getting used more internally inside Azure
for their IOT gateway
on my to-do list
still need to ship a DotNetty Akka.Remote.Transport nuget package
but I'd want to add UDP support to DotNetty first
before doing that
I'd be releasing that package separately