Hi,
We are using James Server with an ActiveMQ master/slave configuration
configured via failover:
failover:(tcp://mq0.xxx:8080,tcp://mq1.xxx:8080)?jms.prefetchPolicy.all=0
When the master stops, we would expect a failover to the slave - this is
working fine with other applications. However, James Server does not switch
queue instance and keeps producing the following exception instead:
[ERROR] - Exception caught in RemoteDelivery.run() [Remote delivery thread (3)]
[j.mailetcontext]
org.apache.james.queue.api.MailQueue$MailQueueException: Unable to dequeue next
message (javax.jms.IllegalStateException: The Session is closed)
at
org.apache.james.queue.jms.JMSMailQueue.deQueue(JMSMailQueue.java:170)
~[james-server-queue-jms-3.0-beta5-20130109.104230-723.jar:3.0-beta5-SNAPSHOT]
at
org.apache.james.transport.mailets.RemoteDelivery.run(RemoteDelivery.java:771)
~[james-server-mailets-3.0-beta5-20130110.114225-802.jar:3.0-beta5-SNAPSHOT]
at java.lang.Thread.run(Thread.java:679) [na:1.6.0_24]
Caused by: javax.jms.IllegalStateException: The Session is closed
at
org.apache.activemq.ActiveMQSession.checkClosed(ActiveMQSession.java:731)
~[activemq-core-5.7.0.jar:5.7.0]
at
org.apache.activemq.ActiveMQSession.createQueue(ActiveMQSession.java:1169)
~[activemq-core-5.7.0.jar:5.7.0]
at sun.reflect.GeneratedMethodAccessor51.invoke(Unknown Source) ~[na:na]
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
~[na:1.6.0_24]
at java.lang.reflect.Method.invoke(Method.java:616) ~[na:1.6.0_24]
at
org.springframework.jms.connection.CachingConnectionFactory$CachedSessionInvocationHandler.invoke(CachingConnectionFactory.java:344)
~[spring-jms-3.1.0.RELEASE.jar:3.1.0.RELEASE]
at $Proxy87.createQueue(Unknown Source) ~[na:na]
at
org.apache.james.queue.jms.JMSMailQueue.deQueue(JMSMailQueue.java:107)
~[james-server-queue-jms-3.0-beta5-20130109.104230-723.jar:3.0-beta5-SNAPSHOT]
... 2 common frames omitted
The James Server keeps running and consumes 100% of the available CPU until it
is manually restarted.
Thanks for looking into this issue.
Cheers,
Philipp
