1 2 Previous Next 22 Replies Latest reply on Oct 13, 2010 5:51 PM by clebert.suconic Go to original post
      • 15. Re: Lazy journal creation and journal-min-files
        jason.greene

        Yeah you have a good point. Having 0 journal files by default, and lazily creating them sounds like the best solution.

         

        On a side topic, is there a reason that the journal is scanned each individual byte, and is not a record format? I assume you are looking for corruption, but wouldnt that be a fallback strategy?

        • 16. Re: Lazy journal creation and journal-min-files
          jason.greene

          Jason Greene wrote:

           

          Yeah you have a good point. Having 0 journal files by default, and lazily creating them sounds like the best solution.

           

          On a side topic, is there a reason that the journal is scanned each individual byte, and is not a record format? I assume you are looking for corruption, but wouldnt that be a fallback strategy?

          Actually that should be each individual byte multiple times.

          • 17. Re: Lazy journal creation and journal-min-files
            clebert.suconic

            We are talking about a profile target at developer's, not production.

             

            You can't deliver a production site with NullPersistence. But that's ok (and I actually think it's better for the developer)

             

            You are rulling by the exception. Most developers will cleanup their journal data each time they restart the server, as they usually start fresh on each startup. And developers can of course change it to be persistent if they need.

            • 18. Re: Lazy journal creation and journal-min-files
              clebert.suconic

              we don't cleanup the files on each reuse. So, we always need to scan the files for all the valid records.

               

              when the file is reused, all we do is to change the header's file ID to a new file, and each record has that ID. We need to scan for all the valid records on startup.

               

               

              I talked to Dmlloyd yesterday night though. I can improve it a bit, and I have created a JIRA for it.

               

              https://jira.jboss.org/browse/HORNETQ-550

              • 19. Re: Lazy journal creation and journal-min-files
                clebert.suconic

                So, you guys have a developer's profile now, right?

                 

                I'm assuming you have something extra in top of default.

                • 20. Re: Lazy journal creation and journal-min-files
                  dimitris

                  Jason Greene wrote:

                   

                  Yeah you have a good point. Having 0 journal files by default, and lazily creating them sounds like the best solution.

                   

                  +1

                   

                  IMO, a spec-compliant behaviour (i.e. persistence enabled) must be default, even for a developer profile.

                  • 21. Re: Lazy journal creation and journal-min-files
                    clebert.suconic

                    It's up to you guys to decide.... I think most developers always start from fresh on each startup.

                    • 22. Re: Lazy journal creation and journal-min-files
                      clebert.suconic

                      BTW that won't work...Best would be to make HornetQ lazy started upon its first connection is created.

                       

                      However, you will have to make JCA also to only init its pool on the first MDB startup.

                       

                       

                      And I can speed up the journal startup a bit.

                       

                       

                      This is kind of funny actually. JBoss Messaging used to take 20 seconds to boot up when empty and minutes when full of messages and now you guys are complaining about 1 second :-)

                       

                       

                      anyway.. we will speed up the load a bit as it's an easy fix for 2.3.

                      1 2 Previous Next