Yes, I am queuing write requests as well, but the way you mentioned seems like a possible ticket to OutOfMemoryError.
And on the read operation, we can't remove OP_READ on DatagramAcceptor, because there is just one selection key for many possible clients. I'm currently just checking the session's TrafficMask and dropping the message on the floor if it isn't readable. Any more thoughts on this? -Greg On 4/5/07, Trustin Lee <[EMAIL PROTECTED]> wrote:
Hi Greg, On 3/31/07, Greg Duffy <[EMAIL PROTECTED]> wrote: > I'm almost done with a first stab at a new datagram transport. It's about > 1500 LoC. Should I just open a JIRA and attach it as I've done with patches > before, or is there a different process for something of this size? Maybe a > sandbox or something? > > Let me know the best way to get started. I think it's just one or two classes, so attaching it to JIRA would be fine. Thanks for your contribution! > Also, I'm having some trouble with the TrafficMask stuff. If we are blocking > reads and writes, should I still queue them up? I think that I should drop > them to avoid unlimited queue growth, but this doesn't seem to be agreeing > with the existing unit test. I'll try and dig deeper, but some pointers on > the intended behavior would be helpful. All write requests are queued, so any write attempt should be queued up until TrafficMask for write operations is cleared. But I'm not sure this is the optimal behavior, although the implementor will know that he or she changed the traffic mask and therefore not writing data. For read operations, there's no queue because removing OP_READ interestOp will suffice. HTH, Trustin -- what we call human nature is actually human habit -- http://gleamynode.net/ -- PGP Key ID: 0x0255ECA6
