[jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-908) MySQL on Linux fails to load server after failover
[ http://jira.jboss.com/jira/browse/JBMESSAGING-908?page=all ]
Jay Howell updated JBMESSAGING-908:
-----------------------------------
Workaround Description:
This work around will resync up your database so that you can continue to work. Problem
is that you may loose some messages that have not been processed yet. The only ones you
will loose are the ones that are out of sync. But this will get you processing again.
delete from jbm_msg_ref where message_id not in (select message_id from jbm_msg);
delete from jbm_msg where message_id not in (select message_id from jbm_msg_ref);
Workaround: [Workaround Exists]
MySQL on Linux fails to load server after failover
--------------------------------------------------
Key: JBMESSAGING-908
URL: http://jira.jboss.com/jira/browse/JBMESSAGING-908
Project: JBoss Messaging
Issue Type: Bug
Reporter: Tim Fox
Assigned To: Tim Fox
Priority: Critical
Fix For: 1.4.0.CR1
Sometimes, after failover occurs and a server is restarted, the server start fails with:
java.lang.IllegalStateException: Did not load correct number of messages, wanted:1 but
got:0
at
org.jboss.messaging.core.PagingChannelSupport.processReferences(PagingChannelSupport.java:591)
at org.jboss.messaging.core.PagingChannelSupport.doLoad(PagingChannelSupport.java:518)
at
org.jboss.messaging.core.plugin.postoffice.cluster.LocalClusteredQueue.mergeIn(LocalClusteredQueue.java:243)
at
org.jboss.messaging.core.plugin.postoffice.cluster.DefaultClusteredPostOffice.performFailover(DefaultClusteredPostOffice.java:2169)
at
org.jboss.messaging.core.plugin.postoffice.cluster.DefaultClusteredPostOffice.nodeLeft(DefaultClusteredPostOffice.java:2031)
at
org.jboss.messaging.core.plugin.postoffice.cluster.DefaultClusteredPostOffice.access$1800(DefaultClusteredPostOffice.java:98)
at
org.jboss.messaging.core.plugin.postoffice.cluster.DefaultClusteredPostOffice$HandleViewAcceptedRunnable.run(DefaultClusteredPostOffice.java:2400)
at EDU.oswego.cs.dl.util.concurrent.QueuedExecutor$RunLoop.run(QueuedExecutor.java:89)
at java.lang.Thread.run(Thread.java:595
or similar.
Analysing logs it seems this is because when the server crashed previously it did so and
partially committed a transaction, i.e inserted the ref but not the message.
My suspicion is that this is because the MySQL configuration being used is setup to use
the non transaction myISAAM storage which has no transaction support. But this needs to
be verified.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira