1 2 Previous Next 29 Replies Latest reply on Sep 24, 2012 12:15 PM by mazz

    Does HornetQ support JBBC persistence

    raja021084

      Hi All,

      I want to use JDBC persistence for High Availability. Does hornetQ supports JDBC persistence?

        • 1. Re: Does HornetQ support JBBC persistence
          ataylor

          raja murugesan wrote:

           

          Hi All,

          I want to use JDBC persistence for High Availability. Does hornetQ supports JDBC persistence?

          No, there's not really any reason for us to support it. IS there a reason u can't use the journal?

          • 2. Re: Does HornetQ support JBBC persistence
            raja021084

            Actually we are migrating from JBoss 4.2 to JBoss 5.1. In 4.1, We used JBoss Messaging Server which supports JDBC Persistence. In 5.1 we want to use HornetQ because JBoss Messaging Server is depricated. We are yet to explore journel. Is journel support all the features supported by JDBC persistence with respect to High Availability, Clustering and Fail Over ?

            • 3. Re: Does HornetQ support JBBC persistence
              ataylor

              raja murugesan wrote:

               

              Actually we are migrating from JBoss 4.2 to JBoss 5.1. In 4.1, We used JBoss Messaging Server which supports JDBC Persistence. In 5.1 we want to use HornetQ because JBoss Messaging Server is depricated. We are yet to explore journel. Is journel support all the features supported by JDBC persistence with respect to High Availability, Clustering and Fail Over ?

              HornetQ supports high availibilty, clustering and failover and the journal is part of HornetQ

              • 4. Re: Does HornetQ support JBBC persistence
                dchilders

                This blows my mind.

                 

                Obviously your very proud of Journal and it sounds like a lot of work has been put into making it very fast on spindle based drives.  But it seams to me that your missing the bigger picture here.

                 

                First, everywhere that I have worked the app tier is almost never built to the same level of redundancy and failover as the database.  In fact we don't even typically have clustered drives mounted to the app tier at all.  Nothing all that important is stored there and as such its just not needed.  The database is where all the money is spent on redundancy and failover.

                 

                Second, after reading about Journal I'm amazed at the amount of thought and work it sounds like went it a software design that optimizes access to spindle based harddrives which will be dead and gone over the next few years.  We're seeing it start this year but by next year datacenters everywhere will begin moving away from spindle drives and over to ssd's where seek time and read head movements all go out the window.

                 

                Maybe I'm missing something here but this really seams like a mistake.  I for one am trying to figure out how to migrate from a JBoss 4.2.3 server using oracle backed queue's to JBoss 6 M4.  At face value this is a deal killer.  There are still options but it means I have to first find a production server with spare capacity and clustered drives that I can move my queue'ing to.  Then I'll have to re-architectect my app to use a remote queue.  Re-architectect may be a bit strong but its definitly more work that we expected.

                • 5. Re: Does HornetQ support JBBC persistence
                  clebert.suconic

                  This blows my mind.

                   

                  Obviously your very proud of Journal and it sounds like a lot of work has been put into making it very fast on spindle based drives.  But it seams to me that your missing the bigger picture here.

                   

                  First, everywhere that I have worked the app tier is almost never built to the same level of redundancy and failover as the database.  In fact we don't even typically have clustered drives mounted to the app tier at all.  Nothing all that important is stored there and as such its just not needed.  The database is where all the money is spent on redundancy and failover.

                   

                   

                   

                  Databases are different than messaging system. I have spend the past 5 years designing messaging systems, and 10 years prior to that on designing DB applications, and I can ensure you that Database are really slow and will attack a different type of problem. They are good on indexing and recovering information, but really slow on appending data and guaranteeing syncs.

                   

                  We could use of course the Database as a storage media, but that doesn't give you anything. In a messaging system we use a lot of blogs, what that means.. the DB is not really being used a relational database... In other words, the DB is not giving you any features.

                   

                  Second, after reading about Journal I'm amazed at the amount of thought and work it sounds like went it a software design that optimizes access to spindle based harddrives which will be dead and gone over the next few years.  We're seeing it start this year but by next year datacenters everywhere will begin moving away from spindle drives and over to ssd's where seek time and read head movements all go out the wind

                   

                   

                  The work was done on making sure the data is sync on disk. SD disk may be very fast but still we can't deliver any message until it was persisted on the storage. All the work still valid.

                   

                   

                  Maybe it will be obsolete the day that RAMs are gone.. and every memory access is persistent like SDs... until then we still need to guarantee syncs before delivery.

                   

                   

                   

                   

                  Maybe I'm missing something here but this really seams like a mistake.  I for one am trying to figure out how to migrate from a JBoss 4.2.3 server using oracle backed queue's to JBoss 6 M4.  At face value this is a deal killer.  There are still options but it means I have to first find a production server with spare capacity and clustered drives that I can move my queue'ing to.  Then I'll have to re-architectect my app to use a remote queue.  Re-architectect may be a bit strong but its definitly more work that we expected.

                   

                  I agree that migrate from JBoss MQ or JBoss Messaging is not automatic... but even if we were supporting DBs on HornetQ, the DataModel and storage would be totally different. That means you would still have issues on migrating from one DB to another.

                   

                   

                  Finally: It would be possible to write a DBStorageManager.. .however I don't think we want to maintain it.  We may consider if someone finds a real reason besides I want it. (Failover and HA are not.. since we support replicate the journal, and you still need another HornetQ instance to perform Failover. Failover and HA are features to the Messaging system, not to the DB system).

                  • 6. Re: Does HornetQ support JBBC persistence
                    clebert.suconic
                    Maybe it will be obsolete the day that RAMs are gone.. and every memory access is persistent like SDs... until then we still need to guarantee syncs before delivery.

                     

                    Ah... Databases will be also obsolete on that day :-)

                    • 7. Re: Does HornetQ support JBBC persistence
                      thunder.farmer

                      one maybe minor reason for relational DB: If messages are stored in DB, it's a little convenient to look at and manipulate during failure.

                      Does HornetQ provide any tool to check the raw message in journal persistence?

                      • 8. Re: Does HornetQ support JBBC persistence
                        clebert.suconic

                        >> "one maybe minor reason for relational DB: If messages are stored in DB, it's a little convenient to look at and manipulate during failure."

                         

                         

                        Actually this is not true... To achieve performance we keep everything in blobs.. so at this point the DB is as a black box as any other journal.

                         

                        (well.. the best possible performance, as databases are slooooow for messaging systems or any ultra fast processing you need)

                         

                        >> "Does HornetQ provide any tool to check the raw message in journal persistence?"

                         

                        Yep: look at the export/import tool:

                         

                        http://hornetq.sourceforge.net/docs/hornetq-2.1.2.Final/user-manual/en/html/persistence.html#persistence.importexport

                        1 of 1 people found this helpful
                        • 9. Re: Does HornetQ support JBBC persistence
                          clebert.suconic

                          To achieve performance we keep everything in blobs.

                           

                           

                          I meant: we would keep everything in blobs.

                           

                           

                          That's how we do it on JBoss Messaging. JBoss MQ does the same.

                           

                           

                          All the competitors I know will also do the same kind of thing with blobs.

                          • 10. Re: Does HornetQ support JBBC persistence
                            clebert.suconic

                            And besides the journal is not a black box at all.. that was just a wrong expression.

                             

                             

                            The export/import tool makes its use very clear. Probably better than what you would get from a database for this end.

                            • 11. Re: Does HornetQ support JBBC persistence
                              thunder.farmer

                              That's great...

                              • 12. Re: Does HornetQ support JBBC persistence
                                raja021084

                                Thanks for great explanation.

                                • 13. Re: Does HornetQ support JBBC persistence
                                  dhcavalcanti

                                  I can give you a simple reason. Not every project will have a SAN available to setup the shared store.

                                  In those cases, a DB is better than NAS.

                                   

                                  I do agree with you that a DB shared storage is slower, but for some applications that is an acceptable proposition.

                                  Furthermore, there are some faster DB in the market today: VoltDB. Granted, they are in mem replicated DBs, so if all instances go down, you will lose the data. But again, if architected right, the risk of complete failure may be acceptable.

                                  • 14. Re: Does HornetQ support JBBC persistence
                                    gaohoward

                                    One thing I'd suggest is to make the journal system pluggable so that HornetQ can support as many shared store as it wants. (including JDBC). How about you go ahead and raise a feature request Jira?

                                    1 2 Previous Next