1 2 3 4 Previous Next 47 Replies Latest reply on Mar 29, 2010 12:45 AM by clebert.suconic

    Configuration storage

    clebert.suconic

      So far the requirements I got is we should be able  to persist configuration for :

       

      - Connection Factories

      - JMS Queues

      - JMS Topics

      - Address Settings

      - Security Settings

       

      I think we could also optionally include:

      - Diverts

      - Bridges

       

       

      Instead of doing a JMS Journal, I'm considering implementing what I call a ConfigurationManager, that will persist any kind of configuration you want.

       

       

      Each config item we have would be represented by ConfigurationItem, with these attributes:

       

       

         private final SimpleString type;
       
         private final SimpleString key;
         /** The id for the configuration item on the journal */
         private volatile long journalID;
         /**
          * This represents the config before parsing and storing
          * It will be empty after parsed or stored.
          */
         private byte[] data;
       
         /** this presents the config after being parsed */
         private Object configValue;
      
      
      

       

       

      The ConfigurationManager would look like this interface:

       

      public interface ConfigurationManager
      {
           void storeItem(ConfigItem item);
           
           void deleteItem(SimpleString type, SimpleString key);
           
           void deleteItem(ConfigItem item);
           
           ConfigItem[] recoverItems();
           
           ConfigItem[] recoverItems(SimpleString type);
      }
      
       
      

       

       

      For example, JMSManager would store the configs as new items are stored.

       

      Same deal with hornetQServer. it would store configs as new security settings are stored.

       

      On load time, JMSManager would be able to recoverItems by type, and the JMSManager would be able to recreate the queues and JMS connection factories.

       

      with this we could keep any configuration persisted.. and it would be about the same ammount of time to develop as a plain JMS Storage manager.

        • 1. Re: Configuration storage
          timfox

          The only requirements I know of are persisting JMS queues and topics, where did these other requirements come from?

           

          Andy- I would like to see your input here, as these requirements come from the console work.

          • 2. Re: Configuration storage
            clebert.suconic

            As far as I know, we should be able to persist security settings, connection factories and address settings as well.

            • 3. Re: Configuration storage
              clebert.suconic

              > where did these other requirements come from?

               

              The console admin is for instance managing connection factories. They should be persisted for example.

               

               

              Anything done through the admin console should be persisted. We may decide to cut some of the persistence now.. but that means.. we will have to do it later.

              • 4. Re: Configuration storage
                timfox

                It's all very well saying that you think that we should persist X, Y and Z.

                 

                But without providing any reasoning as to why you think that, your statement is really rather pointless.

                 

                I may as well say "I like cheese". Well, thanks for that.

                • 5. Re: Configuration storage
                  timfox

                  Clebert Suconic wrote:

                   

                  > where did these other requirements come from?

                   

                  The console admin is for instance managing connection factories. They should be persisted for example.

                   

                   

                  Anything done through the admin console should be persisted. We may decide to cut some of the persistence now.. but that means.. we will have to do it later.

                  Well, that's not what I have been told on the latest updates.

                   

                  If it's changed, it needs to be discussed. Right now I am working on the basis it's just JMS queues and topics.

                  • 6. Re: Configuration storage
                    clebert.suconic

                    If you look at the attachments on Andy's message:

                     

                    http://community.jboss.org/message/532433#532433

                     

                     

                    He's managing address settings & security settings.

                     

                     

                    I could just do it alltogether around Queue names, but I don't think that's the proper way of doing it.

                     

                    I know for instance we need to persist Connection Factories. If I provide a generic way now, it could be easily reused later, while the development time would be the same here.

                    • 7. Re: Configuration storage
                      leosbitto

                      As an aministrator, I would be significantly diappointed if I would lose anything which I would configure through the administration console! Every other JMS provider I have approached offers the possibility to persist the online configuration changes, which I consider to be an essential feature (still missing in HornetQ, sadly though).

                      • 8. Re: Configuration storage
                        timfox

                        Can you be more specific about what is "missing" ?

                        • 9. Re: Configuration storage
                          leosbitto

                          I miss the possibility to persist all the configuration changes made through any online configuration interfaces (like the JMX console in 2.0.0.GA for example) to get the consistent behaviour after the restart.

                          • 10. Re: Configuration storage
                            timfox

                            I'm looking for a specific list of what is missing.

                            • 11. Re: Configuration storage
                              timfox

                              Clebert Suconic wrote:

                               

                              If you look at the attachments on Andy's message:

                               

                              http://community.jboss.org/message/532433#532433

                               

                               

                              He's managing address settings & security settings.

                               

                               

                              I could just do it alltogether around Queue names, but I don't think that's the proper way of doing it.

                               

                              I know for instance we need to persist Connection Factories. If I provide a generic way now, it could be easily reused later, while the development time would be the same here.

                              I expected it to be done by the end of yesterday. This should be a two hour copy and paste job. Maybe quicker for you since you are familiar with the journal.

                               

                              Looks like all we got after one day is an email outlining how to do this

                              • 12. Re: Configuration storage
                                ataylor

                                We need to persist the following:

                                 

                                JMS Queue

                                JMS Topic

                                JMS COnnection Factories

                                 

                                However since the user must be able to configure things on the destinations we need to persist Address Settings and Security Settings as well so on restart the queues are configured the same.

                                 

                                Have a look at the attached screen shot of configuring a new Queue Resource via the admin console and you will see.

                                • 13. Re: Configuration storage
                                  timfox

                                  Address settings and security settings go in core, not the jms server.

                                   

                                  Also, I'd like to understand how this works together with xml config.

                                   

                                  What takes precedence? Xml or store? Can they work together? If so, how?

                                  • 14. Re: Configuration storage
                                    ataylor

                                    This was discussed at the F2F and agreed on by every one, when the user creates a new destination they should be able to configure settings and security at the point the queue is created. Exactly like the screen shot shows.

                                     

                                    Persistence ill take priority over xml config.

                                     

                                    fyi, the admin console will only have JMS objects for this version.

                                    1 2 3 4 Previous Next