Hi fellow Smix users.
This may not be an exclusive servicemix problem but thought if someoen coudl
help.
We are using Smix 3.2.1 - which uses Amq 4.1.1.
We have a broker cluster of 2 machines say 192.200.200.1 and 192.200.200.2 and
both have the same components deployed(mostly LWC).
Nowe have 2 client machines - say 192.200.200.3 and 192.200.200.4 - both of
which talk to the cluster of .1 and .2 above using teh follwoinf failover
configuration
failover:(tcp://192.200.200.1:61616,tcp://192.200.200.2:61616)?randomize=false
So first the clients try machine .1 and if it is down it sends request to .2.
However it so happened .1 Servicemix process was up and running but stopped
respoding today morning throwing the following error
2010-05-18 05:05:43,988 | WARN | ActiveMQ Scheduler | ActiveMQConnection
| org.apache.activemq.ActiveMQConnection 1529 | Async exception
with no exception listener:
org.apache.activemq.transport.InactivityIOException: Channel was inactive for
too long.
org.apache.activemq.transport.InactivityIOException: Channel was inactive for
too long.
at
org.apache.activemq.transport.InactivityMonitor.readCheck(InactivityMonitor.java:101)
at
org.apache.activemq.transport.InactivityMonitor.access$000(InactivityMonitor.java:35)
at
org.apache.activemq.transport.InactivityMonitor$1.run(InactivityMonitor.java:51)
at
edu.emory.mathcs.backport.java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:442)
at
edu.emory.mathcs.backport.java.util.concurrent.FutureTask.runAndReset(FutureTask.java:198)
at
edu.emory.mathcs.backport.java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$101(ScheduledThreadPoolExecutor.java:102)
at
edu.emory.mathcs.backport.java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.runPeriodic(ScheduledThreadPoolExecutor.java:189)
at
edu.emory.mathcs.backport.java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:213)
at
edu.emory.mathcs.backport.java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:665)
at
edu.emory.mathcs.backport.java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:690)
at java.lang.Thread.run(Thread.java:595)
And hence the cluster system was hung up unless I stopped .1 when .2
automatically became primary and started servicing requests.
I have 3 questions
1) How can I re-create the situation in Test environment... any configuration
that would enable it in say a few minutes time?
2) Is there any solution to this in Smix 3.2.1 - i.e. any configuration change
that might help without affecting performance and stability
3) is there a way to flag it in case such an error occurs.
looking forward to suggestions from you experts. Will update further in case I
hit upon any concrete solution.. none yet... :-(
Thanks in advance
Soumya
