> 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(...){
> }
> });
i think about this scheme:
Allow multiple protocolchains registration per controller.
1.
controller.setProtocolChainInstanceHandler(chain,operation) OP_READ or OP_WRITE
etc..) or some kind of mask OP_READ|OP_WRITE
2. Use context for passing protocol state between chains
This needs 1:1 Context vs SelectionKeys mapping. Bind context to SelectionKey
3. In filter reader chain just alter protocol state in context or write raw data into context write buffer) and switch SelectionKey on Selector from OP_READ to OP_WRITE and return false; (don't call next filter in read chain).
4. in next select() loop
SelectionKey + Context will arrive into protocol writer chain:
protocol dependent writer (add headers, check protocol state from context,
extract data to be written from Context and put result into TLS bytebuffer)
if no more data to write switch to reader or close connection.
WriteFilter.java (generic bytes writer, should not close connection after all data are send)
5.
consider writing new filter classes.
EOFFilter() - cancel connection if no more data needs to be sent.
SwitchToRead() - switch to read mode if no more data needs to be sent.
SwitchToWrite() ditto