8 Replies Latest reply on Sep 20, 2006 10:52 PM by gohip

    The actual physical location of Message Queue data...

    gohip

      Hi kids, In testing the JBoss mail servers, I have been going back and forth between different machines, as well as different OS's. During this testing, I have found out that the Message Queue Data, is persisted between restarts (which I hear is configurable), and can even be copied to another server(by copying the whole mail server folder to another box (yes, with a couple modifications a windows mail server folder was copied to Fedora Core 5 server, and run successfully)), but now, I have an environment set up on windows, and one on Fedora. I would just like to copy the queue data, from the windows box, to the Fedora box, without copying the whole mail server folder...

      But I cannot find this data anywhere, I perused through the seemingly applicable folders, and can not find it, i tried searching the folders, and seraching the folders file data for a known email that was put in the store, to no avail(imagine it's base64 encoded).

      Anyone have any ideas where I can find the file/folder that stores the MQ data between restarts?

        • 1. Re: The actual physical location of Message Queue data...
          sappenin

          What kind of JMS persistency are you using? Does your JMS use your Mysql/postgre database? If so, the MQ messages are stored in the "JMS_MESSAGES" table in the database. If you're using Hypersonic (for your JMS), then I'm not sure where that gets persisted (seems like it would just go away since Hypersonic is an in-memory DB) (?)

          • 2. Re: The actual physical location of Message Queue data...
            acoliver

            Unless you change it then the default install of JBCS sets up to use hypersonic. This is kinda bad sorta... since the jms messages don't stay there long and they only have headers it may not be a big deal. I'd probably switch it myself but not sure if it makes sense to do so at installation. The wiki has instructions on how to change this.

            • 3. Re: The actual physical location of Message Queue data...
              gohip

              Thanks Guys for the response, I am using M4 with mySQL. I didnt think they were stored in the database...there's currently 70messages, on an external self created queue, lemme look at the dbase as I never saw such a table before...

              That doesnt make sense, from what I have seen...In the past, If I wanted to parse and delete the files on the external queue, I would make a copy of the Mail servers directory, not the mySql directory, parse and delete them, then to restore the queued emails after, I would restore the backed up mail server directory, this had the effect of restoring the queued emails.

              it doesnt jive with what you guys said, but maybe thats in M5.

              In M4, after looking at the mysql tables, this is all i see...

              +--------------------------+
              | Tables_in_app_user_email |
              +--------------------------+
              | alias |
              | blob_mail_store |
              | folder |
              | lock_table |
              | messagedata |
              | paged_mail_store |
              | paged_mail_store_pages |
              | storeitemmetadata |
              +--------------------------+

              • 4. Re: The actual physical location of Message Queue data...
                sappenin

                Yeah, it looks like you're still using the defualt JMS storage location, which is Hypersonic -- otherwise you'd have some mysql tables whose names start with "JMS".

                Since you don't have those tables, I'm guessing your config of JBCS is storing MAIL messages and data in mysql, but JMS messages (like MessageData info to deliver messages into various mailboxes -- essentially mail header info used for internal processing directives) are stored in message queues backed by HSQL/Hypersonic.

                Anyway, if you change your JMS to use MySql (or, even better, PostgreSQL), then all of the queue data will get stored in the database. The tablenames will be JMS_MESSAGES, JMS_USERS, JMS_ROLES, etc.

                If you're just testing JBCS, then there's not much of a need to make the switch to a real database for the message queues. However, I would suggest making the switch for anything else. It will mimic a real world setup, and you won't have to worry about where this data is being stored if you move JBCS from one server to another.

                In regards to your initial question, I don't use HSQL, so I can't comment on where it stores its data, or in what files.

                Thanks!
                David

                • 5. Re: The actual physical location of Message Queue data...
                  osterday

                  The hypersonic data is stored in the jboss/server/default/data/hypersonic directory. If the queue is not processed, you can copy the data by copying the files to another jboss install - freaked me out a bit when I accidentally did this!

                  • 6. Re: The actual physical location of Message Queue data...
                    acoliver

                    but you really should switch OFF of hypersonic if/when going to production. See the wiki for details as to how.

                    • 7. Re: The actual physical location of Message Queue data...
                      osterday

                      Yup, I know I need to switch off hypersonic - just lazy right now!

                      Thanks for the reminder, though!

                      • 8. Re: The actual physical location of Message Queue data...
                        gohip

                        Thanks guys for the insight, I appreciate it.

                        I'll look at the Wiki, and yes, it freaked me out to, when I read Sappenins comment, as I hadnt seen anything in the dbase, and at at least one point, had just killed the java process and the data still persisted, then I read osterday's...and it brought me back down to my senses.

                        Again, Thanks