Mailing-List: contact users-help@activemq.apache.org; run by ezmlm
Precedence: bulk
Reply-To: users@activemq.apache.org
Received-SPF: pass (nike.apache.org: domain of lists@nabble.com designates
 216.139.236.158 as permitted sender)
Message-ID: <28594760.post@talk.nabble.com>
Date: Tue, 18 May 2010 04:42:42 -0700 (PDT)
From: allgo <soumya_ssp@yahoo.co.in>
To: users@activemq.apache.org
Subject: Re: ActiveMQ 4.1.1 - Channel Inactive for too long
In-Reply-To: <28594162.post@talk.nabble.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
References: <28594162.post@talk.nabble.com>


Any help?

allgo wrote:
> 
> Hi fellow ActiveMQ and Smix users.
> This may not be an exclusive servicemix problem but may be an ActiveMQ one
> 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.
> 4) I found some forums suggesting to set
> wireFormat.maxInactivityDuration=0. But do I need to di it in all servers?
> Also any adverse effect of using it?
> 
> looking forward to suggestions from you experts. Will update further in
> case I hit upon any concrete solution.. none yet... :-(
> 
> Thanks in advance
> Soumya
> 
> 

-- 
View this message in context: http://old.nabble.com/ActiveMQ-4.1.1---Channel-Inactive-for-too-long-tp28594162p28594760.html
Sent from the ActiveMQ - User mailing list archive at Nabble.com.