james-server-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Robert Burrell Donkin" <robertburrelldon...@gmail.com>
Subject Re: [JAMESHandler] Streams in AbstractJamesHandler
Date Sat, 05 Apr 2008 19:37:42 GMT
On Sat, Apr 5, 2008 at 8:04 PM, Bernd Fondermann
<bernd.fondermann@googlemail.com> wrote:
>
> On Sat, Apr 5, 2008 at 11:19 AM, Robert Burrell Donkin
>  <robertburrelldonkin@gmail.com> wrote:

<snip>

>  >  #6 uses Buffered streams for IO.
>  >   6A the buffer size is hard coded. this is ok or does it need to be
>  >  configurable?
>
>  I think the default would have been ok here (which is 512 for Sun Java
>  1.4). The advantage of letting the JDK implementation decide is that
>  future machines (under newer JDKs) might be better off with other
>  buffer sizes.
>  The choice people make is probably to achieve that they optimize IP
>  packets going over the wire.
>  Don't know if this can be effectively controlled with the buffer size
>  since the underlying system layers might make their own decisions.
>  But all this is speculation.

yes: better to use the default size

if there's a demand for another buffer size then let the user specify
it in the configuration

>  >   6B performance wise, many implementations read character by
>  >  character.
>
>  "performance wise" in this context means "to degrade performance", right? :-)

not necessarily: some protocols require octet based decision trees so
you pretty much have to read byte-by-byte

>  > 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?
>
>  doing bytewise IO on an _un_buffered stream is the anti-pattern. so I
>  think buffering is the way to go here.

it's the reading from and writing to the buffers i meant. andrew
opined that  byte-wise reading from and writing to a buffered input
stream is an anti-pattern.

>  >  #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?
>
>  but you could wrap any stream with a reader, couldn't you (via
>  InputStreamReader)? so you could see the stream as the low level
>  choice and the reader as the higher level choice.

i'm not disagreeing about the utility it's just that having all four
accessible from protected methods seems inefficent and potentially a
source of hard to track down bugs with encoding in odd error cases...

>  >  #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?
>
>  AFAIK, dnsServer uses a cache - but the question remains valid.
>  probably, in the end, it is worthwhile - even indespensible - in
>  certain failure situations. ;-)

even if they are, would it be better to look them up only when needed?

- robert

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


Mime
View raw message