Hello,
Sorry I just realized that my posted suggestion doesn't
either work. I do than get into thread races. I overlooked that
when Parser is in expectingMoreData=true state one has to ensure that
the same thread calls the next read.
I'll look for another solution for my parser.
-------- Original-Nachricht --------
> Datum: Tue, 24 Jun 2008 18:15:54 +0200
> Von: "John ROM" <snake-john_at_gmx.de>
> An: dev_at_grizzly.dev.java.net
> Betreff: ParserProtocolFilter ContinuousExecution Handling
> Hello,
>
> Currently if you want your parser to be called again on a
> hasMoreBytesToParse()
> you have to set on your DefaultProtocolChain
> protocolChain.setContinuousExecution(true);
> This ensures that you don't go back to the main Selectionkey Loop.
>
> My problem is that when I have read a full message with my parser and am
> finished (
> hasMoreBytesToParse()== false and expectingMoreData()== false)
> the chain does one extra loop until ReadFilter breaks out of the chain.
> This might cost perfomance and my statefull parser might be called again
> because
> it may be in the context attributes:
>
> What about changing ParserProtocolFilter Line 148 to :
>
> if (parser != null && parser.hasMoreBytesToParse()) {
> // Need to say that we read successfully since bytes are left
> context.setAttribute(ProtocolFilter.SUCCESSFUL_READ,
> Boolean.TRUE);
> return true;
> } else{
> context.setAttribute(ProtocolFilter.SUCCESSFUL_READ,
> Boolean.FALSE);
> }
>
> Or am I overseeing something (-:
> Many Greetings
>
>
>
>
> --
> Psssst! Schon vom neuen GMX MultiMessenger gehört?
> Der kann`s mit allen: http://www.gmx.net/de/go/multimessenger
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_grizzly.dev.java.net
> For additional commands, e-mail: dev-help_at_grizzly.dev.java.net
--
GMX startet ShortView.de. Hier findest Du Leute mit Deinen Interessen!
Jetzt dabei sein: http://www.shortview.de/?mc=sv_ext_mf@gmx