11 Replies Latest reply on Dec 19, 2001 3:34 PM by slaboure

    round-robin

    sojka

      Hi
      I try JBoss 3.0 Clustering. I am really impressed how it works.
      I have small problem with round-robin:
      I set clustering with default parameters (I copied cluster-service.xml to deploy directory). My bean is InterestBean from JBoss documentation-example with added tag in jboss.xml:
      True.
      First I try fail over - it works perfectly. When one server go down all invokes are redirect to another.
      Next I try load balancing:
      I add loop in InterestClient to invoke 10 times interest.calculateCompoundInterest(...) method.
      All invoke go to one server.
      I thought that I've got RoundRobin load balancing policy and invoke should go once to one server and next to another (currently I have 2 servers).
      My question is:
      1. How round robin work in JBoss?
      2. How to set load balancing that first invoke go to server1, second to server2, third to server1 and etc.

      Dawid

        • 1. Re: round-robin
          slaboure

          Hello,

          That is strange. If this is a SLSB, load balancing should occur by default (you can set this in your depl. descr.)

          Set JBoss logging level to "info" and watch messages like :
          "using default RoundRobin for bean load balancing." while deploying your bean.

          feedback welcome.

          Cheers,


          Sacha

          • 2. Re: round-robin

            I was under the impression that the jboss load balances the bean creation and not the invocation of methods from an already created bean.

            • 3. Re: round-robin
              sojka

              hi
              I tested more clustering. Round robin started work, but it does not work every time. When I started my servers (2) first time everything work fine (usually). But when I restart few times servers all request are process only by one server. When I shutdown server which process all request the second started work. When I start first server it start process all request again.
              Here is logs which I think are responsible for this situation:
              [16:42:27,774,HASessionState-/HASessionState/Default] Computed topology : {
              SessionState-'/HASessionState/Default'-Group-0:[[theorik:1038, odalix:1037]] aka '[]'
              }
              [16:42:28,287,HASessionState-/HASessionState/Default] Starting repartitioning... :{
              SessionState-'/HASessionState/Default'-Group-0:[[theorik:1038, odalix:1037]] aka '[]'
              }
              [16:42:28,287,HASessionState-/HASessionState/Default] We stay in the same partition ('SessionState-'/HASessionState/Default'-Group-0'): nothing to do
              [16:42:28,288,HASessionState-/HASessionState/Default] Repartitioning done.
              [16:42:28,290,HAPartition:DefaultPartition] Handle: DistributedState._set
              [16:42:28,291,HASessionState-/HASessionState/Default] Starting repartitioning... :{
              SessionState-'/HASessionState/Default'-Group-1:[[odalix:1037]] aka '[]'
              }

              I don't know why in Group-1 is only one server - I have running 2 servers.
              Dawid

              • 4. Re: round-robin
                slaboure

                Sojka,

                I thought you were speaking about SLSB, not SFSB. We do *not* load balance calls with SFSB (what an horror! the state would need to travel between nodes for each invocation)

                Which kind of bean are you using?

                The log you give is a SFSB trace.

                Cheers,



                Sacha

                • 5. Re: round-robin
                  sojka

                  hi Sacha,
                  Of course we were speaking about SLSB. Sorry for this log, but I don't know too much about JBoss logs.
                  I am sure in 100% that I use stateless session bean. I tested it more and I still have the same problem. I understand that it is alpha version, but you have asked about feedback - so it was feedback.
                  BTW, if you started speak about stateful session bean, I have question:
                  Is it possible to set some method in SFSB that they change (only this method, not another) state of bean in all cluster. For example I have login method - and only this method changes state in my bean. I wanted have information that client is logged on all servers in cluster. If the server on which client directly was logged go down, another server could take request from client. In this case this second server need to know if client has already logged or not.

                  regards
                  Dawid

                  • 6. Re: round-robin
                    slaboure

                    Hello,

                    > Of course we were speaking about SLSB. Sorry for this
                    > log, but I don't know too much about JBoss logs.
                    > I am sure in 100% that I use stateless session bean.
                    > I tested it more and I still have the same problem. I

                    Do not hesitate to provide me a log file (to my private e-mail address for example) so I can analyse it.

                    > understand that it is alpha version, but you have
                    > asked about feedback - so it was feedback.

                    Sure, thank you for you feedbac! continue this way, that's great for us.

                    > BTW, if you started speak about stateful session
                    > bean, I have question:
                    > Is it possible to set some method in SFSB that they
                    > change (only this method, not another) state of bean
                    > in all cluster. For example I have login method - and
                    > only this method changes state in my bean. I wanted
                    > have information that client is logged on all servers
                    > in cluster. If the server on which client directly
                    > was logged go down, another server could take request
                    > from client. In this case this second server need to
                    > know if client has already logged or not.

                    I am not sure I understand your concern. If, what you want, is that once a server on which a client has logged on fails, the client is automatically redirected to a working node and does not need to log again (i.e. it can re-use the previous state before the other node had failed), then it *is* the way it behaves, in any cases.

                    Cheers,



                    Sacha

                    • 7. Re: round-robin
                      slaboure

                      Hello,

                      I've tested the very simple testbean.jar from the testsuite (the nextgen.StatelessSession SLSB).

                      I've only added a jboss.xml file to the jar and set True for this bean, without setting any other clustering option.

                      It has worked as it should have: calls have been load-balanced between nodes of the cluster.

                      Consequently, you should check these points:
                      - you have correctly set the tag for your target SLSB bean
                      - when the bean is deployed on one node, you should see entries such as these on the *other* nodes of the cluster:

                      [16:57:40,720,DefaultPartition:ReplicantManager] _add(nextgen.StatelessSession, sacha:1161
                      [16:57:40,720,DefaultPartition:ReplicantManager] _adding new HashMap
                      [16:57:40,720,DefaultPartition:ReplicantManager] notifyKeyListeners

                      (well, bean name and host name will be different I guess... ;) )

                      If you don't see these entries, it means that the bean is not "cluster-deployed"

                      The fact that you were able to use one bean or the other in your tests (but without load-balancing) is logical: the HA-JNDI layer was "electing" a target node that was containing the deployed bean but the bean itself was actually not clustered.

                      Cheers,



                      Sacha

                      • 8. Re: round-robin
                        slaboure

                        That is really strange... The only reason I can think of is a JavaGroups-level issue i.e. the configuration of JG does not fit your environment. What is your network scheme (i.e. simple LAN with hubs/switch?)

                        Is your code self-contained? If that is the case (i.e. if you have a reproducible case), send me the code, I will debug it and try to find the reason of the problem. It should behave as you mentionned it i.e. 1, 3, 5... and 2, 4, 6 for the other node.

                        Cheers,



                        Sacha

                        • 9. Re: round-robin
                          bill.burke

                          Are all nodes started before you start your client? This is the only reason you could get this behaviour. These are SLSBs correct?

                          • 10. Re: round-robin
                            sojka

                            Hi
                            >What is your network scheme (i.e. simple LAN with hubs/switch?)
                            I don't know to much about my network, I must speak with my admin, because it could be reason my problems. I noticed that multicasting is not working in my network. Have you tested JBoss Clustering without multicasting?

                            >send me the code
                            my code is very simple, I only add "cluster" in jboss.xml tag in Interest sample from JBoss doc - so I think it doesn't have sense to send you this code.
                            I really appreciate you support, thank you very much for you help.

                            regards
                            Dawid

                            • 11. Re: round-robin
                              slaboure

                              Well... even that simple, it will shorten the time needed to make the test. Please send me the client and bean code (jar) to sacha.labourey@cogito-info.ch

                              Cheers,


                              Sacha