Hi Mark,
>
> Ok so Im just trying to make sense of all this,
>
> The only real way that the framework would invalidate the
> SelectionKey is when it is supposed to be cancelled, such as when
> the channel is closed, or interrupted.
>
> Is is explicitly invalidated. So I wonder why there are bytes trying
> to be sent through a channel whos key is invalid. I am implementing
> connection managing via the CacheableSelectionKeyHandler, so I guess
> that if I was to send too many connections from JMeter then it is
> possible that Grizzly is trying to reclaim the older connections
> (which is this case are really only a few milliseconds old) and use
> them for new incomming connections.
>
> Does this logic make sense?
Well, it's possible. Can you pls. try the different
SelectionKeyHandler, just to check whether it's the case?
Thanks.
WBR,
Alexey.
>
>
> Cheers,
> Mark
>
> On Thu, Jul 24, 2008 at 5:30 PM, John ROM <snake-john_at_gmx.de> wrote:
> Hi Mark,
> well from looking at the exception what
>
> happend is that the connection (selectionKey) was just ready to have
> bytes read in.
>
> Then just before Grizzly was going to read those bytes in the
> Connection(selectionKey) was canceled.
>
> Remeber your protocolChain is running on a WorkerThread and I think
> you mentioned that you are
> canceling the key in your filter so this can happen : (I am just
> guessing, because I do not have your code)
>
> 1) jmeter sends bytes
> 2) grizzly signals bytes are ready
> 3) WorkerThread cancels key
> 4) grizzly wants to read bytes in
> 5) CancelledKeyException
>
> Laugh maybe your setup is a little mean ((-:
>
> But I would like to ask Alexy or Jeanfrancois who are much more
> experts then me
> if it makes sense to catch CancelledKeyException and log a little
> bit nicer that the key has been canceled
> I don't think you can complete avoid this exception because testing
> if key is valid always cost a little performance.....
>
> many Greetings John
>
>
>
>
> -------- Original-Nachricht --------
> > Datum: Thu, 24 Jul 2008 16:33:15 +1000
> > Von: "Mark Macumber" <mark.macumber_at_gmail.com>
> > An: dev_at_grizzly.dev.java.net
> > Betreff: Random CancelledKeyException\'s
>
> > Hi Everyone,
> >
> > At the moment I am trying to setup a configurable TCP server that
> will
> > process a proprietary protocol, and I am using JMeter to do some
> testing.
> >
> > I have setup JMeter so that it fires of lots of requests on
> different
> > threads, I am doing this because I want to only allow a certain
> number of
> > connections.
> >
> > While I am doing this though, I seem to get random exceptions, in
> my log
> > files like so:
> >
> > 2008-07-24 16:29:26,180 [11] ERROR grizzly - doSelect exception
> > java.nio.channels.CancelledKeyException
> > at
> sun.nio.ch.SelectionKeyImpl.ensureValid(SelectionKeyImpl.java:55)
> > at
> sun.nio.ch.SelectionKeyImpl.interestOps(SelectionKeyImpl.java:59)
> > at
> >
> com
> .sun
> .grizzly.TCPSelectorHandler.onReadInterest(TCPSelectorHandler.java:
> 650)
> > at com.sun.grizzly.Controller.doSelect(Controller.java:423)
> > at
> >
> com.sun.grizzly.SelectorHandlerRunner.run(SelectorHandlerRunner.java:
> 82)
> > at
> >
> com
> .sun.grizzly.Controller.startSelectorHandlerRunner(Controller.java:
> 1117)
> > at com.sun.grizzly.Controller.start(Controller.java:924)
> > at au.com.anz.gsts.gbstp.GBSTPServer$1.run(GBSTPServer.java:90)
> > at java.lang.Thread.run(Thread.java:595)
> >
> > I am not sure why it happens, I was wondering if anyone else had
> come
> > across
> > this type of thing before?
> >
> > Cheers,
> > Mark
>
> --
> GMX startet ShortView.de. Hier findest Du Leute mit Deinen Interessen!
> Jetzt dabei sein: http://www.shortview.de/wasistshortview.php?mc=sv_ext_mf@gmx
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_grizzly.dev.java.net
> For additional commands, e-mail: dev-help_at_grizzly.dev.java.net
>
>