1 2 Previous Next 22 Replies Latest reply on Feb 13, 2009 7:37 AM by jbabad

    MySQL in Cluster question

      Hi,

      We're using JBoss 5.0.0.GA with it's JBM and want to use a MySQL cluster as the underlying DataSource.

      Currently we're using MySQL 5.0.51 - so the cluster is in-memory.
      What will the maximum message size that we can send. I've seen a note on the MySQL site that mentions that there's an 8K limitation on a table row in the cluster. So, question is that the JBM_MSG table stores the headers and payload as blobs and we could be sending TextMessages of 10k characters or more. Would this be a problem?

      I'm a bit puzzled as I've managed to send a 10k message through the cluster - but I'm worried whether I'm missing anything.

      I have had a bit of a trawl through the forums but couldn't see anything that quite fitted the bill.

      As a follow-on question what would be the effect if we could upgrade either to MySQL 5.1.x or possibly to MySQL NDB Cluster 6.x?

      Any help would be appreciated.

      Thanks,
      Joseph.

        • 1. Re: MySQL in Cluster question
          gaohoward

          Hi, 10k message is ok. Blobs are not store in the table as references or pointers. So 8k should be ok enough.

          JB5's messaging are tested against mysql 5.0.x, so if you upgrade, it's all st your own risk.

          • 2. Re: MySQL in Cluster question

            Hi, thanks for the response,

            10k message is ok. Blobs are not store in the table as references or pointers.


            Sorry, just to clarify... are you saying that blobs are not stored in the table and it's just the reference that is stored?

            Also, another silly question... but in that case how/where is the actual blob data stored?

            Also, do you know if there's a maximum message size - as I mentioned we tried 10k, but potentially we could be using 20k+?

            Thanks for you help

            • 3. Re: MySQL in Cluster question
              ataylor

               

              Sorry, just to clarify... are you saying that blobs are not stored in the table and it's just the reference that is stored?


              The message is payload is stored as a blob in the JBM_MSG table.

              Also, do you know if there's a maximum message size - as I mentioned we tried 10k, but potentially we could be using 20k+?


              Only memory will restrict how big a message is. Also afaik mysql cluster maximum row size does not include blobs so you are ok.

              • 4. Re: MySQL in Cluster question
                gaohoward

                 

                Sorry, just to clarify... are you saying that blobs are not stored in the table and it's just the reference that is stored?


                sorry for the typo, I mean internally the database stores the blob reference/pointer to the table row, the contents of blob (which can be huge) has another location to store.


                • 5. Re: MySQL in Cluster question

                  Thanks guys for the responses.

                  Can I move the question a bit?
                  As I said we're running a JBoss Cluster using MySQL 5.0.51 as the underlying JMS data store. I'm trying to send 5000 messages (20k each) through the system - with a sender and receiver client.

                  Lets call the 2 JBoss instances Jboss1 and Jboss2 and the two MySQL data notes mysql1 and mysql2
                  Jboss1 has a datasource pointing to mysql1; Jboss2 points to mysql2.

                  My sender app is connecting to the JNDI on Jboss1 and getting a ClusteredConnectionFactory, The receiver is doing the same, but on Jboss2.

                  So, what I see is that for normal operation, messages go into the cluster via Jboss1/mysql2, but get pulled off via Jboss2/mysql2

                  But... when I sent 5000 messages in, I'm seeing 100-200 messages getting stuck and not being picked up by the receiver process.

                  Any ideas?

                  Thanks.

                  • 6. Re: MySQL in Cluster question
                    ataylor

                     

                    So, what I see is that for normal operation, messages go into the cluster via Jboss1/mysql2, but get pulled off via Jboss2/mysql2


                    yes thats correct.

                    But... when I sent 5000 messages in, I'm seeing 100-200 messages getting stuck and not being picked up by the receiver process.


                    Hmmm, have you checked the logs for any errors?

                    • 7. Re: MySQL in Cluster question
                      timfox

                      probably you have another consumer somewhere which has buffered those messages ready for consumption.

                      see prefetchsize

                      this has been discussed a lot before

                      • 8. Re: MySQL in Cluster question

                        OK, here are some errors that I'm seeing ....

                        09:44:14,178 WARN [JDBCSupport] SQLException caught, SQLState HY000 code:1296- assuming deadlock detected, try:1
                        java.sql.SQLException: Got error 266 'Time-out in NDB, probably caused by deadlock' from NDB
                         at com.mysql.jdbc.SQLError.createSQLException(SQLError.java:1055)
                         at com.mysql.jdbc.SQLError.createSQLException(SQLError.java:956)
                         at com.mysql.jdbc.MysqlIO.checkErrorPacket(MysqlIO.java:3515)
                         at com.mysql.jdbc.MysqlIO.checkErrorPacket(MysqlIO.java:3447)
                         at com.mysql.jdbc.MysqlIO.sendCommand(MysqlIO.java:1951)
                         at com.mysql.jdbc.MysqlIO.sqlQueryDirect(MysqlIO.java:2101)
                         at com.mysql.jdbc.ConnectionImpl.execSQL(ConnectionImpl.java:2554)
                         at com.mysql.jdbc.PreparedStatement.executeInternal(PreparedStatement.java:1761)
                         at com.mysql.jdbc.PreparedStatement.executeUpdate(PreparedStatement.java:2046)
                         at com.mysql.jdbc.PreparedStatement.executeUpdate(PreparedStatement.java:1964)
                         at com.mysql.jdbc.PreparedStatement.executeUpdate(PreparedStatement.java:1949)
                         at org.jboss.resource.adapter.jdbc.WrappedPreparedStatement.executeUpdate(WrappedPreparedStatement.java:365)
                         at org.jboss.messaging.core.impl.JDBCPersistenceManager.cacheID(JDBCPersistenceManager.java:1637)
                         at org.jboss.messaging.core.impl.JDBCPersistenceManager$1AddReferenceRunner.doTransaction(JDBCPersistenceManager.java:1370)
                         at org.jboss.messaging.core.impl.JDBCSupport$JDBCTxRunner2.execute(JDBCSupport.java:474)
                         at org.jboss.messaging.core.impl.JDBCSupport$JDBCTxRunner2.executeWithRetry(JDBCSupport.java:512)
                         at org.jboss.messaging.core.impl.JDBCPersistenceManager.addReference(JDBCPersistenceManager.java:1408)
                         at org.jboss.messaging.core.impl.ChannelSupport.handle(ChannelSupport.java:226)
                         at org.jboss.messaging.core.impl.postoffice.MessagingPostOffice.routeInternal(MessagingPostOffice.java:2212)
                         at org.jboss.messaging.core.impl.postoffice.MessagingPostOffice.route(MessagingPostOffice.java:499)
                         at org.jboss.jms.server.endpoint.ServerConnectionEndpoint.sendMessage(ServerConnectionEndpoint.java:755)
                         at org.jboss.jms.server.endpoint.ServerSessionEndpoint.send(ServerSessionEndpoint.java:397)
                         at org.jboss.jms.server.endpoint.advised.SessionAdvised.org$jboss$jms$server$endpoint$advised$SessionAdvised$send$aop(SessionAdvised.java:87)
                         at org.jboss.jms.server.endpoint.advised.SessionAdvised$send_7280680627620114891.invokeTarget(SessionAdvised$send_7280680627620114891.java)
                         at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:111)
                         at org.jboss.jms.server.container.SecurityAspect.handleSend(SecurityAspect.java:157)
                         at sun.reflect.GeneratedMethodAccessor283.invoke(Unknown Source)
                         at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
                         at java.lang.reflect.Method.invoke(Method.java:597)
                         at org.jboss.aop.advice.PerInstanceAdvice.invoke(PerInstanceAdvice.java:122)
                         at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
                         at org.jboss.jms.server.endpoint.advised.SessionAdvised.send(SessionAdvised.java)
                         at org.jboss.jms.wireformat.SessionSendRequest.serverInvoke(SessionSendRequest.java:95)
                         at org.jboss.jms.server.remoting.JMSServerInvocationHandler.invoke(JMSServerInvocationHandler.java:143)
                         at org.jboss.remoting.ServerInvoker.invoke(ServerInvoker.java:908)
                         at org.jboss.remoting.transport.socket.ServerThread.completeInvocation(ServerThread.java:742)
                         at org.jboss.remoting.transport.socket.ServerThread.processInvocation(ServerThread.java:695)
                         at org.jboss.remoting.transport.socket.ServerThread.dorun(ServerThread.java:549)
                         at org.jboss.remoting.transport.socket.ServerThread.run(ServerThread.java:230)
                        09:44:14,189 WARN [JDBCSupport] Trying again after a pause
                        09:44:14,282 WARN [JDBCSupport] Update worked after retry
                        


                        Also, this one...

                        09:45:15,657 WARN [JDBCSupport] SQLException caught, SQLState HY000 code:1296- assuming deadlock detected, try:1
                        java.sql.SQLException: Got error 286 'Node failure caused abort of transaction' from NDB
                         at com.mysql.jdbc.SQLError.createSQLException(SQLError.java:1055)
                         at com.mysql.jdbc.SQLError.createSQLException(SQLError.java:956)
                         at com.mysql.jdbc.MysqlIO.checkErrorPacket(MysqlIO.java:3515)
                         at com.mysql.jdbc.MysqlIO.checkErrorPacket(MysqlIO.java:3447)
                         at com.mysql.jdbc.MysqlIO.sendCommand(MysqlIO.java:1951)
                         at com.mysql.jdbc.MysqlIO.sqlQueryDirect(MysqlIO.java:2101)
                         at com.mysql.jdbc.ConnectionImpl.execSQL(ConnectionImpl.java:2554)
                         at com.mysql.jdbc.PreparedStatement.executeInternal(PreparedStatement.java:1761)
                         at com.mysql.jdbc.PreparedStatement.executeUpdate(PreparedStatement.java:2046)
                         at com.mysql.jdbc.PreparedStatement.executeUpdate(PreparedStatement.java:1964)
                         at com.mysql.jdbc.PreparedStatement.executeUpdate(PreparedStatement.java:1949)
                         at org.jboss.resource.adapter.jdbc.WrappedPreparedStatement.executeUpdate(WrappedPreparedStatement.java:365)
                         at org.jboss.messaging.core.impl.JDBCPersistenceManager$1AddReferenceRunner.doTransaction(JDBCPersistenceManager.java:1357)
                         at org.jboss.messaging.core.impl.JDBCSupport$JDBCTxRunner2.execute(JDBCSupport.java:474)
                         at org.jboss.messaging.core.impl.JDBCSupport$JDBCTxRunner2.executeWithRetry(JDBCSupport.java:512)
                         at org.jboss.messaging.core.impl.JDBCPersistenceManager.addReference(JDBCPersistenceManager.java:1408)
                         at org.jboss.messaging.core.impl.ChannelSupport.handle(ChannelSupport.java:226)
                         at org.jboss.messaging.core.impl.postoffice.MessagingPostOffice.routeInternal(MessagingPostOffice.java:2212)
                         at org.jboss.messaging.core.impl.postoffice.MessagingPostOffice.route(MessagingPostOffice.java:499)
                         at org.jboss.jms.server.endpoint.ServerConnectionEndpoint.sendMessage(ServerConnectionEndpoint.java:755)
                         at org.jboss.jms.server.endpoint.ServerSessionEndpoint.send(ServerSessionEndpoint.java:397)
                         at org.jboss.jms.server.endpoint.advised.SessionAdvised.org$jboss$jms$server$endpoint$advised$SessionAdvised$send$aop(SessionAdvised.java:87)
                         at org.jboss.jms.server.endpoint.advised.SessionAdvised$send_7280680627620114891.invokeTarget(SessionAdvised$send_7280680627620114891.java)
                         at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:111)
                         at org.jboss.jms.server.container.SecurityAspect.handleSend(SecurityAspect.java:157)
                         at sun.reflect.GeneratedMethodAccessor283.invoke(Unknown Source)
                         at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
                         at java.lang.reflect.Method.invoke(Method.java:597)
                         at org.jboss.aop.advice.PerInstanceAdvice.invoke(PerInstanceAdvice.java:122)
                         at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
                         at org.jboss.jms.server.endpoint.advised.SessionAdvised.send(SessionAdvised.java)
                         at org.jboss.jms.wireformat.SessionSendRequest.serverInvoke(SessionSendRequest.java:95)
                         at org.jboss.jms.server.remoting.JMSServerInvocationHandler.invoke(JMSServerInvocationHandler.java:143)
                         at org.jboss.remoting.ServerInvoker.invoke(ServerInvoker.java:908)
                         at org.jboss.remoting.transport.socket.ServerThread.completeInvocation(ServerThread.java:742)
                         at org.jboss.remoting.transport.socket.ServerThread.processInvocation(ServerThread.java:695)
                         at org.jboss.remoting.transport.socket.ServerThread.dorun(ServerThread.java:549)
                         at org.jboss.remoting.transport.socket.ServerThread.run(ServerThread.java:230)
                        09:45:15,671 WARN [JDBCSupport] Trying again after a pause
                        09:45:16,160 WARN [JDBCSupport] Update worked after retry
                        

                        First one about deadlock - I was seeing this more often, but then increased
                        the MySQL TransactionDeadlockDetectionTimeout to 3s, so not happening as often.

                        The second one I've not seen/noticed before,
                        I'm still trying to dig out the client-side error - but the error is related to failing over.

                        11:08:13,730 INFO @Thread-10 failureDetected(FailoverCommandCenter.java:117) [FailoverCommandCenter] JBoss Messaging server failure detected - waiting for failover to complete...
                        

                        When this error appears on the sender app, it appears as though Jboss1 has failed over its JBM ConnectionFactory to Jboss2.

                        As another thing to add to the mix...
                        When messages are stuck - I have seen the following:
                        Shut down Jboss1 - which then forces a failover onto Jboss2. The receiver application is then able to receive the messages. This is odd since I can see the messages in the JBM_MSG table across the MySQL cluster.

                        For information:
                        For Jboss1 and Jboss2 I've set up the datasources so that they can fail over i.e. for Jboss1 the url is mysql1|mysql2 and for jboss2 it's mysql2|mysql1
                        I've noticed that in the case where Jboss1 fails over from mysql1 to mysql2
                        (ie both are now pointing to the same MySQL instance) I don't see the issues about stuck messages.

                        If all this sounds confused - you're right :) as I've not got my head round the root of the problem. If I try to summarise it seems to be that under load JBM/MySQL:
                        1. Either thinks that one of the MySQL data nodes is no longer responding which triggers a failover;
                        2. Or, gets into a state whereby a sender app can still push messages into the cluster, but a receiver app can't pick them up unless:
                        - either there's been a failover to the JBoss that the receiver is connecting to,
                        - or... the receiver connects to the same JBoss instance as the sender.

                        Thanks.

                        • 9. Re: MySQL in Cluster question

                          Hi,
                          This is a follow-on... similar testing I've now seen the set of exceptions below. Is there some configuration of JBoss/MySQL that I'm missing?

                          It's quite difficult to reliably replicate the problem at a known point, but I am seeing these errors and the ones in the previous posting happen on a regular basis. Any help/suggestions would be really appreciated.

                          The other question I suppose I should ask is whether people have experienced these sorts of issues either with JBoss4.2.x/JBossMQ combination or with JBoss4.2.x/JBM1.4.2


                          Thanks,
                          Joseph.

                          13:54:48,442 WARN [JDBCSupport] SQLException caught, SQLState HY000 code:1296- assuming deadlock detected, try:1
                          java.sql.SQLException: Got error 4010 'Node failure caused abort of transaction' from NDB
                           at com.mysql.jdbc.SQLError.createSQLException(SQLError.java:1055)
                           at com.mysql.jdbc.SQLError.createSQLException(SQLError.java:956)
                           at com.mysql.jdbc.MysqlIO.checkErrorPacket(MysqlIO.java:3515)
                           at com.mysql.jdbc.MysqlIO.checkErrorPacket(MysqlIO.java:3447)
                           at com.mysql.jdbc.MysqlIO.sendCommand(MysqlIO.java:1951)
                           at com.mysql.jdbc.MysqlIO.sqlQueryDirect(MysqlIO.java:2101)
                           at com.mysql.jdbc.ConnectionImpl.execSQL(ConnectionImpl.java:2554)
                           at com.mysql.jdbc.PreparedStatement.executeInternal(PreparedStatement.java:1761)
                           at com.mysql.jdbc.PreparedStatement.executeUpdate(PreparedStatement.java:2046)
                           at com.mysql.jdbc.PreparedStatement.executeUpdate(PreparedStatement.java:1964)
                           at com.mysql.jdbc.PreparedStatement.executeUpdate(PreparedStatement.java:1949)
                           at org.jboss.resource.adapter.jdbc.WrappedPreparedStatement.executeUpdate(WrappedPreparedStatement.java:365)
                           at org.jboss.messaging.core.impl.JDBCPersistenceManager.cacheID(JDBCPersistenceManager.java:1637)
                           at org.jboss.messaging.core.impl.JDBCPersistenceManager$1AddReferenceRunner.doTransaction(JDBCPersistenceManager.java:1370)
                           at org.jboss.messaging.core.impl.JDBCSupport$JDBCTxRunner2.execute(JDBCSupport.java:474)
                           at org.jboss.messaging.core.impl.JDBCSupport$JDBCTxRunner2.executeWithRetry(JDBCSupport.java:512)
                           at org.jboss.messaging.core.impl.JDBCPersistenceManager.addReference(JDBCPersistenceManager.java:1408)
                           at org.jboss.messaging.core.impl.ChannelSupport.handle(ChannelSupport.java:226)
                           at org.jboss.messaging.core.impl.postoffice.MessagingPostOffice.routeInternal(MessagingPostOffice.java:2212)
                           at org.jboss.messaging.core.impl.postoffice.MessagingPostOffice.route(MessagingPostOffice.java:499)
                           at org.jboss.jms.server.endpoint.ServerConnectionEndpoint.sendMessage(ServerConnectionEndpoint.java:755)
                           at org.jboss.jms.server.endpoint.ServerSessionEndpoint.send(ServerSessionEndpoint.java:397)
                           at org.jboss.jms.server.endpoint.advised.SessionAdvised.org$jboss$jms$server$endpoint$advised$SessionAdvised$send$aop(SessionAdvised.java:87)
                           at org.jboss.jms.server.endpoint.advised.SessionAdvised$send_7280680627620114891.invokeTarget(SessionAdvised$send_7280680627620114891.java)
                           at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:111)
                           at org.jboss.jms.server.container.SecurityAspect.handleSend(SecurityAspect.java:157)
                           at sun.reflect.GeneratedMethodAccessor281.invoke(Unknown Source)
                           at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
                           at java.lang.reflect.Method.invoke(Method.java:597)
                           at org.jboss.aop.advice.PerInstanceAdvice.invoke(PerInstanceAdvice.java:122)
                           at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
                           at org.jboss.jms.server.endpoint.advised.SessionAdvised.send(SessionAdvised.java)
                           at org.jboss.jms.wireformat.SessionSendRequest.serverInvoke(SessionSendRequest.java:95)
                           at org.jboss.jms.server.remoting.JMSServerInvocationHandler.invoke(JMSServerInvocationHandler.java:143)
                           at org.jboss.remoting.ServerInvoker.invoke(ServerInvoker.java:908)
                           at org.jboss.remoting.transport.socket.ServerThread.completeInvocation(ServerThread.java:742)
                           at org.jboss.remoting.transport.socket.ServerThread.processInvocation(ServerThread.java:695)
                           at org.jboss.remoting.transport.socket.ServerThread.dorun(ServerThread.java:549)
                           at org.jboss.remoting.transport.socket.ServerThread.run(ServerThread.java:230)
                          13:54:48,444 WARN [JDBCSupport] Trying again after a pause
                          13:54:48,525 WARN [TxConnectionManager] Connection error occured: org.jboss.resource.connectionmanager.TxConnectionManager$TxConnectionEventListener@9eb61a[state=NORMAL mc=org.jboss.resource.adapter.jdbc.local.LocalManagedConnection@1323140 handles=1 lastUse=1233928488441 permit=true trackByTx=false mcp=org.jboss.resource.connectionmanager.JBossManagedConnectionPool$OnePool@3f9de3 context=org.jboss.resource.connectionmanager.InternalManagedConnectionPool@96a235 xaResource=org.jboss.resource.connectionmanager.TxConnectionManager$LocalXAResource@1c58721 txSync=null]
                          java.sql.SQLException: Can't lock file (errno: 157)
                           at com.mysql.jdbc.SQLError.createSQLException(SQLError.java:1055)
                           at com.mysql.jdbc.SQLError.createSQLException(SQLError.java:956)
                           at com.mysql.jdbc.MysqlIO.checkErrorPacket(MysqlIO.java:3515)
                           at com.mysql.jdbc.MysqlIO.checkErrorPacket(MysqlIO.java:3447)
                           at com.mysql.jdbc.MysqlIO.sendCommand(MysqlIO.java:1951)
                           at com.mysql.jdbc.MysqlIO.sqlQueryDirect(MysqlIO.java:2101)
                           at com.mysql.jdbc.ConnectionImpl.execSQL(ConnectionImpl.java:2554)
                           at com.mysql.jdbc.PreparedStatement.executeInternal(PreparedStatement.java:1761)
                           at com.mysql.jdbc.PreparedStatement.executeUpdate(PreparedStatement.java:2046)
                           at com.mysql.jdbc.PreparedStatement.executeUpdate(PreparedStatement.java:1964)
                           at com.mysql.jdbc.PreparedStatement.executeUpdate(PreparedStatement.java:1949)
                           at org.jboss.resource.adapter.jdbc.WrappedPreparedStatement.executeUpdate(WrappedPreparedStatement.java:365)
                           at org.jboss.messaging.core.impl.JDBCPersistenceManager$1AddReferenceRunner.doTransaction(JDBCPersistenceManager.java:1343)
                           at org.jboss.messaging.core.impl.JDBCSupport$JDBCTxRunner2.execute(JDBCSupport.java:474)
                           at org.jboss.messaging.core.impl.JDBCSupport$JDBCTxRunner2.executeWithRetry(JDBCSupport.java:512)
                           at org.jboss.messaging.core.impl.JDBCPersistenceManager.addReference(JDBCPersistenceManager.java:1408)
                           at org.jboss.messaging.core.impl.ChannelSupport.handle(ChannelSupport.java:226)
                           at org.jboss.messaging.core.impl.postoffice.MessagingPostOffice.routeInternal(MessagingPostOffice.java:2212)
                           at org.jboss.messaging.core.impl.postoffice.MessagingPostOffice.route(MessagingPostOffice.java:499)
                           at org.jboss.jms.server.endpoint.ServerConnectionEndpoint.sendMessage(ServerConnectionEndpoint.java:755)
                           at org.jboss.jms.server.endpoint.ServerSessionEndpoint.send(ServerSessionEndpoint.java:397)
                           at org.jboss.jms.server.endpoint.advised.SessionAdvised.org$jboss$jms$server$endpoint$advised$SessionAdvised$send$aop(SessionAdvised.java:87)
                           at org.jboss.jms.server.endpoint.advised.SessionAdvised$send_7280680627620114891.invokeTarget(SessionAdvised$send_7280680627620114891.java)
                           at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:111)
                           at org.jboss.jms.server.container.SecurityAspect.handleSend(SecurityAspect.java:157)
                           at sun.reflect.GeneratedMethodAccessor281.invoke(Unknown Source)
                           at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
                           at java.lang.reflect.Method.invoke(Method.java:597)
                           at org.jboss.aop.advice.PerInstanceAdvice.invoke(PerInstanceAdvice.java:122)
                           at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
                           at org.jboss.jms.server.endpoint.advised.SessionAdvised.send(SessionAdvised.java)
                           at org.jboss.jms.wireformat.SessionSendRequest.serverInvoke(SessionSendRequest.java:95)
                           at org.jboss.jms.server.remoting.JMSServerInvocationHandler.invoke(JMSServerInvocationHandler.java:143)
                           at org.jboss.remoting.ServerInvoker.invoke(ServerInvoker.java:908)
                           at org.jboss.remoting.transport.socket.ServerThread.completeInvocation(ServerThread.java:742)
                           at org.jboss.remoting.transport.socket.ServerThread.processInvocation(ServerThread.java:695)
                           at org.jboss.remoting.transport.socket.ServerThread.dorun(ServerThread.java:549)
                           at org.jboss.remoting.transport.socket.ServerThread.run(ServerThread.java:230)
                          


                          • 10. Re: MySQL in Cluster question
                            ataylor

                            can you try increasing the size of the MySQL lock table overflow

                            • 11. Re: MySQL in Cluster question

                              Hi,

                              Sorry, for my lack of MySQL knowledge - what parameter is that? I can find references to an innodb buffer variable, but for clustering we're using the ndb engine.

                              Thanks,
                              Joseph.

                              • 12. Re: MySQL in Cluster question

                                Hi,

                                a couple more questions to add to the list...
                                - in JBM_POSTOFFICE table, should the ALL_NODES field for the clustered queues be set to Y or N? In my setup it is 'N', the CLUSTERED column is 'Y' for both references to the clustered queue on each node.
                                - I've noticed that when messages get stuck in my scenario (messages come in via JBoss1/mysql1 and are read view Jboss2/mysql2) - forcing a failover will often change the channel Id in JBM_MSG_REF from Jboss1's channel to Jboss2 - and will mean that the receiver now reads the "stuck" messages.

                                I seem to be hitting a brick wall in terms of JBM and MySQL clustering. Does anyone have a representative set of config parameters for JBM and MySQL NDB?

                                Cheers,
                                Joseph

                                • 13. Re: MySQL in Cluster question

                                  Hi,

                                  Apologies for giving this one a nudge, but I've just had the scenario again where I'm sending in messages to one half of a Jboss/MySQL cluster and a receiver connected to the other half of the cluster doesn't pick up the messages unless I fail over the "sender" side of the cluster.

                                  Thanks again for people's time.
                                  Joseph.

                                  • 14. Re: MySQL in Cluster question
                                    timfox

                                     

                                    "jbabad" wrote:


                                    I seem to be hitting a brick wall in terms of JBM and MySQL clustering. Does anyone have a representative set of config parameters for JBM and MySQL NDB?



                                    JBM 1.4 ships with a ndb-persistence-service.xml in with all the other xxx-persistence-service.xml files.

                                    1 2 Previous Next