james-server-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Danny Angus" <da...@apache.org>
Subject Re: [JAMESHandler] Streams in AbstractJamesHandler
Date Sat, 05 Apr 2008 20:53:06 GMT
On Sat, Apr 5, 2008 at 10:19 AM, Robert Burrell Donkin
<robertburrelldonkin@gmail.com> 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

>  #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


To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org

View raw message