SocketChannels die, I'm not invited to the funeral

[blahblahblahh]

Chuckle. I’m desperate enough to give it a try :). Whilst reading this it’s also occurred to me that the CPU problems always occur on the server/app that is also running an SSLServerSocket.

…so I went over our classes which integrate old io with nio with a fine toothcomb (note: Sun’s SSL hasn’t yet been upgraded to support SelectableChannel’s). And I found a point where a particular malformed HTTP request could cause a busy-wait on an individual Socket - but only if that Socket had been created via old io, not via nio. This could, of course, explain cpu-hogging. I fixed that loophole and put in an alert so that if a request triggers it, we’ll get a note in the log, and I’ll know that that problem at least was being exercised.

I’ve also put in Kev’s brute-force “if you take too long to request data, I kill you” approach :). We’ll just have to wait and see which one triggers first…

[blahblahblahh]

…so I went over our classes which integrate old io with nio with a fine toothcomb (note: Sun’s SSL hasn’t yet been upgraded to support SelectableChannel’s). And I found a point where a particular malformed HTTP request could cause a busy-wait on an individual Socket - but only if that Socket had been created via old io, not via nio.
…
I’ve also put in Kev’s brute-force “if you take too long to request data, I kill you” approach :). We’ll just have to wait and see which one triggers first…

In the long-run, there were quite a lot of malformed HTTP requests, so it looks like that was causing the problem…pity that you have to code, maintain and support everything twice at the moment, if you want to use SSL (our nio-related classes were always robust…).

[blahblahblahh]

[quote]This also raises another question, is it wise to un-register a channel from a selector in order to register it again with new options? This would be nice for channels that are idle for long times, but channels that need to send alot would be re-registered alot and this could impact on performance and perhaps introduce bugs?
[/quote]
…I realised my previous answer was a bit too vague. The situation normally (in C) is that your Asynch library is working one of two ways - either it iterates over ALL Channels (or the equivalent for your asynch lib), or it iterates only over those which have changed state.

Obviously, in the former case it’s a REALLY good idea to de-register if you have large numbers of channels (e.g. several thousand connected clients). OTOH, in the latter case it’s a bad idea - because you’re adding considerable extra overhead with no gain in performance.

Hope that makes it a little clearer…