Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
  • 00:47
    Aaronontheweb commented #4948
  • 00:45
    Aaronontheweb assigned #4948
  • 00:45
    Aaronontheweb synchronize #4946
  • 00:45
    Aaronontheweb labeled #4948
  • 00:45
    Aaronontheweb labeled #4948
  • 00:45
    Aaronontheweb opened #4948
  • 00:45
    Aaronontheweb milestoned #4948
  • 00:33
    Aaronontheweb synchronize #4882
  • Apr 18 21:47
    Aaronontheweb synchronize #4882
  • Apr 18 21:45
    Aaronontheweb synchronize #4946
  • Apr 18 21:45
    Aaronontheweb commented #4946
  • Apr 18 21:45

    Aaronontheweb on dev

    modified PingPong / RemotePingP… (compare)

  • Apr 18 21:45
    Aaronontheweb closed #4947
  • Apr 18 21:44
    Aaronontheweb synchronize #4946
  • Apr 18 21:38
    Aaronontheweb auto_merge_enabled #4947
  • Apr 18 21:38
    Aaronontheweb labeled #4947
  • Apr 18 21:38
    Aaronontheweb opened #4947
  • Apr 18 21:21
    Aaronontheweb commented #4882
  • Apr 18 21:21
    Aaronontheweb synchronize #4882
  • Apr 18 20:36
    Aaronontheweb commented #4946
Aaron Stannard
@Aaronontheweb
this is with Hyperion
do you get that issue without it?
and is this on Linux?
Jesse Connor
@jesseconnr
It's on windows.
Aaron Stannard
@Aaronontheweb
so we've had reports of DotNetty fucking up its length-frame encoding
on v0.4.6
originally the reports were Windows-only
err
Linux only
Jesse Connor
@jesseconnr
I send the messages in the same order and tried to figure out if it was a particular one that was having a serialization issue, but the point at which the error occurs seems random.
Aaron Stannard
@Aaronontheweb
had one last week on Windows
no no, this isn't something you're doing wrong
it's DotNetty
Jesse Connor
@jesseconnr
I believe I read that issue, but I think I'm on 0.4.7
Yep, as far as I can tell, DotNetty is all 0.4.7
Aaron Stannard
@Aaronontheweb
v0.4.7 has major issues
like, their API is outright broken there
I've literally never had this issue happen to me on v0.4.6 but other users have reported it
I would strongly, strongly encourage rolling back to v0.4.6
Jesse Connor
@jesseconnr
I was having the issue on 0.4.6 and an older version of akka and upgraded to see if it would fix it and no dice.
Aaron Stannard
@Aaronontheweb
well shucks
can you guys do me a favor and open an issue on the DotNetty github
I don't have a window where I can even look into the issue for another 5 days
you're going to get a faster resolution on it if we can get their org to start looking at the problem
this is not an Akka.NET issue
it's a problem with length-frame encoding not being written or read correctly
Jesse Connor
@jesseconnr
Ah yeah I see the bug report and the mention. I get that same error. DotNetty.Codecs.TooLongFrameException: Adjusted frame length exceeds 128000: 419561476 - discarded
Aaron Stannard
@Aaronontheweb
Azure/DotNetty#360
Jesse Connor
@jesseconnr
hmm, v5 was next week in february, but I guess it never got there
Aaron Stannard
@Aaronontheweb
I have the DotNetty guys on the horn in their gitter now
please go post a copy of your error message et al
that would help
have to demonstrate the pervasiveness of the issue
Jesse Connor
@jesseconnr
Would having an old 1.3.0 version of Akka.Serialization.Hyperion possibly have an effect?
I just realized that when everything else was updated, that wasn't because I didn't check the prerelease in visual studio.
Aaron Stannard
@Aaronontheweb
try an upgrade and see what happens
but this looks really clearly like a DotNetty issue
Ryan Anthony
@ryandanthony_twitter
Can you use a Lighthouse type of solution with Akka.Cluster.Sharding?
Aaron Stannard
@Aaronontheweb
https://petabridge.com/blog/cluster-sharding-technical-overview-akkadotnet/ - scroll to the bottom
Ryan Anthony
@ryandanthony_twitter
ok let me try that
thanks
Jesse Connor
@jesseconnr
Ah well, I would try, but using nuget from within visual studio to downgrade was apparently a bad idea, everything is wonderfully jacked now. :)
Aaron Stannard
@Aaronontheweb
lol
well, got some answers from the DotNetty crew that make some sense
due to some issues with .NET Core, it's possible that the byte buffer pools DotNetty uses can be released early
by the socket itself
especially true on Linux
we use the default byte buffer allocator in our DotNetty transport, which uses pooling
this normally helps performance big time, because it eliminates allocations and keeps GC pressure down
guess I could expose some sort of setting to change the pooling strategy within Akka.Remote's DotNetty transport ("none" being an option)