8 Replies Latest reply on Apr 9, 2009 5:17 PM by Jason Greene

    New tree state model

    Ales Justin Master

       

      "kabir" wrote:

      I've vaguely started thinking about this in the back of my mind, and am curious about how you see a few of the initial concepts.

      In the current linear one, install/uninstall = move to next/previous state.

      In the tree-based one, there will be more than one state to "install" to. Something needs to decide that. How will the decision be made, and who will make it, about what state to move to?

      Going "back" will one always transition to the fromState? Or can there be several of these as well? This question feels weird, but I was thinking of circular states such as
      "Does Not Exist" <-> "method ready"
      ^-------------> passive <-----^

      It would still be sort of linear,
      meaning we wouldn't have to change too much.

      At that time I was thinking about having some sub-linear path in the ControllerContext.
      And you would only change that path once you needed a different state "route".

      Afair this would work, you would only need some additional checks.
      e.g. confirming that the path you provided is legal
      e.g.2 checking if the state you wanna transfer exists on that path
      ...

      And instead of asking the Controller to provide the state model,
      you would ask the ControllerContext for his current linear path.

      HTH


        • 1. Re: New tree state model
          David Lloyd Master

          Just out of curiousity - what is wrong with the original linear state model? Seems like exploring concurrent startup etc. would be more important to most users.

          • 2. Re: New tree state model
            Ales Justin Master

             

            "david.lloyd@jboss.com" wrote:
            Just out of curiousity - what is wrong with the original linear state model?

            It's not able to support EJB state model,
            which has some decision/condition after passivate state,
            hence it's not plain linear.

            • 3. Re: New tree state model
              Jason Greene Master

               

              "alesj" wrote:
              "david.lloyd@jboss.com" wrote:
              Just out of curiousity - what is wrong with the original linear state model?

              It's not able to support EJB state model,
              which has some decision/condition after passivate state,
              hence it's not plain linear.


              This just sounds wrong. We should not be increasing the already high level of complexity in the MC by trying to make it into an EJB container. Why does the MC have to manage anything associated with passivation?

              • 4. Re: New tree state model
                David Lloyd Master

                Yeah, I tend to agree - anyway this doesn't seem to be the time to be redesigning core chunks of the MC. Just my opinion

                • 5. Re: New tree state model
                  Ales Justin Master

                   

                  "jason.greene@jboss.com" wrote:

                  We should not be increasing the already high level of complexity in the MC by trying to make it into an EJB container.

                  Where did you pick up this?
                  This is just a discussion/brainstorming about
                  how to change current (limited) linear state model.

                  "jason.greene@jboss.com" wrote:
                  Why does the MC have to manage anything associated with passivation?

                  This was just an example.
                  And since EJB actually builds upon MC, it's a real example.
                  Currently they have to do some tweaks/hacks to get around this problem.
                  With a tree based state model this would be trivial to do it properly.

                  "david.lloyd@jboss.com" wrote:

                  anyway this doesn't seem to be the time to be redesigning core chunks of the MC

                  Who said this is gonna be done now? ;-)
                  This is a future roadmap feature, which Kabir got interested about.

                  Your two post are just steering this discussion off the target.
                  I would much rather see you added something useful on how
                  we should actually impl this new tree model,
                  then jumping on the thread when I simply mention EJB.
                  This is just not the way how MC dev forum should work. ;-)


                  • 6. Re: New tree state model
                    Jason Greene Master

                     

                    "alesj" wrote:
                    "jason.greene@jboss.com" wrote:

                    We should not be increasing the already high level of complexity in the MC by trying to make it into an EJB container.

                    Where did you pick up this?
                    This is just a discussion/brainstorming about
                    how to change current (limited) linear state model.


                    Increasing the complexity of the MC state model to support something that only EJB3 needs, that might not even be the right way to solve their problem needs to be justified.


                    "jason.greene@jboss.com" wrote:
                    Why does the MC have to manage anything associated with passivation?

                    This was just an example.
                    And since EJB actually builds upon MC, it's a real example.
                    Currently they have to do some tweaks/hacks to get around this problem.
                    With a tree based state model this would be trivial to do it properly.


                    Great, but before this is done, we need to first ask should it be done? Does the overall AS architecture make sense this way? How does this make the MC better for users? How does this make the AS better for users?


                    Your two post are just steering this discussion off the target.
                    I would much rather see you added something useful on how
                    we should actually impl this new tree model,
                    then jumping on the thread when I simply mention EJB.
                    This is just not the way how MC dev forum should work. ;-)


                    This is exactly the way this forum should work.



                    • 7. Re: New tree state model
                      Ales Justin Master

                       

                      "jason.greene@jboss.com" wrote:

                      Increasing the complexity of the MC state model to support something that only EJB3 needs, that might not even be the right way to solve their problem needs to be justified.

                      Justified by who or what?
                      And how do you know that might not be the right way to do it?
                      They are moving more and more to MC.
                      Why should they invent a new way to handle their lifecycle
                      when MC could/should do this.

                      I'm not saying it needs to be done now.
                      And nothing of what I wrote implied it will be.

                      "jason.greene@jboss.com" wrote:

                      Great, but before this is done, we need to first ask should it be done?

                      Afaik MC has it's own roadmap, steered by the one's who are actively involved / contribute.

                      "jason.greene@jboss.com" wrote:

                      Does the overall AS architecture make sense this way?

                      AS has nothing to do here.
                      This is transparent to 99,9% of MC use cases.
                      Apart from EJB3 there is no project/component that I know
                      that is outside of MC umbrella and uses MC/Kernel spi directly.

                      "jason.greene@jboss.com" wrote:

                      How does this make the MC better for users?

                      More generic state model.
                      This was one of the ideas from the first day I joined the project back in 2006.
                      It was based on my real use case from my previous work.

                      "jason.greene@jboss.com" wrote:

                      How does this make the AS better for users?

                      Again, no relation, it should be completely transparent.
                      And it depends which users you're refering to here.
                      Plain app developer doesn't see the diff from 4.2.x and 5.x wrt to kernel.

                      If you mean components inside AS, then EJB3 is a clear example.
                      We would only have a single lifecycle state model,
                      hence the possible contributors wouldn't have learn any other hacks.

                      "jason.greene@jboss.com" wrote:

                      "alesj" wrote:

                      Your two post are just steering this discussion off the target.
                      I would much rather see you added something useful on how
                      we should actually impl this new tree model,
                      then jumping on the thread when I simply mention EJB.
                      This is just not the way how MC dev forum should work. ;-)

                      This is exactly the way this forum should work.

                      By hijacking brainstorming thread. Nice ...

                      It was never done this way and I hope it will stay that way.
                      If you mean to bring AS to every MC dev thread,
                      then I don't see why we have Pojo server forum.
                      I'm not saying it should be completely separate,
                      but it should be limited to only issues that are not transparent to AS.
                      e.g. deployers api, OSGi-fication, ...


                      • 8. Re: New tree state model
                        Jason Greene Master

                         

                        "alesj" wrote:
                        "jason.greene@jboss.com" wrote:

                        Increasing the complexity of the MC state model to support something that only EJB3 needs, that might not even be the right way to solve their problem needs to be justified.

                        Justified by who or what?
                        And how do you know that might not be the right way to do it?
                        They are moving more and more to MC.
                        Why should they invent a new way to handle their lifecycle
                        when MC could/should do this.


                        A project's scope and proper usage is a normal topic to discuss when core architectural changes are being considered, especially when it impacts the many things that depend on it. It could very well be this is the right way, which is why i said "may". I am generally suspicious about pushing more and more ejb specific behavior into the MC.


                        "jason.greene@jboss.com" wrote:

                        Great, but before this is done, we need to first ask should it be done?

                        Afaik MC has it's own roadmap, steered by the one's who are actively involved / contribute.


                        First off, part of public forums and open source is accepting feedback from anywhere, and being open to public debate. Second of all, the roadmap needs to consider the big picture, since AS is the whole reason (and the funding source) for this project.


                        "jason.greene@jboss.com" wrote:

                        Does the overall AS architecture make sense this way?

                        AS has nothing to do here.
                        This is transparent to 99,9% of MC use cases.
                        Apart from EJB3 there is no project/component that I know
                        that is outside of MC umbrella and uses MC/Kernel spi directly.


                        Sure it does. All design decisions with the MC greatly affect the AS, even more so now that EJB functionality keeps moving in its direction. We have ALOT of work to do to make the AS better (performance, on-demand, etc), and the only way we are going to accomplish this, is if every task is tied to a user need.


                        "jason.greene@jboss.com" wrote:

                        How does this make the MC better for users?

                        More generic state model.
                        This was one of the ideas from the first day I joined the project back in 2006.
                        It was based on my real use case from my previous work.


                        Alright, but shouldn't these use cases be discussed before a solution is designed?


                        "jason.greene@jboss.com" wrote:

                        How does this make the AS better for users?

                        Again, no relation, it should be completely transparent.
                        And it depends which users you're refering to here.
                        Plain app developer doesn't see the diff from 4.2.x and 5.x wrt to kernel.


                        Sure they do, they see more memory consumption and unreasonable startup times ;) The negative side-effects should be considered (and compensated with the good) as well.


                        If you mean components inside AS, then EJB3 is a clear example.
                        We would only have a single lifecycle state model,
                        hence the possible contributors wouldn't have learn any other hacks.


                        "Hack" is rather subjective. The overall question to answer, is where do we draw the line on functionality that should be specific to EJB. Does passivation of MC beans make sense? Should MC be a superset of EJB? The answers to these questions *majorly* affect other componets. As an example, if passivation is moved to the MC, then clustering must switch its implementation to the MC.

                        "alesj" wrote:

                        By hijacking brainstorming thread. Nice ...

                        It was never done this way and I hope it will stay that way.
                        If you mean to bring AS to every MC dev thread,
                        then I don't see why we have Pojo server forum.
                        I'm not saying it should be completely separate,
                        but it should be limited to only issues that are not transparent to AS.
                        e.g. deployers api, OSGi-fication, ...


                        Perhaps some of the branches of this conversation should be moved to a separate thread. However, discussing the reasons and use-cases for a MC architecture change in the first thread announcing such a change seems reasonable to me.