6 Replies Latest reply on Mar 28, 2010 12:00 AM by BJ Chippindale

    dg times out waiting for bg

    BJ Chippindale Master

      The thing is, this particular discovery group is starting inside JBoss 4.2.3.GA


      It was given a startup value of 42000 (42 seconds.  JBoss is taking 90000+  ),  broadcast group is 4700.   SHOULD be OK. No?  No.


      The error occurs about 30 seconds into the server log.  Other things starting are wanting JMS and it isn't there yet.


      Shorter values seem to give similar results.   I am trying others.


      Does anyone have a feel for useful time values to use in this context?


      Earlier discovered that was not permissible in my environment.   Tried 


      However, STILL getting timeout.   Is there anything else that can possibly cause this exception?


      Coded exact IP addresses into the local-bind-address, to ensure correect IP is used for broadcast.    Listener does not have equivalent.


      Is it possibly binding ONLY to system wildcard?  I have NOT gotten this to work.


      Note that failover is not enabled for static defined cluster compels me to seek the discovery based solution.  




        • 1. Re: dg times out waiting for bg
          BJ Chippindale Master

          Other question occurs.  If failover is not defined for a CLUSTER that is statically defined, what happens to an HA pair?  Seems to me this is entirely different and ought to work.     A little reassurance on this point would not go astray.   :-)




          • 2. Re: dg times out waiting for bg
            BJ Chippindale Master

            Actually... got to wondering .... failover of what? connection?  application?  hornetq instance?    If I have  a live-backup it must fail over to the backup....  this is confusing.    Better be explicit about limitation because I am about to test it.  :-)

            • 3. Re: dg times out waiting for bg
              BJ Chippindale Master

              Tried the static cluster.  It connects nicely.  Then gives beaucoups exceptions about illegal states.  This frustrates the attempt to back out of the cluster definition.   I am told I can remove these.  If I do and I can't get back to where I was I am in deep poo.


              Which is where I apparently am anyway.



              • 4. Re: dg times out waiting for bg
                BJ Chippindale Master

                I really REALLY would like to know how to persuade HQ to simply give me a clean start.   How does one go about wiping the bindings clean so it starts over and rebuilds its internal plumbing?  


                Would this work?


                1. Make a bare all-with-hornetq profile.
                2. Alter the hornetq.sar of the bare profile to match the desired target profile 
                3. Start JBoss aimed at the bare profile.
                4. Stop JBoss
                5. copy the data directory of the target profile someplace (just in case).
                6. copy the data directory of the bare profile over to the target.


                Too complicated.  Could just copy the data directory from before I start JBoss at all?  Would be much simpler if it would work.




                • 5. Re: dg times out waiting for bg
                  BJ Chippindale Master

                  This DOES NOT WORK.  Nor given the manner of its failing, do I expect any variation, including a standalone HQ installation to do better at changing profiles.


                  Basically it is a JBoss problem.  JBoss takes the installed messaging system (whatever it is) and builds up several internal queues for its "postoffice".


                  These queues are unique to the profile you just built and if you change your clustering configuration, the hanging postoffice queues are simply not defined anymore.    The defined postoffice queues are held in the JBoss DB,  not in any local datastore.    If there is a place where I can wipe them and I find it, I might answer this question myself, but it is not possible to do through hornetq facilities.


                  Which makes this process very linear.  You must settle on your clustering definitions and your usage before you start putting anything into your Appserver.


                  ...or you are going to have to reinstall everything when you change your mind.




                  • 6. Re: dg times out waiting for bg
                    BJ Chippindale Master



                    No problem with Hornetq except for the apparent inability to bind discovery to the correct nic or all nics.  I see it listening on the right port.


                    Tested  multicast on the target systems.  Used simple test program. was blocked. was OK.   Used


                    Test program set NIC to use on both send AND receive as dual-homed system is not well suited for our use.


                    In JBoss discovery worked but only with command line intervention.  Binding to force broadcast to use proper nic is hard to achieve else. 


                    In Hornetq it did NOT work.  At no time did it come close with dual-homed environment and eth1 needing to be used ---- Static clustering did work. 


                    The apparent difficulty is that there is no way to set a local-bind-address on the discovery-group as it is set on the broadcast group.  If there is I have not found it.  I think it is not there.


                    Hornetq has clustered successfully using discovery in all single-homed tests.


                    It also clusters successfully statically in this environment. 


                    No problems with either.




                    Now the nasty part.   Once used in a cluster internally in JBoss, there are JBoss queues created for the JBoss postoffice functions.  These connections are stored in the DB and are not accessible.  Changing the name of the JBoss cluster and altering the configurations does NOT seem to cause them to disappear.  They are bound in some way to the clustered profile and at this point have not been capable of being removed or altered.   If I find a way I will post it.


                    This is possibly not true of JBoss-Messaging based solutions for JBoss, though the inference is weak.  


                    The question arises whether an external standalone Hornetq will have the same queues created or whether it will use internal JMS hooks to manage changes and ignore the external messaging  (unknown to me at present).    


                    All testing conducted on a JBoss-4.2.3.GA system.