Hi, > Do you want to look into doing those changes?
OK Sergei ----- Original Message ----- From: "Noel J. Bergman" <[EMAIL PROTECTED]> To: "James Developers List" <[EMAIL PROTECTED]> Sent: Friday, January 03, 2003 9:47 PM Subject: RE: [Proposal] Upgrade to DnsJava 1.3.1 & Use highter level API to neaten code in RemoteDelivery & more .... > 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:[EMAIL PROTECTED]] > 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" <[EMAIL PROTECTED]> > To: "James Developers List" <[EMAIL PROTECTED]> > 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:[EMAIL PROTECTED]> > > For additional commands, e-mail: > <mailto:[EMAIL PROTECTED]> > > > > > > > -- > To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> > For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> > > > -- > To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> > For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> > > -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
