6 Replies Latest reply on Jun 28, 2010 11:48 AM by brian.stansberry

    Domain/Host Update Results

    dmlloyd

      What are some examples of possible successful results for domain and host updates?  Apart from the obvious one, "no result" aka simple success.  What kinds of operations generate a more interesting result that the user would want to see in the console, and what would that result be?

       

      For operations which span multiple servers, how should the results be accumulated?  Intermixed success and exception list?

        • 1. Re: Domain/Host Update Results
          emuckenhuber

          David Lloyd wrote:

           

          What are some examples of possible successful results for domain and host updates?  Apart from the obvious one, "no result" aka simple success.  What kinds of operations generate a more interesting result that the user would want to see in the console, and what would that result be?

           

          For operations which span multiple servers, how should the results be accumulated?  Intermixed success and exception list?

          Maybe a response with a list of (Node, Value) would be interesting in general. Also for queries of metrics, so this might be the best option - as the console can decide how to present the result.

          • 2. Re: Domain/Host Update Results
            johnbailey

            I am having trouble thinking of update operations that would have more info than "success" or "failure", but it need to maintain information about individual SM/S results for certain operations.  (Eg.  update config in SM A and sync the changes to all SMs)

             

            What would cause a "no result" response?  An operation to update config on a SM that was also done manually on the SM?   

             

            I think the metric based operations would likely have a lot more information and the information will need to contain the markers for where the information came from (SM, server).

            • 3. Re: Domain/Host Update Results
              emuckenhuber

              John Bailey wrote:

               

              I am having trouble thinking of update operations that would have more info than "success" or "failure", but it need to maintain information about individual SM/S results for certain operations.  (Eg.  update config in SM A and sync the changes to all SMs)

              Yeah i agree some more details on what happened during an update could be interesting.

              John Bailey wrote:

               

              What would cause a "no result" response?  An operation to update config on a SM that was also done manually on the SM?   

              Not sure in the update case. However we currently have managed operations with "void" as return type. Maybe that's "no result"? A operation which already has been done, should maybe return "nothing to do"

              John Bailey wrote:

               

              I think the metric based operations would likely have a lot more information and the information will need to contain the markers for where the information came from (SM, server).

              Yes, that's what i meant with "Node" as the identifier for the server. Currently the actual return value for metrics and operations goes from void, over simple types to a Map of JMS messages or ejb3 method invocation stats.

              • 4. Re: Domain/Host Update Results
                dmlloyd

                Emanuel Muckenhuber wrote:

                John Bailey wrote:

                 

                What would cause a "no result" response?  An operation to update config on a SM that was also done manually on the SM?   

                Not sure in the update case. However we currently have managed operations with "void" as return type. Maybe that's "no result"? A operation which already has been done, should maybe return "nothing to do"

                 

                Yeah by "no result" I mean "void result".

                 

                I don't know about "nothing to do".  Such a case could happen at a few levels:

                1. The change applies to something in the domain; the domain already has the exact info so "nothing to do".  We could detect this state and skip sending the change to the Servers, but it seems like we might use a valuable debugging/problem solving tool...
                2. The change applies to something in the domain but the domain doesn't have the info for some reason.  However, the change doesn't actually affect anything on the Servers.  Thus the domain state is updated, but theres "nothing to do" on the actual Servers.

                 

                In addition it's possible that you can't get a result from a Server because it's simply not up at the time.  So do we bother accumulating results from the servers that are up, or do we just accept a result at the domain level?

                • 5. Re: Domain/Host Update Results
                  emuckenhuber

                  David Lloyd wrote:

                   

                  I don't know about "nothing to do".  Such a case could happen at a few levels:

                  1. The change applies to something in the domain; the domain already has the exact info so "nothing to do".  We could detect this state and skip sending the change to the Servers, but it seems like we might use a valuable debugging/problem solving tool...
                  2. The change applies to something in the domain but the domain doesn't have the info for some reason.  However, the change doesn't actually affect anything on the Servers.  Thus the domain state is updated, but theres "nothing to do" on the actual Servers.

                  Yeah, "nothing to do" was not a very good example. I guess it depends on what all can be considered as managed operation. Nothing to do would rather fit when a node is out of sync. Which most likely should not happen once it's up and running.

                   

                  David Lloyd wrote:

                   

                  In addition it's possible that you can't get a result from a Server because it's simply not up at the time.  So do we bother accumulating results from the servers that are up, or do we just accept a result at the domain level?

                  Hmm most likely only results from the servers that are up?

                   

                  With the hosts.xml - can't we just ditch the instance scope from the domain level and rather have a more group based notion? At least something like a pool size rather depends on the host environment than a "server/instance name". Is that where you are going with that or maybe i'm just far off?

                  • 6. Re: Domain/Host Update Results
                    brian.stansberry

                    Emanuel Muckenhuber wrote:

                    David Lloyd wrote:

                     

                    In addition it's possible that you can't get a result from a Server because it's simply not up at the time.  So do we bother accumulating results from the servers that are up, or do we just accept a result at the domain level?

                    Hmm most likely only results from the servers that are up?

                     

                    It should be simple enough to include an entry for known servers that are not up that reflects that fact. Otherwise the client has to try and interpret why a value for a given server wasn't received, probably by querying for the domain membership. So, two queries, and then to be truly correct, some mechanism to make those two queries an atomic operation.

                     

                     

                    Emanuel Muckenhuber wrote:


                     

                    With the hosts.xml - can't we just ditch the instance scope from the domain level and rather have a more group based notion? At least something like a pool size rather depends on the host environment than a "server/instance name". Is that where you are going with that or maybe i'm just far off?

                     

                    Yeah, the idea is to get the instance-scope stuff out of the domain-level file.