On 4/5/06, peter royal <[EMAIL PROTECTED]> wrote: > > On Apr 4, 2006, at 11:18 AM, Trustin Lee wrote: > >> Write would become synchronous when under load.. The write queue > >> would be "bounded", attempts to create the future would block when > >> under load. How to assembly the bits is tbd, but we have all the > >> necessary primitives to build the behavior. > > > > > > What if a session is running in a single thread model? We cannot > > block in > > this case because it's the thread that performs I/O for other sesions. > > Good point, but it then may not be an option to do write throttling > when running with that model...
Yes, we can make it optional then it's fine. I thought about reads. I think it is not quite easy to implement once ThreadPoolFilter comes into play. All the counting should take place after all thread pool filters and before any codecs, and this constraint is sometimes not applicable. The solution would be: * To maintain a stateful buffer per session so we can track the read buffer size easily, but it's not viable because of a memory consumption issue. * To let users decrease the values by themselves, and it's not reasonable either. * To rely on observation on ByteBuffer.release(). There's a risk here that an IoFilter implementor might forget to release the buffer or doesn't release intentionally for some implementation issues (e.g. reused buffers). Trustin -- what we call human nature is actually human habit -- http://gleamynode.net/ -- PGP key fingerprints: * E167 E6AF E73A CBCE EE41 4A29 544D DE48 FE95 4E7E * B693 628E 6047 4F8F CFA4 455E 1C62 A7DC 0255 ECA6
