Radim Kolar SF.NET wrote:
> i wonder if there is better way to handle writes than making own selector and
> doing select() loop in Filter, because it wastes 1 worker thread/client just
> for looping around select() and writing output data to client. I think app
> should do multiplexed writes and break 1:1 thread/client maping.
Agree. The temporary Selector trick we use here might not be appropriate
for all case. One way to workaround the problem would consist of having
a decicated SelectorHandler + WriteFilter on which you can register a
ByteBuffer and get notified when the byte are fully written. We have
discussed several time on that list having a Write queue functionality,
we just didn't have a chance yet to implement it.
>
> i am here:
> Selector() OP_READ -> Worker thread -> Protocol filter -> request parsed, reply
> is stored into Context
>
> so i need to make 2nd controller because i cant have 2 ProtocolChainInstanceHandlers / controller and i don't think chains like ReaderFilter - something - Write filter works.
It will work but like you noted, the Write will block if the network is
slow or if the client isn't reading bytes fast enough. But it can work.
>
> Now i need to do ?
> 1. switch registration of select type on channel from OP_READ to OP_WRITE
> 2. deregister Selection key from controller/selector
> 3. assign selection key to different controller
Yes probably. Working on an async write queue is exactly what you need I
suspect. What I was having in mind is to be able, from a Context (using
the getAttribute()), to get a reference to a write queue where you can
register something like that:
((WriteQueue)ctx.getAttribute(Grizzly.WriteQueue)).write(new
WriteCallbackHandler(SelectionKey) {
public void onComplete(...){
}
public void onException(...){
}
});
The WriteQueue will take care or handling the async write.
What do you think? That would make asyn write easy to handle.
Just thinking loud :-)
Thanks
-- Jeanfrancois
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_grizzly.dev.java.net
> For additional commands, e-mail: users-help_at_grizzly.dev.java.net
>