1 2 Previous Next 27 Replies Latest reply on Feb 11, 2009 12:29 AM by konami

    MQ migration help

    tnine

      Hi all,
      I'm upgrading our processing cluster from AS 4.0.5 to AS 4.2.2. Part of this upgrade includes a migration from JBoss MQ to JBoss Messaging. I have some questions regarding HA and data sources.

      In our current MQ installation, we have left the DefaultDS as the HSQL DB and created an MQ data source using a MySQL XA connection. Which of the following is the most commonly accepted and cleanest with JBoss Messaging?

      1. Change the DefaultDS to use MySQL XA connections. Can more than 1 node share the same database on MySQL if I set up the DefaultDS to point to the same database across all nodes?


      2. Define a new Datasource and point each node to the same database.

      All databases will be in MySQL cluster.


      Second, I've had some flakiness using Spring's JMSTemplate with MQ when the system is under heavy load. Most of the queue inputs come from POJO clients that partition 2 GB plus flat files into Threadpools and queue the partitions concurrently. This wiki article outlines the issues

      http://wiki.jboss.org/wiki/JBMSpringJMSTemplateNotes

      However, it doesn't point to a good way to connect from POJO clients outside the container. Can anyone point me to an article so that I can implement a JBoss "approved" JMSTemplate with connection pooling? These client queues will need to be XA compatible.


      Thanks,
      Todd[/url]

        • 1. Re: MQ migration help
          clebert.suconic

           


          1. Change the DefaultDS to use MySQL XA connections. Can more than 1 node share the same database on MySQL if I set up the DefaultDS to point to the same database across all nodes?



          You actually need a shared database across the nodes to guarantee a proper failover. You don't need XA on the Database though... just simple transactions. When you open a jms.Connection in XA mode we already control our transactions to the database.


          2. Define a new Datasource and point each node to the same database.

          All databases will be in MySQL cluster.


          Same as above, right?


          http://wiki.jboss.org/wiki/JBMSpringJMSTemplateNotes

          However, it doesn't point to a good way to connect from POJO clients outside the container. Can anyone point me to an article so that I can implement a JBoss "approved" JMSTemplate with connection pooling? These client queues will need to be XA compatible.




          Well.. IMO that is a Spring issue. You definitely need to reuse your connections. Creating a new connection on every message receive is not practical with any JMS provider. You'd better finding help on Spring guys.

          • 2. Re: MQ migration help
            tnine

            Thanks for the help. I've hit a bit of a snag, and I've found the solution. I changed the default datasource to use MySQL. Whenever I started jboss, I received this error

            2008-04-16 09:02:40,752 DEBUG [org.jboss.messaging.core.impl.JDBCSupport] Failed to execute: CREATE TABLE JBM_POSTOFFICE (POSTOFFICE_NAME VARCHAR(255), NODE_ID INTEGER,QUEUE_NAME VARCHAR(255), CONDITION VARCHAR(1023), SELECTOR VARCHAR(1023), CHANNEL_ID BIGINT, CLUSTERED CHAR(1), ALL_NODES CHAR(1), PRIMARY KEY(POSTOFFICE_NAME, NODE_ID, QUEUE_NAME))
            com.mysql.jdbc.exceptions.MySQLSyntaxErrorException: You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near 'CONDITION VARCHAR(1023), SELECTOR VARCHAR(1023), CHANNEL_ID BIGINT, CLUSTERED CH' at line 1


            It appears that in mysql 5.0, some of the column names are reserved keywords or functions. I fixed it by manually escaping all the column names and executing the SQL myself.

            CREATE TABLE JBM_POSTOFFICE (`POSTOFFICE_NAME` VARCHAR(255), `NODE_ID` INTEGER,`QUEUE_NAME` VARCHAR(255), `CONDITION` VARCHAR(1023), `SELECTOR` VARCHAR(1023), `CHANNEL_ID` BIGINT, `CLUSTERED` CHAR(1), `ALL_NODES` CHAR(1), PRIMARY KEY(POSTOFFICE_NAME, NODE_ID, QUEUE_NAME))
            


            This will be a pain when we start deploying this to different servers. Is there a configuration file somehwere I can change the create SQL?

            • 3. Re: MQ migration help
              tnine

              Also, its creating all tables using the MyISAM engine. MySQL doesn't support transactions in MyISAM tables.

              http://dev.mysql.com/doc/refman/5.0/en/ansi-diff-transactions.html

              I had to use the ALTER TABLE command to set the engine to InnoDB. My default storange engine is InnoDB. Should the create SQL set the storage engine?

              • 4. Re: MQ migration help
                clebert.suconic

                I mean no harm... But you should read the manual ! :-)

                You need to replace the persistence manager by the mysql-persistence version. Look at docs

                • 5. Re: MQ migration help
                  clebert.suconic

                  Just to complete my last post... On the zip distribution files there is a directory for each persistence-manager, for several databases. We test those extensively on every release.

                  Look under ./zip-file/examples/config

                  • 6. Re: MQ migration help
                    tnine

                    No offense taken. A read the manual response is an appropriate one, however I wasn't clear on exactly which doc I need to read. I've changed the default data source to use our MySQL cluster for all of JBoss. In the JBoss AS documentation, it simply defines the default source as MySQL, and doesn't mention any further changes. I'm assuming that I need to re-configure jboss messaging on top of changing the default data source as outlined here?

                    http://www.jboss.org/file-access/default/members/jbossmessaging/freezone/docs/userguide-1.4.0.SP3/html/configuration.html#conf.persistencemanager

                    I apologize for the obvious questions, but I couldn't find anything in the AS doc that references the Messaging configuration change. I thought changing the data source was all that is required. I also don't have the example files described in the doc for persistence. Only the "null-persistence-service.xml" file. I created my installation from the 1.2.1 JEMS installer, does it not install alternative configuration files?

                    • 7. Re: MQ migration help
                      clebert.suconic

                      I don't know how that's on the JEMS installer.


                      I believe the JEMS installer will only install the JBossMQ? I remember we talking about possibly having the installer replacing JBossMessaging automatically for us, but I don't think that ever happened.

                      If it did actually, you should be careful as it will be probably an old version.


                      So.. I don't know if you will have the alternative files on the JEMS installer, but you will for sure find them on the latest downloads:

                      http://www.jboss.org/jbossmessaging/downloads/

                      • 8. Re: MQ migration help
                        tnine

                        Thanks for the help. I was able to successfully get everything on the server side running by using the settings below. Hopefully this will help someone else out who reads this post. Now I'm hitting another issue. We use Maven 2 to perform our builds, and my dependencies are no longer valid now that we've migrated to 4.2.2. I'm trying to use the maven 2jboss repository

                        http://repository.jboss.com/maven2/

                        but I can't seem to find the messaging dependencies with the correct version. I'm using this doc

                        http://www.jboss.org/file-access/default/members/jbossmessaging/freezone/docs/userguide-1.4.0.SP3/html/installation.html#inst.remoteclient

                        as a guide on what dependencies I need. Do I need to deploy the artifacts from my application server and the linked URLS to my local repository, or can I find the version somewhere on the repository?

                        Thanks,
                        Todd

                        Steps to migrate DefaultDS to MySQL and set up messaging.


                        1. Download the latest MySQL client jar and put it in server/lib
                        2. Set up the following in a mysql-ds.xml file, and remove the hsqldb-ds.xml file


                          <datasources>
                           <local-tx-datasource>
                           <jndi-name>DefaultDS</jndi-name>
                           <connection-url>
                           jdbc:mysql://localhost:3306/jboss
                           </connection-url>
                           <driver-class>com.mysql.jdbc.Driver</driver-class>
                           <user-name>jboss</user-name>
                           <password>password</password>
                           <exception-sorter-class-name>
                           org.jboss.resource.adapter.jdbc.vendor.MySQLExceptionSorter
                           </exception-sorter-class-name>
                           <metadata>
                           <type-mapping>mySQL</type-mapping>
                           </metadata>
                           <!-- Required for Messaging to work correctly -->
                           <transaction-isolation>
                           TRANSACTION_READ_COMMITTED
                           </transaction-isolation>
                           </local-tx-datasource>
                          
                          </datasources>
                          


                        3. Download the messaging distribution that has the same version as the one in your application server. For the JEMS 1.2.1.CR4 installer, I installed messaging version 1.4.0.SP3 (build: CVSTag=JBossMessaging_1_4_0_
                          SP3 date=200712131418)

                        4. Copy mysql-persistence-service.xml from examples/config of your messaging download to server/deploy/jboss-messaging.sar, and either delete or rename hsqldb-persistence-service.xml.bak

                        5. Restart the server, and everything should work!


                        • 9. Re: MQ migration help
                          clebert.suconic

                          Well.. i don't know if I can help you with Maven... We are just not maven guys .

                          You might find help on the JBossAS user's forum.

                          Regarding your instructions... I should pointed you to this WIKI right away:

                          http://wiki.jboss.org/wiki/MQMessageMigration


                          If you find something missing maybe you could complete it. (it's a better way to share information among other users)

                          • 10. Re: MQ migration help
                            tnine

                            Thanks for the help again. I've given up on the JEMS version of JBoss. I was getting very strange serialization issues. As soon as I installed messaging to the "all" server from the 4.2.2GA download and configured the data sources everything started working. Note that I couldn't use the jbossall-client.jar as outlined in the doc, since it conflicted with my version of Hibernate. Would it be possible to list each specific client jar in the doc? I have my client working, but it was a guess and check on the jar files, and I want to be sure I have everything I need.

                            I'm was also having a bit of a performance issue. When I was using MQ, I could queue up my messages very quickly. My messages are object messages, and they're quite large, between 16k up to 40k (so far). With JBoss MQ I could queue around 500 messages a minute with our current POJO client. With JBoss messaging and the default queues, it takes about 10 minutes to queue 500 messages, then hangs at around 570 messages. I though this may be due to my queue configuration and paging given the large message size. I lowered the memory storage and paging quite a bit, which appears to have fixed my issue. Is this a valid fix, or is there a better way to handle large messages?

                            Settings
                            Data Source: DefaultDS
                            Database Type: MySQL (InnoDB Tables)
                            Connection Info: java.naming.provider.url=jnp://localhost:1100
                            Connection Factory JNDI Location: ClusteredXAConnectionFactory

                            destinations-service.xml

                            
                             <!-- Input Queue for statements -->
                             <mbean code="org.jboss.jms.server.destination.QueueService"
                             name="jboss.messaging.destination:service=Queue,name=StatementInput"
                             xmbean-dd="xmdesc/Queue-xmbean.xml">
                             <depends optional-attribute-name="ServerPeer">
                             jboss.messaging:service=ServerPeer
                             </depends>
                             <depends>jboss.messaging:service=PostOffice</depends>
                             <attribute name="DLQ">
                             jboss.messaging.destination:service=Queue,name=StatementDLQ
                             </attribute>
                             <attribute name="Clustered">true</attribute>
                             <attribute name="MaxDeliveryAttempts">2</attribute>
                             <attribute name="FullSize">100</attribute>
                             <attribute name="PageSize">50</attribute>
                             <attribute name="DownCacheSize">50</attribute>
                            
                             </mbean>
                            
                             <mbean code="org.jboss.jms.server.destination.QueueService"
                             name="jboss.messaging.destination:service=Queue,name=StatementOutput"
                             xmbean-dd="xmdesc/Queue-xmbean.xml">
                             <depends optional-attribute-name="ServerPeer">
                             jboss.messaging:service=ServerPeer
                             </depends>
                             <depends>jboss.messaging:service=PostOffice</depends>
                             <attribute name="DLQ">
                             jboss.messaging.destination:service=Queue,name=StatementDLQ
                             </attribute>
                             <attribute name="Clustered">true</attribute>
                             <attribute name="FullSize">100</attribute>
                             <attribute name="PageSize">50</attribute>
                             <attribute name="DownCacheSize">50</attribute>
                             </mbean>
                            
                            
                             <!-- DLQ for statements -->
                             <mbean code="org.jboss.jms.server.destination.QueueService"
                             name="jboss.messaging.destination:service=Queue,name=StatementDLQ"
                             xmbean-dd="xmdesc/Queue-xmbean.xml">
                             <depends optional-attribute-name="ServerPeer">
                             jboss.messaging:service=ServerPeer
                             </depends>
                             <depends>jboss.messaging:service=PostOffice</depends>
                             <attribute name="Clustered">true</attribute>
                             <attribute name="FullSize">100</attribute>
                             <attribute name="PageSize">50</attribute>
                             <attribute name="DownCacheSize">50</attribute>
                             </mbean>
                            



                            Thanks,
                            Todd

                            • 11. Re: MQ migration help
                              tnine

                              Sorry, hit the submit button a bit too quickly. Anyway, with this new config I get this error from the client at around 5000 messages queued, then my client dies

                              2008-04-17 17:26:20,647 WARN [org.jboss.remoting.LeasePinger] - <LeasePinger[SocketClientInvoker[9315af, bisocket://127.0.0.1:4457](aa12t-uel02u-ff4vp9h3-1-ff4vpd4g-e)] failed to ping to server: Java heap space>
                              2008-04-17 17:26:21,009 WARN [org.jboss.remoting.LeasePinger] - <LeasePinger[SocketClientInvoker[9315af, bisocket://127.0.0.1:4457](aa12t-uel02u-ff4vp9h3-1-ff4vpd4g-e)] failed to ping to server: Java heap space>
                              


                              What does this error message mean?

                              • 12. Re: MQ migration help
                                clebert.suconic

                                Messages stay on the client until you commit them. If you need this number of messages on the client side, you should increase your memory.

                                this is being changed on JBM 2.


                                Regarding the client JARs.. look at docs.

                                • 13. Re: MQ migration help
                                  tnine

                                  I've used this doc on jars required by the client.

                                  http://www.jboss.org/file-access/default/members/jbossmessaging/freezone/docs/userguide-1.4.0.SP3/html/installation.html#inst.remoteclient

                                  as I said earlier, I can't use jbossall-client.jar. I need the individual jars that have the same classes, but without the hibernate dependencies as this causes version errors with my data access module.

                                  As far as the transactions, I'm committing each message in its own XA transaction. Its queued, and the audit record is written to the db. I can see the data in the db when I query, so I know my transaction is committed with each queue operation. Is it possible I have too many open connections, which is why the client crashes?

                                  • 14. Re: MQ migration help
                                    clebert.suconic

                                    Here is a list from our build-thirdparty


                                     <componentref name="retrotranslator" version="0.9.6jboss"/>
                                     <componentref name="sun-javacc" version="3.2-brew"/>
                                     <componentref name="oswego-concurrent" version="1.3.4.patch01-brew"/>
                                     <componentref name="apache-log4j" version="1.2.14-brew"/>
                                     <componentref name="javassist" version="3.5.0.GA-brew"/>
                                     <componentref name="jgroups" version="2.4.2.GA_CP01-brew"/>
                                     <componentref name="trove" version="1.0.2-brew"/>
                                     <componentref name="jboss/common" version="1.2.1.GA-brew"/>
                                     <componentref name="jboss/aop" version="1.5.5.GA_CP01-brew"/>
                                     <componentref name="jboss/remoting" version="2.2.2.SP7-brew"/>
                                     <componentref name="jboss/jbossts14" version="4.2.3.SP5_CP01-brew"/>
                                     <componentref name="jbossas/core-libs" version="4.2.0.GA"/>
                                    
                                    


                                    As for core-libs, consider whatever is necessary to locate a JNDI.


                                    As for the exception.. I'm not really sure what you're doing.

                                    An easy way would be to use a kill -3, using a Histogram, as I have described here:

                                    http://wiki.jboss.org/wiki/StackTrace



                                    1 2 Previous Next