On Sat, Apr 5, 2008 at 10:19 AM, Robert Burrell Donkin <[EMAIL PROTECTED]> wrote: > #6 uses Buffered streams for IO. > 6A the buffer size is hard coded. this is ok or does it need to be > configurable?
Its probably OK, assuming that we understand the normal patterns of data we expect to be reading, and we don;t really want to confuse people with too many esoteric config params. OTOH making it configurable would allow people to be optimised for patterns which don't fit our model. > 6B performance wise, many implementations read character by > character. IMHO it depends what your priorities are, if you *need* to clear down the stream and close it fast, perhaps to release I/O resources you should have a buffer which will make this happen, i.e. one sized to accept most of the stream in one go. If you process your bytes slowly you will fill you buffer, release your resources and then read from the buffer, but if your processing is quick and your I/O slow you may just be streaming your bytes straight through the buffer or even waiting for bytes to be read from the stream. However apart from the memory overhead I can't see that it would do much harm as long as you didn't have huge empty buffers hanging about. But thats just my 2c. > IIRC Andrew C. Oliver posted about that reading or writing > bytewise from a buffered source is an anti-pattern. can anyone > explain? is buffering the right choice? do implementations need to > fill buffers? Not Sure what Andy might have been alluding to if its not covered by my guess work. > > #7 when an exception is caught, it is immediately rethrown. in this > case, are the streams ever closed? do they need to be? Always, in case not closing them locks some I/O resource like a socket or filehandle. IMHO you should always close I/O in finally, even if you suspect that the implementation will release "orphaned" resources at/after garbage collection. > #8 each protocol needs to decide whether to use character or bytewise > streams. so, i think that either in+outs, or out+inReader will be used > but not both. would it be better to split off subclasses or would this > be overengineering? IMHO choices are specialisation and should always be implemented with inheritance, however that itself might be more elegantly achieved using delegation (normalise your model), delegate to an abstract generalisation and provide alternate implementations which can be selected at runtime. Anything else is, to use a datamodelling term again, a "denormalisation". > > #9 these fields only seem to be used when logging exceptions. reverse > DNS lookups have a tendency to be expensive and will often not produce > any useful information. this cost is paid every time that a connection > is started. is this worthwhile? IMO no, DNS lookups should be off by default and enabled by choice if the operator is willing to take the performance hit in return for the convenience of not having to look them up when interpreting the exception. d. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
