Any help guys? Apart from this.. now I notice te servicemix on the machine .1 itself is behaving weird!!! Hot deploy isnt taking effect and also not able to identify and load classes in jars which are part of a some deployed components.... is the servicemix instance got corrupt? anyone had similar issue where servicemix have started behaving weird all of a sudden! no change had been done to the system for long and same zips work happily in another machine! Please suggest!
________________________________ From: Soumya <[email protected]> To: [email protected] Sent: Tue, 18 May, 2010 3:15:31 PM Subject: ActiveMq- Channel was inactive for too long 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
