Yes, but at the same time, creating a lighthouse service is literally 3 lines of code + a bit of config in its simplest form.. Petabridge Lighthouse does a little bit more, you can pass command line arguments and such to it..
But we also have to keep in mind the scope of the akka.net project, we are porting what exists in java Akka. everything else is pretty much out of scope and should be hosted elsewhere
I think that Lighthouse as command-line program installed as chocolatey is good idea
yes absolutely. but that can be managed by Petabridge
@Horusiath where is the 3 sec for akka.persistence tests specified?
the timeout that is.. hardcoded or in config?
@rogeralsing are you talking about Akka.Persistence.TestKit specs?
AsyncWriteProxy has hardcoded timeout (marked as TODO in both .NET and JVM ;) ) on replay but it's not 3sec ;) If I'm correct this is a TestProbe.ExpectMsg timeout
Pretty impressive with an Akka Transport on Akka IO :)
The framework builds itself :D
@rogeralsing I see you point about leaving Akka.NET clear and following inherited Akka model. But 3 lines of code is potentially 3 bugs. So having reusable piece of code even such small piece of code won't hurt anyone I believe. It's possible to put discovery service to a separate package as @tstojecki mentioned and I think such package will appear in form of community contribs to the project.
@Horusiath that is a good idea
I'll see about making that happen
@timba I'm going to make lighthouse more user-friendly, for sure
@rogeralsing is there a new XUnit plugin for ReSharper or VS that runs XUnit 2?
I miss being able to run our tests in debug mode :p
also, I'm not a fan of the latest changes to Gitter - seems like they don't show which messages have been read or not any more
@Aaronontheweb good article, have you actually used akka.net cluster in prod with good success? ... would love to that, but those intermittent tcp errors are not giving me a warm and fuzzy feeling
i have looked at the comments and issues today, looks like others are running to some of those as well
This message was deleted
@tstojecki senor @annymsMthd has. You have to bear in mind that a lot of the issues that come up with Akka.Cluster when you're initially launching it have to do with two nodes racing to connect with each other, dropping the connection attempt when they realize that two are occurring at once (which is illegal,) and then waiting at random intervals to attempt to connect again.
Cassandra, Riak, and other clustered DB systems run into the same issue
and it's something that comes up more often in dev and test than production
that being said, eliminating intermittent TCP connection errors is something that we're still working on
1.0.2 resolved a lot of that
but there's still a lot more work to do
I'm just about done with the R&D I had to do to develop Petabridge's training courses (gotta pay the bills,) shifting back to full-time R&D on Akka.Cluster and Helios next week
I've personally used Akka.Remote in production under what I would consider to be very heavy workloads
great to hear you guys are aware and on top of that
yeah, I'm anal about the quality control on Akka.Cluster - but a lot of the issues are really subtle
i.e. we realized that running the heartbeat system on top of the TPL had devastating consequences under even light loads