Ok, problem solved....:-)
I thought that AMQ-clusters could be used with only one Uri, meaning one cluster-node goes down and the other node "hops" in, like when using a virtual IP with Jboss. Well, here is how it worked for me: Master-Broker: <transportConnectors> <transportConnector name="openwire" uri="tcp://localhost:61613"/> </transportConnectors> <persistenceAdapter> <journaledJDBC journalLogFiles="5" dataDirectory="/opt/activemq/cluster_1/shared_data"/> </persistenceAdapter> Slave-Broker: <transportConnectors> <transportConnector name="openwire" uri="tcp://localhost:61616"/> </transportConnectors> <persistenceAdapter> <journaledJDBC journalLogFiles="5" dataDirectory="/opt/activemq/cluster_1/shared_data"/> </persistenceAdapter> Client-Configuration failover:(tcp://localhost:61613,tcp://localhost:61616) j0llyr0g3r wrote: > > Hey folks, > > i am having a hard time trying to find out how clustering works seamlessly > with amq. > > Imagine the following situation: > > -> One cluster consisting of a master and a slave broker > -> One consumer and one producer > -> Persistence / Clustering mechanism is filesystem-based via shared > storage > > This means the master broker has the following configuration: > > <transportConnectors> > <!--<transportConnector name="stomp" uri="stomp://localhost:61616" > />--> > <transportConnector name="openwire" uri="tcp://localhost:61616" /> > </transportConnectors> > > <persistenceAdapter> > <journaledJDBC journalLogFiles="5" > dataDirectory="/opt/amq_test/cluster_1/shared_data"/> > </persistenceAdapter> > > The slave has the same configuration: > > > <transportConnectors> > <!--<transportConnector name="stomp" uri="stomp://localhost:61616" > />--> > <transportConnector name="openwire" uri="tcp://localhost:61616" /> > </transportConnectors> > > <persistenceAdapter> > <journaledJDBC journalLogFiles="5" > dataDirectory="/opt/amq_test/cluster_1/shared_data"/> > </persistenceAdapter> > > Now if start the master-broker followed by the slave-broker the output of > the slave-broker is: > > INFO faultPersistenceAdapterFactory - Journal is locked... waiting 10 > seconds for the journal to be unlocked. > INFO faultPersistenceAdapterFactory - Journal is locked... waiting 10 > seconds for the journal to be unlocked. > > > So far, so good.... > > BUT: > > If i now start my consumer and producer everything works fine, meaning > that i see the consumer receiving the messages. > Both producer and consumer connect with the following uri: > > tcp://debln099:61616?wireFormat=openwire&transport.useAsyncSend=false&tcpNoDelay=true > > But if i now stop my master broker via hitting "CTRL + c" my consumer > quits with the message: > > JMS Exception occured. Shutting down client. > > And the producer quits with a: > > response from futureResponse was invalid > FILE: activemq/transport/ResponseCorrelator.cpp, LINE: 145 > FILE: activemq/transport/ResponseCorrelator.cpp, LINE: 152 > FILE: activemq/connector/openwire/OpenWireFormatNegotiator.cpp, > LINE: 105 > FILE: activemq/connector/openwire/OpenWireConnector.cpp, LINE: > 1468 > FILE: activemq/connector/openwire/OpenWireConnector.cpp, LINE: 928 > FILE: activemq/core/ActiveMQSession.cpp, LINE: 703 > FILE: activemq/core/ActiveMQProducer.cpp, LINE: 194 > FILE: activemq/core/ActiveMQProducer.cpp, LINE: 149 > FILE: activemq/core/ActiveMQProducer.cpp, LINE: 108 > ----------------------------------------------------- > Finished with the demo ignore errors from this > point on as the sockets breaks when we shutdown. > ===================================================== > Segmentation fault > > > According to the documentation, i would have expected that the slave > broker immediately takes over the database lock. > > This doesn't seem to be the case.... > > What is going wrong here? > -- View this message in context: http://www.nabble.com/Clustering-not-working%3A-JMS-Exception-tf4297810s2354.html#a12250674 Sent from the ActiveMQ - User mailing list archive at Nabble.com.
