Mailing-List: contact users-help@mina.apache.org; run by ezmlm
Precedence: bulk
Reply-To: users@mina.apache.org
Received-SPF: pass (athena.apache.org: domain of kinnza@gmail.com designates
 64.233.170.184 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=message-id:date:from:to:subject:in-reply-to:mime-version:content-type:references;
        b=Zmwymr5EPacVBngY9MsAlRVkRBKbH4FRijfHGkJjQtItX19/1xxI/Eb+ihaD5ROfREEs+ndX/6hd+MQAWEQDa140hkwEqtzWDT/kOeNAnNANsAzUqVOmkpaf8F3BRGBnVM4Fk2GRSfEX22aX4+bP4m+3iaTtjivioyRVp0zIuyg=
Message-ID: <7b16f6f60805260805k2e788095sb25632486f4062e4@mail.gmail.com>
Date: Mon, 26 May 2008 17:05:34 +0200
From: Kinnza <kinnza@gmail.com>
To: users@mina.apache.org
Subject: Re: StateMachine and session.write may block
In-Reply-To: 
 <29C6004141E2EA49AB91238C5E83DC9D01FF1289@BTEXC01.bluetreewireless.com>
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_Part_3017_4153011.1211814334833"
References: 
 <29C6004141E2EA49AB91238C5E83DC9D01FF123B@BTEXC01.bluetreewireless.com>
	 <483A5510.2070701@trillian.se>
	 <29C6004141E2EA49AB91238C5E83DC9D01FF127F@BTEXC01.bluetreewireless.com>
	 <7b16f6f60805260745x1562bf86j86e37ab77222aded@mail.gmail.com>
	 <29C6004141E2EA49AB91238C5E83DC9D01FF1289@BTEXC01.bluetreewireless.com>

------=_Part_3017_4153011.1211814334833
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

oh ok sorry :D

On Mon, May 26, 2008 at 5:01 PM, Simon Trudeau <
strudeau@bluetreewireless.com> wrote:

> Sorry, kinnza but the issue I am discussing is not related to your issue
> (unless you are having problem with deadlock and statemachines! :.), my
> previous mail was not directed to you specifically but was directed at
> the mailing list in general and at Niklas in particular. Good luck with
> your issue.
>
>
> Simon
> -----Original Message-----
> From: Kinnza [mailto:kinnza@gmail.com]
> Sent: May-26-08 10:45 AM
> To: users@mina.apache.org
> Subject: Re: StateMachine and session.write may block
>
> hi simon
> are you sure we are talking about the same problem? i think the last
> mail you sent me might not be relevant to me as well
>
> On Mon, May 26, 2008 at 4:39 PM, Simon Trudeau <
> strudeau@bluetreewireless.com> wrote:
>
> >
> > Found a deadlock! Jstack is a very cool tool! :.)
> >
> > It seams that the problem lies with:
> >
> > **********
> > StateMachine.java L.130
> >
> >    public void handle(Event event) {
> >        StateContext context = event.getContext();
> >
> >        synchronized (context) {
> >            LinkedList<Event> eventQueue = eventQueueThreadLocal.get();
>
> > ...
> > **********
> >
> > I am not sure as to why there would be contention between my two
> > statemachine's context (FirmwareUpgradeFilter$FirmwareUpgradeContext
> > and PasswordProtection$PasswordProtectionContext). My only guess is
> > that since both state machines are executed one after the other:
> >
> > 1- My Codec Filter
> > 2- StateMachine Filter 1 (Mina state-machine)
> > 3- StateMachine Filter 2 (Mina state-machine)
> > 4- executorFilter
> > 5- My Processor Filter
> >
> > One filter must be attempting to write a request while the other one
> > must be attempting to write a response and they both lock on the
> > other's resource.
> >
> > "NioProcessor-1":
> > at $Proxy46.messageSent(Unknown Source)
> >
> > "pool-5-thread-1":
> > at $Proxy46.filterWrite(Unknown Source)
> >
> > That's my guess. What do you think? Should this be addressed at the
> > framework level or should I but a dummy filter between my two state
> > machines to make sure that both statemachines don't compete for the
> > same locked resource? Should I change something to my executor filter?
> >
> > Thanks,
> >
> > Simon
> > -----Original Message-----
> > From: Niklas Therning [mailto:niklas@trillian.se]
> > Sent: May-26-08 2:14 AM
> > To: users@mina.apache.org
> > Subject: Re: StateMachine and session.write may block
> >
> > Hi Simon,
> >
> > I think a thread dump would help debugging this. Please generate one
> > the next time you experience this problem and post the output here. If
>
> > you don't know how to generate one please see:
> > http://wiki.netbeans.org/GenerateThreadDump
> >
> > /Niklas
> >
> > Simon Trudeau skrev:
> > > I think I have uncovered a very weird behavior of mina 2.x (latest
> > > trunk).
> > >
> > > I have a filterchain structure as followed
> > >
> > > 1- My Codec Filter
> > > 2- StateMachine Filter 1 (Mina state-machine)
> > > 3- StateMachine Filter 2 (Mina state-machine)
> > > 4- executorFilter
> > > 5- My Processor Filter
> > >
> > > On certain usage scenarios, calls to session.write() block!
> > >
> > > It blocks when DefaultIoFilterChain.callPreviousFilterWrite(){ ...
> > > filterWrite(nf, session, writeRequest); ...} is invoked.
> > > When trying to print the name of the filter that gets invoked
> > > (filter.getClass.getSimpleName()), I get $Proxy46. I would have
> > > wanted
> >
> > > to be more precise and put a break point to know what's going on but
>
> > > since I can only reproduce the scenario 1/10 try, it's a bit hard
> > > :.)
> > >
> > > Nevertheless I got the following order of filters called when it
> > > blocked:
> > > org.apache.mina.common.DefaultIoFilterChain$TailFilter
> > >
> > > foo.bar.MyProcessorFilter
> > >
> > > org.apache.mina.filter.executor.ExecutorFilter
> > >
> > > $Proxy46
> > >
> > > $Proxy46
> > >
> > >
> > > I cannot explain why it could have blocked since I don't know where
> > > to
> >
> > > start in the Proxy and in Mina StateMachine. Maybe it has to do with
>
> > > my ExcutorFilter being a
> > > org.springframework.scheduling.concurrent.ThreadPoolTaskExecutor
> > > instead of an OrderedThreadPoolExecutor
> > > <http://mina.apache.org/report/trunk/apidocs/org/apache/mina/filter/
> > > ex ec utor/OrderedThreadPoolExecutor.html> .
> > >
> > > I would really appreciate any help you can give me on the matter
> > > since
> >
> > > this application I am building will go commercial soon. Thanks.
> > >
> > >
> > > Simon
> > >
> > >
> >
> >
>
>
> --
>
> Kinnza
>


-- 

Kinnza

------=_Part_3017_4153011.1211814334833--