james-server-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Noel J. Bergman" <n...@devtech.com>
Subject RE: [Proposal] Upgrade to DnsJava 1.3.1 & Use highter level API to neaten code in RemoteDelivery & more ....
Date Fri, 03 Jan 2003 20:47:16 GMT
Serge,

>From the sound of it, why don't we start by upgrading the v2.1 branch with
the new DnsJava, and some of your updates, since it sounds from what you are
saying that it is all API compatible.

Sounds as if we'd get some immediate benefits from it, and could get some
good experience with it.

Do you want to look into doing those changes?

	--- Noel

-----Original Message-----
From: Serge Sozonoff [mailto:serge@globalbeach.com]
Sent: Thursday, January 02, 2003 10:00
To: James Developers List
Subject: [Proposal] Upgrade to DnsJava 1.3.1 & Use highter level API to
neaten code in RemoteDelivery & more ....


Hi,

1.
The current release 1.3.1 of DnsJava fixes some bugs and also contains a
feature to auto detect the dns servers of the OS on which it is running.
"Currently, this works if either the appropriate properties are set, the OS
has a unix-like /etc/resolv.conf, or the system is Windows based with
ipconfig or winipcfg"
This is a nice to have that has been requested.

2.
There is a higher level DnsJava API we could make use of to neaten up the
code in RemoteDelivery.

3.
It might be worth having a discussion of the impact DnsJava could have on
the scalability of RemoteDelivery.

The ExtendedResolver in DnsJava uses several threads to do concurrent
lookups against the defined Dns servers. The first returned answer gets
used. Currently there is a hard coded limit of max 10 threads in DnsJava
which as far as I can tell we don't initialize to anything bigger in JAMES.
In theory this means that if RemoteDelivery is under heavy load things could
get held up on dns lookups.

I am not familiar enough with the DNS implementation in JNDI so I am not
sure how it works compared to DnsJava.
I will take a look at this.

I guess one of the main questions is, do we stick with DnsJava or do we use
the DNS service provider of the JNDI extension?
If we are leaning towards heavy use of JRE 1.4+, we would have the benefit
of the DNS service included.

One could also argue that we could write a test using both options to see
which is faster....


Thanks,
Serge

----- Original Message -----
From: "Noel J. Bergman" <noel@devtech.com>
To: "James Developers List" <james-dev@jakarta.apache.org>
Sent: Wednesday, January 01, 2003 10:15 PM
Subject: [V3] DNSJava / JNDI DNS Service Provider


> Serge,
>
> > FYI, DnsJava currently does [discovery], we are just not using it that
> way.
> > One of the things I had thought about for v3 and RemoteDelivery was to
> > clean up and do some work regarding DNS.
>
> Please submit a proposal.  Depending upon the scope, perhaps it would make
> sense to roll some or all of that change into the v2 series as well.
>
> > I guess we will need a discussion as to the pros and cons for moving to
> the
> > JNDI [DNS] Service provider.  Maybe we make the DNS service pluggable?
>
> It already is pluggable, and should certainly stay that way.
>
> --- Noel
>
>
> --
> To unsubscribe, e-mail:
<mailto:james-dev-unsubscribe@jakarta.apache.org>
> For additional commands, e-mail:
<mailto:james-dev-help@jakarta.apache.org>
>
>


--
To unsubscribe, e-mail:   <mailto:james-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:james-dev-help@jakarta.apache.org>


--
To unsubscribe, e-mail:   <mailto:james-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:james-dev-help@jakarta.apache.org>


Mime
View raw message