Hi again. Sorry for the lack of replies, but ive been so busy with work that I havnt had time to play with java =)
Is there anything wrong with queuing events? What did you have in mind for this (i.e. you seem to dislike it, but I can't think what's wrong with that, so I'm wondering what you're thinking of that is different to what I'm thinking of
The reason Ive been a bit worried about queuing events/objects is that I was affraid it would introduce to much object creation in the basic operation of the netcode. After Ive had the chance to create a nio server it seems it was an unneeded concern, since nio does do a lot of the work as you said.
Another thing Im a bit concerned about is what the performance cost is for constantly changing the events you are registered for (and perform a wakeup to make the selector update it) plus the good description in SelectionKey.interestOps(int:ops)
This method may be invoked at any time. Whether or not it blocks, and for how long, is implementation-dependent.
Say we have a setup where one object contains the selector and has its own thread who perform select operations. The selected keys are then handed over to a pool from where 1-n workers pick them up to process.
Correct me if im wrong here, but when the selectionkey is put in the pool I would have to cancel the registered OP_READ and then reregister it after processing has been completed, to prevent that multiple threads get a reference to the selectionkey (by cancling i mean changing interestOps not canceling selectionKey).
Its not a problem to implement Im just a little annoyed with working with may/may not work documented features =)
Out of interest, what do you find "messy" about it? Also, what problems have you had with shutdown?
My problem with having seperate read/write selectors is mostly that I then spread out the code that can "trigger" the need to disconnect a client, so it takes extra code to handle those different scenarios. I cant really see advantages of splitting it up (which is probabbly because im new to this area =) so Im just going for the most simple design.
You shouldn't need to use wait/notify with NIO unless you really want to; I'm guessing you're thinking of using this to implement a multi-threaded queue (given your later comments), but you can do it without if you don't like them (which I don't )
Thats what Im going for in my rewrite yes, with multiple worker threads picking the up the SelectionKey's from a queue. Im not sure how you'll do without wait/notify to handle that transfer though
Are you sure you want worker threads? Since dumping the pooling, I've usually found performance more than adequate for hundreds of clients with just a single thread per selector
Nope Im not sure if its needed, but as I said there can be a fair load of users at the chatsite where this code if first intended to be put in use (where some user commands result in multiple-second sql queries so decoupling from any bottleneck in the system is needed, and it seems a better and better idea to do it in the networkcode =) My current plan is to try a rewrite with the structure describe in this reply, and then try out how it works.