by

Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
    olexiyb
    @olexiyb
    @leenozara you need to invite more people who will take care about project. Please take a look into
    https://github.com/actors-rs/actors.rs
    folder structure.
    I have moved example, frontpage and mkdocs to be part of the same repo.
    This way you can propose some change and document at the same time and examples will be kept up to date as well.
    I also utilize standard github pages, so you do not need to pay for hosting
    https://actors-rs.github.io/
    I will be glad to contribute to riker.
    Plus I have added support of https://github.com/pre-commit/pre-commit to enforce the change before commit.
    Be Reddy
    @bereddy_gitlab
    Thank you for your update, @leenozara . Your update was very much along the lines of what I thought we might here back from you, which is why I did not think immediately creating a fork was the most sensible approach to the situation. I am sorry for the burnout you experienced, and I hope the break you took gave you a chance to fully recharge your batteries. As always, I appreciate the tremendous work you've done thus far on Riker.
    Steve Biedermann
    @hardliner66
    @olexiyb while I think that some of the changes you made are good, I don't think it was a good idea to merge every pull request without further discussion.
    olexiyb
    @olexiyb
    @hardliner66 I did review all pull requests I personally like all of them
    especially this one riker-rs/riker#84
    Steve Biedermann
    @hardliner66
    yeah, I like my pull request too, but I'm not the only person using riker. Maybe there are better ways to do what I wanted to achieve, but we wont know if there is no discussion about it. Also I think on some pull request there where still open questions or remarks which haven't been addressed and one pull request failed to build properly for whatever reason. I also don't want to say that these changes shouldn't be merged, just that it shouldn't be rushed and maybe be reviewed by a few people.
    olexiyb
    @olexiyb
    @hardliner66 build failure was just travis issue. Simple restart will help
    Steve Biedermann
    @hardliner66
    Thats good to know. But nothing in indicates that this was the case. There is only a merge of a seemingly broken pull request. Maybe a comment saying why it is okay to merge or something would have helped.
    olexiyb
    @olexiyb
    Let's see comments from @leenozara on pull requests as he is the one who knows the best his code :-)
    Mihail Malo
    @qm3ster
    @leenozara EPIC

    especially this one riker-rs/riker#84

    cheeky

    Lee Smith
    @leenozara
    Hi All, quick update from me. I've started to work through the outstanding PRs. I'd like to get those resolved first since folks took the time to contribute their code. After that's done I'll move on to addressing github issues including bringing Riker up to date with the latest version of futures, reviewing stable vs nightly etc. So @hardliner66 's PR #84 needs to be reviewed in depth by me and I will then prepare a publish of a new version on Cargo. I hope to get that done in the next two days. After that we can begin discussing how we want to move forward in terms of project development. Thanks!
    Steve Biedermann
    @hardliner66
    @leenozara If you have any questions let me know.
    PankajShet
    @PankajShet
    Hi Team,
    I am not able to find and CQRS and ES related code in the repo.
    Is it yet to be developed feature?
    Also any thing related to DDD?
    Please let me know, Am trying to understand the same.
    PankajShet
    @PankajShet
    Wish to know how does this framework differ from Axon framework in terms of features.
    One of those I can see are Riker supports Actor model like Akka
    Steve Biedermann
    @hardliner66
    I might be wrong, because I only heard about Axon right now, but I think the main difference would be that Axon is a microservice framework, which is built upon DDD (CQRS, ES) and Riker is an actor framework which supports CQRS and ES.
    CQRS is in a second repository: https://github.com/riker-rs/riker-cqrs
    I will have to look if I can find something on the event store.
    Steve Biedermann
    @hardliner66
    It seems that persitence (e.g.: the eventstore) is currently disabled. Maybe @leenozara can elaborate why this is.
    PankajShet
    @PankajShet
    Riker uses Akka like Actor Model and I think Riker should be able to be used as a microservices framework as Akka too can be used for distributed microservices
    melbourne2991
    @melbourne2991
    I would argue that microservices are a higher level abstraction that sits above the concurrency paradigm you use
    Steve Biedermann
    @hardliner66
    Sure it can be used that way. But it’s not a microservice framework. It’s an actor framework.
    melbourne2991
    @melbourne2991
    You can use actors for microservices sure, but you could also use channels or something else
    You can use actors for a bunch of things other than microservices
    PankajShet
    @PankajShet
    Ok got it, how does Ricker compare with Akka?
    melbourne2991
    @melbourne2991
    Akka is on the JVM, also Akka is an umbrella for a bunch of libraries
    Ok, so last time I looked at Riker what stopped me using it is it doesn't yet support remote actors (just checked the github now and it looks as though that is still the case)
    So you probably don't want to use it for microservices
    Then again, why Riker specifically says "Riker is a full-featured actor model implementation that scales to hundreds or thousands of microservices"
    So I'm not sure.
    I guess that's talking about microservices on a single machine
    Lee Smith
    @leenozara

    Hi all, Riker 0.4.0 has been published. This is a breaking change that introduces a much improved syntax to creating actors. A special thanks to @hardliner66 for this excellent contribution.

    I've updated the first page on the riker document site to use this new syntax and expand on the different ways creation in general can be done. I will update the rest of the documentation asap but I wanted to get this new version published today at the latest. riker-patterns will also be updated asap.

    Thank you all for your PRs and issues!

    [dependencies]
    riker = "0.4.0"
    Also let me say that while I haven't responded myself to recent and older conversations that have taken place here on Gitter I have noted them and will be used to improve the documentation, especially around clarifying common questions and misconceptions. Thank you all for your questions, thoughts, ideas, etc that are here on gitter.
    Steve Biedermann
    @hardliner66
    nice :D
    @leenozara I already have a pull request prepared for riker-patterns where I only need to update the dependency version for riker
    fstuess
    @fstuess
    @leenozara That is very nice to see! Thank you all!
    Lee Smith
    @leenozara
    @hardliner66 thanks for that!
    riker-patterns has been updated.
    [dependencies]
    riker-patterns = "0.4.0"
    Steve Biedermann
    @hardliner66
    @leenozara Over the last days I built a small application to experiment with riker performance and memory consumption. https://github.com/hardliner66/riker_bench
    I found that you send messages way faster than the actors can work on them, which leads to an enourmous memory growth, depending on the amount of unprocessed messages. In the extreme cases, this can exhaust all of the computers resources and even lead to system freezes (linux) or reboots (windows).
    This is because the channel used for communication is unbounded. I tried to make it configurable, but using a bounded channel on windows leads deadlocks (or livelocks, havent't looked close enough)
    Steve Biedermann
    @hardliner66
    Do you think this is something which riker should take care of or is this something the user of riker will have to keep in mind?
    Steve Biedermann
    @hardliner66
    This is how the memory timeline looks like when the process doesn't crash:
    grafik.png
    Lee Smith
    @leenozara

    yeah that's a complex question to answer. The idea of 'backpressure' comes into play here. And your question is the right one I think: Should backpressure be a part of riker, and if so is it a component of actors or something else? There are advantages of having unbounded mailboxes. A lot of this comes back to what an actor is, what it represents. In Erlang for example an actor is the unit for concurrency. For Akka, actors are a means to manage concurrency + state, and the unit for concurrency is just a stream.

    In Rust we already have async and backpressure so I'm not sure if that should be extended to Riker actors. By that I literally mean I don't know, not that my opinion is that it shouldn't be extended. I do think at the very least we should be providing best practices for this and clearly communicating what riker does and does not do, which isn't the case currently. I also think that it's important not to position Riker as an alternative to the work being done on async/futures because clearly the minds behind that are vastly better suited for the problems they're trying to solve. In that sense Riker is closer to Akka in that it is building on top of the language's standard concurrency to solve different problems.

    I'm sure you get all of this already but it's a common question so I'm providing an answer for others to see also. So my opinion is: At minimum we need to provide standard guidance on the problem of unbounded messages and how to implement some backpressure. At ideal, we should have something configurable that 'just works' without the deadlocks you see.

    Matt Johnston
    @mkj
    it seems like it would be useful to access the config in my actor's create_args(), that doesn't seem possible? Unless I pass it through as an argument I guess.
    Lee Smith
    @leenozara
    @mkj agreed, I would find that useful too. In terms of lifecycle management it does make it more complex. There are the pre and post start hooks that you can utilize, which require you to make use of Option or defaults on your data type if you're storing any config values. In your case would these work?
    /// Invoked when an actor is being started by the system.
      ///
        /// Any initialization inherent to the actor's role should be
        /// performed here.
        ///
        /// Panics in `pre_start` do not invoke the
        /// supervision strategy and the actor will be terminated.
    fn pre_start(&mut self, ctx: &Context<Self::Msg>) {}
    
    /// Invoked after an actor has started.
        ///
        /// Any post initialization can be performed here, such as writing
        /// to a log file, emmitting metrics.
        ///
        /// Panics in `post_start` follow the supervision strategy.
        fn post_start(&mut self, ctx: &Context<Self::Msg>) {}
    Matt Johnston
    @mkj
    yeah I looked at doing that but it pushed complexity further down. have now decided to stick with passing a custom struct around, I think I prefer it being strongly checked at the start rather than unwrapping config items throughout
    Adriano Santos
    @sleipnir
    Hello @all