Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
  • 18:58
    Aaronontheweb commented #3863
  • 18:16
    Aaronontheweb commented #4022
  • 17:52
    MaximG1234 commented #4054
  • 17:52
    MaximG1234 commented #4054
  • 17:52
    MaximG1234 commented #4054
  • 17:51
    MaximG1234 commented #4054
  • 17:49
    Aaronontheweb commented #4054
  • 17:49
    MaximG1234 commented #4054
  • 17:48
    MaximG1234 commented #4054
  • 17:47
    MaximG1234 commented #4054
  • 17:44
    Aaronontheweb commented #4054
  • 17:43
    MaximG1234 commented #4054
  • 17:42
    ismaelhamed synchronize #3863
  • 17:39
    MaximG1234 commented #4054
  • 17:35
    MaximG1234 commented #4054
  • 17:34
    MaximG1234 commented #4054
  • 17:31
    MaximG1234 commented #4054
  • 17:10
    Aaronontheweb commented #4054
  • 17:06
    MaximG1234 commented #4054
  • 17:05

    dependabot-preview[bot] on nuget

    (compare)

Bartosz Sypytkowski
@Horusiath
it's common for all persistence plugins, but you're right - it should be mentioned in readme
Max
@maxpaj
Alright! But how come it wasn't throwing any errors at me while my config was incorrect?
Bartosz Sypytkowski
@Horusiath
your config is correct (probably). It's just not used
Max
@maxpaj
Right, so it's using the default configuration for persistence then, which is what?
Bartosz Sypytkowski
@Horusiath
by default, journal is in-memory
Max
@maxpaj
Alright, how will that persist my events? Sorry, but this is strange to me... :'(
Bartosz Sypytkowski
@Horusiath
np ;) default journal stores all events directly in memory - it's not meant to be used for production, more for samples and testing purposes
so when your program stop, all events will perish
Max
@maxpaj
Alright, that makes sense :)
Aaron Stannard
@Aaronontheweb
@vladkosarev working on that today
@Horusiath Azure websites is fixed in dev
issue is that Azure websites doesn't support IPV6
Vlad Kosarev
@vladkosarev
@Aaronontheweb thanks, we reverted to 1.0.8
Aaron Stannard
@Aaronontheweb
yeah, sorry about that - trying to add support for IPV6 broke a ton of shit
growing pains there
although kind of surprised that so many parts of Azure don't support it - the thing has been out for like a decade
Aaron Stannard
@Aaronontheweb
@Danthar @Silv3rcircl3 working on updating our build script so I can make it mono-friendly
for all of the plugins
TL;DR;, in order for our Docker strategy to work with Akka.Persistence I basically need both parts of the testing process to run inside a Docker container
that will allow me to link the containers
today that looks like running everything on Mono for the testing stage
in the not too distant future, .NET Core
Aaron Stannard
@Aaronontheweb
@alexvaluyskiy @Silv3rcircl3 @Horusiath ready to merge I think: akkadotnet/akka.net#2294
that'll help me get the Mono suite passing
Bartosz Sypytkowski
@Horusiath
ok, I'm merging that
Aaron Stannard
@Aaronontheweb
just about have the PostgreSql test suite working on Mono
have to do a bunch of funky Linux-specific file globbing and crap
ty @Horusiath
Aaron Stannard
@Aaronontheweb
alright, I give up - between half the shit for Akka.Persistence.PostgreSql not working at all on Mono and Docker on Windows Server 2016 barfing up segfaults when I try to run postgres on it
I've exhausted the options for getting builds running for it again
right way to fix this is to force all Akka.Persistence plugins to work on Mono only for the time being (i.e. build chain, drivers work on Mono or no CI) - SQL Server, on the other hand, we should be able to get working on 2016
Aaron Stannard
@Aaronontheweb
alright, Mono build chain is able to run end to end except for some Akka.IO specs
more TCP stuff again
going to see if I can get some more information with the logging settings turned up
if that doesn't help me suss out what the issue is exactly, going to mark it as "won't fix" since all of this shit is about to be rewritten anyway
Aaron Stannard
@Aaronontheweb
woot
think I was able to hotfix Akka.IO
riawz
@riawz

does it make any difference in terms of resource sharing / performance in an actor which does self polling

to have a short delay using Context.System.Scheduler.ScheduleTellOnce(10, Self, SelfPoll(), Self), like 10 ms
VS
Self.Tell(SelfPoll()) straight away

Aaron Stannard
@Aaronontheweb
@riawz the IScheduler allocates a Task-like object basically
the SelfPoll will fire immediately without allocating anything other than the message (and possibly some space inside the mailbox depending on how large the queue is)
really though, I'd use the scheduler if you really need a delay of any kind
otherwise it's safe to just to a self tell right away
@Silv3rcircl3 got the Akka.Streams suite mostly passing on Mono now... had a weird compilation bug on one spec that broke on a rebase
two areas where Reflection.Emit (from inside the expression compiler) power vomits and blows things up
going to see if there's a work-around
riawz
@riawz
@Aaronontheweb thanks!
Aaron Stannard
@Aaronontheweb
@Silv3rcircl3 anything special about these specs that failed in Akka.Streams? Trying to find the common root cause given that the failure is the same, but there are other specs inside these test fixtures which pass: http://petabridge-ci.cloudapp.net/viewLog.html?buildId=15933&tab=buildResultsDiv&buildTypeId=AkkaNet_LinuxMonoBuild&guest=1
this is building off of a personal branch of mine at the moment - haven't fundamentally changed streams in any meaningful way
Boban
@bobanco
This message was deleted
Aaron Stannard
@Aaronontheweb
what it looks like to me