You are viewing a plain text version of this content. The canonical link for it is here.
Posted to server-dev@james.apache.org by Stefano Bagnara <ap...@bago.org> on 2006/12/18 11:28:41 UTC
[VOTE] InetAddress unbounded cache patch backport
Hi all,
I start this vote trying to solve my veto. I didn't do that before
because I didn't understand someone wanted to make a 2.3.1 release in
the past weeks.
The issue is:
OOM caused by unbounded cache in InetAddress (was James leaks memory slowly)
https://issues.apache.org/jira/browse/JAMES-592
Noel made an ad-hoc fix for the 2.3 branch that you can see here:
http://www.mail-archive.com/server-dev@james.apache.org/msg11380.html
I suggest to read again the whole thread before voting.
In the mean time I fixed the following DNSServer related bugs in Trunk:
- DNSServer does not properly cache MX lookups for CNAMEd domains
https://issues.apache.org/jira/browse/JAMES-672
I consider this not a critical issue, we can avoid backporting.
- DNSJava cache not properly handled when using multiple dnsjava components
https://issues.apache.org/jira/browse/JAMES-674
This is minor, doesn't deserve backporting.
- fetchmail cannot complete processing, because of problem with dnsjava
and firewall/dns
https://issues.apache.org/jira/browse/JAMES-657
I didn't understand why my fixes fixed this problem, but if this is the
case we should consider if this deserve more attention for 2.3.1 or if
we want to ignore it.
- Make sure our container use an expiration for cached dns data
https://issues.apache.org/jira/browse/JAMES-679
This one is a workaround that would avoid JAMES-592 to happen, with no
changes to the code.
Noel suggested the use of
"java.security.Security.setProperty("networkaddress.cache.ttl" , "0"); "
instead of the -Dsun.net.inetaddr.ttl=0, but I expected some reply to
the last comment there.
Please reply also there if you have preferences about this.
With this vote I'm trying to fix the v2.3 branch backport for 2.3.1
release (so this is not necessarily related to next-minor).
This is why I remove the "full backport from trunk" from the options,
because as Noel pointed out, we would break assembly.xml compatibility
and we cannot do this in a point release.
And here are the options to be voted:
1) Backport the custom static access to DNSServer.
http://svn.apache.org/viewvc?view=rev&revision=470929
2) Backport sun jvm specific fix to JAMES-679:
http://svn.apache.org/viewvc?view=rev&revision=473041
3) Define where to add the
"java.security.Security.setProperty("networkaddress.cache.ttl" , "0");"
apply it to trunk and backport it (if you vote this please tell your
preferences about the place to add this code).
Please note that every single of this 3 solutions will remove this OOM
so I think we should simply choose one solution to be backported.
If you agree on this we'll take the solution with the best average vote.
It also worth saying that while 1 is a fix for the problem, 2 and 3 are
workarounds to avoid the OOM, but less optimized as solutions.
Stefano
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: [VOTE] InetAddress unbounded cache patch backport
Posted by Stefano Bagnara <ap...@bago.org>.
Stefano Bagnara wrote:
> And here are the options to be voted:
>
> 1) Backport the custom static access to DNSServer.
> http://svn.apache.org/viewvc?view=rev&revision=470929
-1
I will retire the veto if the majority agree on this.
The long explanation of the veto is in the original thread.
> 2) Backport sun jvm specific fix to JAMES-679:
> http://svn.apache.org/viewvc?view=rev&revision=473041
+1
it is ready and it is simple. It is Sun specific, but: "Does James works
with non SUN jvm?". I remember I tested James with an IBM jvm when I
first used James 2-3 years ago and it was not running (don't remember
why, never tested it again).
> 3) Define where to add the
> "java.security.Security.setProperty("networkaddress.cache.ttl" , "0");"
> apply it to trunk and backport it (if you vote this please tell your
> preferences about the place to add this code).
+0.8
I like this fix but the sun specific fix is the less intrusive option.
Stefano
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: James Server 2.3.0 JVM vendor/version compatibility
Posted by Bernd Fondermann <be...@googlemail.com>.
Fully agreed.
On 12/19/06, Stefano Bagnara <ap...@bago.org> wrote:
> Bernd Fondermann wrote:
> > On 12/19/06, Stefano Bagnara <ap...@bago.org> wrote:
> >> Joachim Draeger wrote:
> >> > We should be careful with sun specific solutions until we clearly
> >> > declare sun jvm as requirement.
> >
> > I would not declare that. Our mission is to provide a pure-Java mail
> > server. For me, this implies to have the goal of make it running
> > anywhere -- even if currently, it is not.
>
> I agree on the "pure" write once run everywhere, but maybe it will
> happen that we know it doesn't work everywhere (right now).
>
> What I propose in practice is to define a set of platform to be checked
> in order to approve a release.
>
> As an example I consider compatibility with Java 6 an higher priority
> than compatibility with JRockit or IBM jvm or gnu gcj+classpath.
>
> I remember I tried James 2.3.0 also with gnu-gcj+classpath and it didn't
> work. IIRC we use (javamail 1.4 does) a Socket constructor that is not
> implemented by classpath.
>
> I think it is better to declare a jvm compatibility limitation than
> avoid releasing at all.
>
> As an example:
> - I think that for next-major compatibility with java 6 should be
> considered (if not too difficult, required).
> - I instead think that for 2.3.1 this issue could be ignored.
>
> >> I know James Server 2.3.0 works on Sun Java 1.4 and 5. This is valid for
> >> SSL and SMIME stuff too, not sure about the JMX stuff (maybe Bernd can
> >> make a summary of his knowledge aboud this).
> >
> > Same with JMX.
> >
> > Bernd
>
> Thank you,
> Stefano
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
> For additional commands, e-mail: server-dev-help@james.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: James Server 2.3.0 JVM vendor/version compatibility
Posted by Stefano Bagnara <ap...@bago.org>.
Bernd Fondermann wrote:
> On 12/19/06, Stefano Bagnara <ap...@bago.org> wrote:
>> Joachim Draeger wrote:
>> > We should be careful with sun specific solutions until we clearly
>> > declare sun jvm as requirement.
>
> I would not declare that. Our mission is to provide a pure-Java mail
> server. For me, this implies to have the goal of make it running
> anywhere -- even if currently, it is not.
I agree on the "pure" write once run everywhere, but maybe it will
happen that we know it doesn't work everywhere (right now).
What I propose in practice is to define a set of platform to be checked
in order to approve a release.
As an example I consider compatibility with Java 6 an higher priority
than compatibility with JRockit or IBM jvm or gnu gcj+classpath.
I remember I tried James 2.3.0 also with gnu-gcj+classpath and it didn't
work. IIRC we use (javamail 1.4 does) a Socket constructor that is not
implemented by classpath.
I think it is better to declare a jvm compatibility limitation than
avoid releasing at all.
As an example:
- I think that for next-major compatibility with java 6 should be
considered (if not too difficult, required).
- I instead think that for 2.3.1 this issue could be ignored.
>> I know James Server 2.3.0 works on Sun Java 1.4 and 5. This is valid for
>> SSL and SMIME stuff too, not sure about the JMX stuff (maybe Bernd can
>> make a summary of his knowledge aboud this).
>
> Same with JMX.
>
> Bernd
Thank you,
Stefano
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: James Server 2.3.0 JVM vendor/version compatibility
Posted by Bernd Fondermann <be...@googlemail.com>.
On 12/19/06, Stefano Bagnara <ap...@bago.org> wrote:
> Joachim Draeger wrote:
> > We should be careful with sun specific solutions until we clearly
> > declare sun jvm as requirement.
I would not declare that. Our mission is to provide a pure-Java mail
server. For me, this implies to have the goal of make it running
anywhere -- even if currently, it is not.
>
> I know James Server 2.3.0 works on Sun Java 1.4 and 5. This is valid for
> SSL and SMIME stuff too, not sure about the JMX stuff (maybe Bernd can
> make a summary of his knowledge aboud this).
Same with JMX.
Bernd
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
James Server 2.3.0 JVM vendor/version compatibility
Posted by Stefano Bagnara <ap...@bago.org>.
Joachim Draeger wrote:
> We should be careful with sun specific solutions until we clearly
> declare sun jvm as requirement.
I agree.
I would also would like to know if James 2.3.0 works in a non-sun jvm.
From a recent bug report it seems that it doesn't even work on Sun Java
6 (problems with SSL).
I know James Server 2.3.0 works on Sun Java 1.4 and 5. This is valid for
SSL and SMIME stuff too, not sure about the JMX stuff (maybe Bernd can
make a summary of his knowledge aboud this).
IIRC we have a bug in JIRA reporting that James does not run in the IBM
JVM, but I can't find it right now and the last time I used an IBM JVM
was 2 years ago. At that time IIRC I wasn't able to run James (2.2.0)
over IBM JVM.
Stefano
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: [VOTE] InetAddress unbounded cache patch backport
Posted by Joachim Draeger <jd...@joachim-draeger.de>.
Am Freitag, den 05.01.2007, 09:14 +0000 schrieb Danny Angus:
> > So how to resolve this issue? How to come to a decision in this case?
> > What to do?
>
> http://www.apache.org/foundation/voting.html
>
> When a reasonable time has elapsed and more than three votes have been
> cast the option with the most +1's and no -1's will have been deemed
> to be the most popular. The person who called the vote will record the
> result in the STATUS file.
>
> If anyone objects to all of the options a -1 for each option (or -1 to
> the whole VOTE) will block it. It is incumbent on anyone who chooses
> to veto the proposed change to work with the group to find a way to
> resolve their veto.
Well, I was asking what to in *this* case.
Joachim
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: [VOTE] InetAddress unbounded cache patch backport
Posted by Danny Angus <da...@gmail.com>.
On 1/5/07, Joachim Draeger <jd...@joachim-draeger.de> wrote:
> So how to resolve this issue? How to come to a decision in this case?
> What to do?
http://www.apache.org/foundation/voting.html
When a reasonable time has elapsed and more than three votes have been
cast the option with the most +1's and no -1's will have been deemed
to be the most popular. The person who called the vote will record the
result in the STATUS file.
If anyone objects to all of the options a -1 for each option (or -1 to
the whole VOTE) will block it. It is incumbent on anyone who chooses
to veto the proposed change to work with the group to find a way to
resolve their veto.
d.
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: [VOTE] InetAddress unbounded cache patch backport
Posted by Joachim Draeger <jd...@joachim-draeger.de>.
Am Donnerstag, den 04.01.2007, 14:55 +0100 schrieb Bernd Fondermann:
> On 1/4/07, Stefano Bagnara <ap...@bago.org> wrote:
> > Danny Angus wrote:
> > > +0
> > >
> > > Now I'm voting, but I trust you guys to come to the right decision
> > > without my input.
> > > Happy Norman? ;-)
> > When there are debates between 2 developers it is really important that
> > the community stand up and cast a vote so that personal preferences can
> > be converted in community decisions.
> >
> > Btw the vote included 3 options: should we consider your "+0" like an
> > "Any option is ok for me, I don't have a preference" ?
>
> That is what he said: "I trust you guys to come to the right decision
> without my input."
> Quite clear what he means by this, isn't it?
>
> Please don't make abstaining from voting even harder... ;-)
So how to resolve this issue? How to come to a decision in this case?
What to do?
Joachim
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: [VOTE] InetAddress unbounded cache patch backport
Posted by Bernd Fondermann <be...@googlemail.com>.
On 1/4/07, Stefano Bagnara <ap...@bago.org> wrote:
> Danny Angus wrote:
> > +0
> >
> > Now I'm voting, but I trust you guys to come to the right decision
> > without my input.
> > Happy Norman? ;-)
> >
> > d.
>
> Happy Stefano, too ;-)
>
> When there are debates between 2 developers it is really important that
> the community stand up and cast a vote so that personal preferences can
> be converted in community decisions.
>
> Btw the vote included 3 options: should we consider your "+0" like an
> "Any option is ok for me, I don't have a preference" ?
That is what he said: "I trust you guys to come to the right decision
without my input."
Quite clear what he means by this, isn't it?
Please don't make abstaining from voting even harder... ;-)
Bernd
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
RE: [VOTE] InetAddress unbounded cache patch backport
Posted by "Noel J. Bergman" <no...@devtech.com>.
> "any option you agree on is OK by me"
Any option that does not eliminate the use if InetAddress and unify the
cache structure, as already done in trunk and done by me with a static
method, is unacceptable to me.
But keep making it more appealing for me to find other projects to work on
than JAMES.
--- Noel
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: [VOTE] InetAddress unbounded cache patch backport
Posted by Danny Angus <da...@gmail.com>.
On 1/4/07, Stefano Bagnara <ap...@bago.org> wrote:
> Btw the vote included 3 options: should we consider your "+0" like an
> "Any option is ok for me, I don't have a preference" ?
Almost... "any option you agree on is OK by me"
d.
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: [VOTE] InetAddress unbounded cache patch backport
Posted by Stefano Bagnara <ap...@bago.org>.
Danny Angus wrote:
> +0
>
> Now I'm voting, but I trust you guys to come to the right decision
> without my input.
> Happy Norman? ;-)
>
> d.
Happy Stefano, too ;-)
When there are debates between 2 developers it is really important that
the community stand up and cast a vote so that personal preferences can
be converted in community decisions.
Btw the vote included 3 options: should we consider your "+0" like an
"Any option is ok for me, I don't have a preference" ?
Thank you,
Stefano
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: [VOTE] InetAddress unbounded cache patch backport
Posted by Danny Angus <da...@gmail.com>.
+0
Now I'm voting, but I trust you guys to come to the right decision
without my input.
Happy Norman? ;-)
d.
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: [VOTE] InetAddress unbounded cache patch backport
Posted by Joachim Draeger <jd...@joachim-draeger.de>.
Am Montag, den 18.12.2006, 11:28 +0100 schrieb Stefano Bagnara:
> 1) Backport the custom static access to DNSServer.
> http://svn.apache.org/viewvc?view=rev&revision=470929
-0 This solution is not bad but quite intrusive compared to the others.
It would be okay if we wouldn't have other options.
> 2) Backport sun jvm specific fix to JAMES-679:
> http://svn.apache.org/viewvc?view=rev&revision=473041
We should be careful with sun specific solutions until we clearly
declare sun jvm as requirement.
+0.9
> 3) Define where to add the
> "java.security.Security.setProperty("networkaddress.cache.ttl" , "0");"
> apply it to trunk and backport it (if you vote this please tell your
> preferences about the place to add this code).
+1
As a Static Initializer in James.java until we find a better place. :-)
Joachim
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
RE: [VOTE RESULT] InetAddress unbounded cache patch backport
Posted by "Noel J. Bergman" <no...@devtech.com>.
Excuse me, but no ...
The only actual votes on the proper fix for the code are yours and mine, and
I reject your alleged technical justification for your veto. I refuse to
put out a crippled product because of your displeasure with the use of a
static method to gain exactly the same capability that we already have in
trunk, but without requiring the change to assembly.xml.
I have considered adding support to the base class to attempt looking up the
dnsserver by the role, and calling it we find one, else invoking the static
method. That would allow it to work without change to assembly.xml, but if
assembly.xml has been updated, it will defer to the registered instance.
> (*) Noel did not vote but wrote this: "Any option that does not
> eliminate the use if InetAddress and unify the cache structure is
> unacceptable to me." that I "interpreted" as "+1" for "1)" and "-1" for
> "2)" and "3)"
Nor did I veto (which is what the -1s would be that you so blithely ignore)
the changes to setting the properties for InetAddress. But they don't fully
address the need, even if you selectively count your -1 and ignore mine.
> Each solution received at least a -1. The current total (sum) for each
> solution for binding votes is the following (in brackets you see the
> result counting the not-binding votes too):
Sorry, it doesn't work that way. Either the -1 is a veto on code or it is
not.
--- Noel
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
[VOTE RESULT] InetAddress unbounded cache patch backport
Posted by Stefano Bagnara <ap...@bago.org>.
Serge voted since the last update, so this is the final result.
It has been a complicate and long vote, but we finally have a majority
agreement on the
java.security.Security.setProperty("networkaddress.cache.ttl" , "0");
solution.
The agreed solution is the one that we didn't do already so we have to
code it: I will try to do the work on trunk asap first, then we can
backport.
Stefano
Here is the detail of the vote result:
Stefano Bagnara wrote:
> 3 full weeks passed, and this is an update of this running vote.
>
> Stefano Bagnara wrote:
>> 1) Backport the custom static access to DNSServer.
>> http://svn.apache.org/viewvc?view=rev&revision=470929
>
> -1 Stefano (binding)
> -0 Norman (binding)
> -0 Joachim
> +0 Danny (binding)
> +1 Noel (binding) (*)
-0 Serge (binding)
>> 2) Backport sun jvm specific fix to JAMES-679:
>> http://svn.apache.org/viewvc?view=rev&revision=473041
>
> +1 Stefano (binding)
> +1 Norman (binding)
> +0.9 Joachim
> +0 Danny (binding)
> -1 Noel (binding) (*)
-0 Serge (binding)
>> 3) Define where to add the
>> "java.security.Security.setProperty("networkaddress.cache.ttl" ,
>> "0");" apply it to trunk and backport it (if you vote this please tell
>> your preferences about the place to add this code).
>
> +0.8 Stefano (binding)
> +0.5 Norman (binding) (updated to +1 if the code is placed in
> phoenix-loader)
> +1 Joachim
> +0 Danny (binding)
> -1 Noel (binding) (*)
+1 Serge (binding) Where norman said is fine.
> (*) Noel did not vote but wrote this: "Any option that does not
> eliminate the use if InetAddress and unify the cache structure is
> unacceptable to me." that I "interpreted" as "+1" for "1)" and "-1" for
> "2)" and "3)"
>
> Each solution received at least a -1. The current total (sum) for each
> solution for binding votes is the following (in brackets you see the
> result counting the not-binding votes too):
>
> 1) +0 (+0)
> 2) +1 (+1.9)
> 3) +0.8 (+1.8)
>
> Even if this currently gives the majority to my preferred solution I
> will keep the vote open for a while more, for anyone willing to add
> something after this summary because, as you can see, a single vote can
> still change the whole result.
>
> I will close this on January, the 18th.
>
> Stefano
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
> For additional commands, e-mail: server-dev-help@james.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: [VOTE RESULT] InetAddress unbounded cache patch backport
Posted by Stefano Bagnara <ap...@bago.org>.
robert burrell donkin ha scritto:
>> > we need to elect a release manager who can shepherd the release
>> > through these difficult waters. we need to take a release branch ASAP
>> > so the short term push towards a release can be separated from medium
>> > term concerns about design and maintainability.
>>
>> I agree. How is a release manager elected?
>
> by an election ;-)
>
> typically lazy consensus
>
>> What is the "special power" of the release manager vs other committers?
>
> none but none should be needed
>
> - robert
*IMHO* we have the following possible releases:
- 2.3.1 : IMHO everything is ready in v2.3 (as I wrote in the recent
"About 2.3.1" topic) and only need someone to take care of it (I can do
if asked, but I would prefer if someone else do)
- 2.4.0 : (ex next-minor) has been proposed by Noel and Vincenzo. If
they still have this in their plans IMHO one of them can be the release
manager and branch "v2.4" from current "v2.3" and start the "vetted
backports" (as per Noel mails)
- 2.5.0 / 3.0.0: (ex next-major) sooner or later trunk should (IMHO) be
branched to start consolidation and release something. We agreed on this
generically but have not found a solution. Now you are the most active
in trunk, so maybe you will take care of understanding what can be done
and when.
I personally don't care of 2.4.0 (next-minor). I'm willing to help for
2.3.1 if asked, and to help with 2.5.0/3.0.0 (once I'll have understood
what can be done there).
Stefano
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: [VOTE RESULT] InetAddress unbounded cache patch backport
Posted by Norman Maurer <nm...@byteaction.de>.
Stefano Bagnara schrieb:
> robert burrell donkin ha scritto:
>>> > we need to elect a release manager who can shepherd the release
>>> > through these difficult waters. we need to take a release branch ASAP
>>> > so the short term push towards a release can be separated from medium
>>> > term concerns about design and maintainability.
>>>
>>> I agree. How is a release manager elected?
>>
>> by an election ;-)
>>
>> typically lazy consensus
>>
>>> What is the "special power" of the release manager vs other committers?
>>
>> none but none should be needed
>>
>> - robert
>
> *IMHO* we have the following possible releases:
>
> - 2.3.1 : IMHO everything is ready in v2.3 (as I wrote in the recent
> "About 2.3.1" topic) and only need someone to take care of it (I can
> do if asked, but I would prefer if someone else do)
Well i allready did most of the merging. So i can step in if noone is
against this ;-)
>
> - 2.4.0 : (ex next-minor) has been proposed by Noel and Vincenzo. If
> they still have this in their plans IMHO one of them can be the
> release manager and branch "v2.4" from current "v2.3" and start the
> "vetted backports" (as per Noel mails)
>
> - 2.5.0 / 3.0.0: (ex next-major) sooner or later trunk should (IMHO)
> be branched to start consolidation and release something. We agreed on
> this generically but have not found a solution. Now you are the most
> active in trunk, so maybe you will take care of understanding what can
> be done and when.
>
> I personally don't care of 2.4.0 (next-minor). I'm willing to help for
> 2.3.1 if asked, and to help with 2.5.0/3.0.0 (once I'll have
> understood what can be done there).
Same here.
>
> Stefano
bye
Norman
--
Mit freundlichen Grüßen
i.A. Norman Maurer
Systemadministrator
ByteAction GmbH
Auf der Beune 83-85
64839 Münster
Phone: +49 (0) 60 71 92 16 - 21
Fax: +49 (0) 60 71 92 16 - 20
E-mail: nm@byteaction.de
Internet: www.byteaction.de
AG Darmstadt, HRB 33271
Ust-Id: DE206997247
GF: Thomas Volkert
------------------------------------------------------
Diese E-Mail enthält vertrauliche Informationen und ist nur für den in der E-Mail genannten Adressaten bestimmt. Für den Fall, dass der Empfänger dieser E-Mail nicht der in der E-Mail benannte Adressat ist, weisen wir darauf hin, dass das Lesen, Kopieren, die Wiedergabe, Verbreitung, Vervielfältigung, Bekanntmachung, Veränderung, Verteilung und/oder Veröffentlichung der E-Mail strengstens untersagt ist. Bitte verständigen Sie den Absender dieser E-Mail unter folgender Rufnummer +49 (0) 6071 / 9216-0, falls Sie irrtümlich diese E-Mail erhalten haben und löschen Sie diese E-Mail. Der Inhalt dieser E-Mail ist nur rechtsverbindlich, wenn er von unserer Seite schriftlich durch Brief oder Telefax bestätigt wird. Die Versendung von E-Mails an uns hat keine fristwahrende Wirkung.
This e-mail contains information which is privileged and is intended only for the Addressee named in the e-mail. In case that the recipient of this e-mail is not the named addressee, we would like to inform you that it is strictly prohibited to read, to reproduce, to disseminate, to copy, to disclose, to modify, to distribute and/or to publish this e-mail. If you have received this e-mail in error, please call the sender under following telephone number +49 (0) 6071 / 9216-0 and delete this e-mail. The content of this e-mail is not legally binding unless confirmed by letter or telefax. E-mails which are sent to us do not constitute compliance with any time limits or deadlines.
------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: [VOTE RESULT] InetAddress unbounded cache patch backport
Posted by robert burrell donkin <ro...@gmail.com>.
On 2/10/07, Stefano Bagnara <ap...@bago.org> wrote:
> robert burrell donkin ha scritto:
<snip>
> > we need to elect a release manager who can shepherd the release
> > through these difficult waters. we need to take a release branch ASAP
> > so the short term push towards a release can be separated from medium
> > term concerns about design and maintainability.
>
> I agree. How is a release manager elected?
by an election ;-)
typically lazy consensus
> What is the "special power" of the release manager vs other committers?
none but none should be needed
- robert
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: [VOTE RESULT] InetAddress unbounded cache patch backport
Posted by Stefano Bagnara <ap...@bago.org>.
robert burrell donkin ha scritto:
> On 1/18/07, Noel J. Bergman <no...@devtech.com> wrote:
>> Oh good ... so now JAMES functionality is going to depend upon a local
>> modification to the container launching it?
>
> running in a container introduces a coupling of functionality to the
> container
We already depends on classloaders provided by the container for
mailets, I think this acceptable: we use a container, we try to use its
features. If we move to spring (as an example) we'll have to take care
to define a new place for mailets resources (SAR-INF is a phoenix
specific folder).
In fact the TTL issue is a "JVM issue/feature", the JVM is the container
of our container (phoenix) and our functionalities strictly depends on
both containers.
>> Does anyone believe that's a
>> maintainable solution, as we look at alternative runtime environments?
>
> but i definitely take your point: just doing this would be an
> unmaintainable solution going forward
The ttl issue is an issue to be resolved in containers: it is a security
property. I think it would be really dangerous and inappropriate to set
security properties inside component code.
On the other side trunk services already avoid using InetAddress at all
so we won't suffer this issue anymore.
> we need to elect a release manager who can shepherd the release
> through these difficult waters. we need to take a release branch ASAP
> so the short term push towards a release can be separated from medium
> term concerns about design and maintainability.
I agree. How is a release manager elected? What is the "special power"
of the release manager vs other committers?
> but on trunk, we should implement the best medium term solution. this
> means implementing noel's fixes in a more elegant fashion.
>
> - robert
Trunk is not affected by this issue: we already fixed it long time ago.
We added the ttl properties there anyway to protect users from
InetAddress usage in their own mailets.
Stefano
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: [VOTE RESULT] InetAddress unbounded cache patch backport
Posted by robert burrell donkin <ro...@gmail.com>.
On 1/18/07, Noel J. Bergman <no...@devtech.com> wrote:
> Norman Maurer wrote:
>
> > i put the property in the startup(....) method of
> > org.apache.avalon.phoenix.launcher.Main . This method get called of each
> > entry point (Main, CommonsDameonLauncher, DaemonLauncher).
>
> Oh good ... so now JAMES functionality is going to depend upon a local
> modification to the container launching it?
running in a container introduces a coupling of functionality to the container
> Does anyone believe that's a
> maintainable solution, as we look at alternative runtime environments?
but i definitely take your point: just doing this would be an
unmaintainable solution going forward
> Please do NOT put this into trunk, since it is not necessary. Also, keep in
> mind that the faux TTL hack, if used, ought to be configurable.
it seems to me that the debate has become unnecessarily polarised
IMO we're in danger of losing focus
we need to elect a release manager who can shepherd the release
through these difficult waters. we need to take a release branch ASAP
so the short term push towards a release can be separated from medium
term concerns about design and maintainability.
releases are about those outside this circle of committers. for the
next release, we should think about them, set aside our disagreements
and do the right thing.
we should backport noel's fixes even if there design is less than
elegant. we should fix every startup script that we can in case any
calls have been missed even though this is an unmaintainable solution.
we should write clearly in the release notes that JAMES may be
effected by a known issue with some Sun JVMs causing memory leaks and
note the fix for those running in other environments. all this should
be done on the release branch.
but on trunk, we should implement the best medium term solution. this
means implementing noel's fixes in a more elegant fashion.
- robert
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: [VOTE RESULT] InetAddress unbounded cache patch backport
Posted by robert burrell donkin <ro...@gmail.com>.
On 1/20/07, Norman Maurer <nm...@byteaction.de> wrote:
<snip>
> For me the point is that we had a VOTE.. Everyone who voted should done
> this only if he think the stuff he voted for is correct and if he not
> voted he should accept any fix. After the VOTE we had a result and want
> to commit the fix. Now after we have a clear result the discuss start
> again.. We should do what the majory voted for... thats how it should work.
the trunk is CTR (commit then review) so the vote was an attempt to
gauge consensus about a controversial measure. my reading of the
results is that there is no consensus: rather the majority are
agnostic with two minority polarised positions.
IMO this is harmful
if both sides are still committed to developing a consensus, then the
best approach would be continue to analyze the problem and look for
superior technical or social solutions.
the alternative is for one of the twos to go forward and commit their
fix to trunk. this seems likely to result in both solutions being
veto'd (neither gained 3 +1's) and the next release shipping with the
problem unresolved.
all i'm asking is that all those with polarised positions take a step
back, take a deep breath and think about users. the right thing to do
is to ship the next release with both fixes but to patch only on the
release branch. the search for a superior solution can then happen on
trunk.
- robert
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: [VOTE RESULT] InetAddress unbounded cache patch backport
Posted by Norman Maurer <nm...@byteaction.de>.
robert burrell donkin schrieb:
> On 1/18/07, Noel J. Bergman <no...@devtech.com> wrote:
>> Norman Maurer wrote:
>>
>> > i put the property in the startup(....) method of
>> > org.apache.avalon.phoenix.launcher.Main . This method get called of
>> each
>> > entry point (Main, CommonsDameonLauncher, DaemonLauncher).
>>
>> Oh good ... so now JAMES functionality is going to depend upon a local
>> modification to the container launching it?
>
> running in a container introduces a coupling of functionality to the
> container
>
For me such a "property" belongs to the container .. And it seems im not
the only one who thinks so..
>> Does anyone believe that's a
>> maintainable solution, as we look at alternative runtime environments?
>
> but i definitely take your point: just doing this would be an
> unmaintainable solution going forward
Sorry i not understand.. Can you explain
>
>> Please do NOT put this into trunk, since it is not necessary. Also,
>> keep in
>> mind that the faux TTL hack, if used, ought to be configurable.
>
> it seems to me that the debate has become unnecessarily polarised
>
> IMO we're in danger of losing focus
>
> we need to elect a release manager who can shepherd the release
> through these difficult waters. we need to take a release branch ASAP
> so the short term push towards a release can be separated from medium
> term concerns about design and maintainability.
>
> releases are about those outside this circle of committers. for the
> next release, we should think about them, set aside our disagreements
> and do the right thing.
>
> we should backport noel's fixes even if there design is less than
> elegant. we should fix every startup script that we can in case any
> calls have been missed even though this is an unmaintainable solution.
> we should write clearly in the release notes that JAMES may be
> effected by a known issue with some Sun JVMs causing memory leaks and
> note the fix for those running in other environments. all this should
> be done on the release branch.
>
> but on trunk, we should implement the best medium term solution. this
> means implementing noel's fixes in a more elegant fashion.
>
> - robert
>
For me the point is that we had a VOTE.. Everyone who voted should done
this only if he think the stuff he voted for is correct and if he not
voted he should accept any fix. After the VOTE we had a result and want
to commit the fix. Now after we have a clear result the discuss start
again.. We should do what the majory voted for... thats how it should work.
bye
Norman
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: [VOTE RESULT] InetAddress unbounded cache patch backport
Posted by robert burrell donkin <ro...@gmail.com>.
On 1/20/07, Jürgen Hoffmann <jh...@byteaction.de> wrote:
> > -----Ursprüngliche Nachricht-----
> > Von: robert burrell donkin [mailto:robertburrelldonkin@gmail.com]
<snip>
> > we should backport noel's fixes even if there design is less than
> > elegant. we should fix every startup script that we can in case any
> > calls have been missed even though this is an unmaintainable solution.
> > we should write clearly in the release notes that JAMES may be
> > effected by a known issue with some Sun JVMs causing memory leaks and
> > note the fix for those running in other environments. all this should
> > be done on the release branch.
>
> So you are suggesting to do both? What is the benefit of doing both?
take a release branch and commit both on that branch only. together
they cover more use cases than either alone.
> > but on trunk, we should implement the best medium term solution. this
> > means implementing noel's fixes in a more elegant fashion.
>
> I think it was pointed out, that Noels fixes broke some serious design
> considerations.
>
> I think the 2 parties should come together and work on a new solution, which
> is suitable for everyone.
+1
but IMO it's expedient to patch the release branch so that a release
can be cut without the bug
- robert
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
AW: [VOTE RESULT] InetAddress unbounded cache patch backport
Posted by Jürgen Hoffmann <jh...@byteaction.de>.
Hi,
> -----Ursprüngliche Nachricht-----
> Von: robert burrell donkin [mailto:robertburrelldonkin@gmail.com]
> Gesendet: Samstag, 20. Januar 2007 09:32
> An: James Developers List
> Betreff: Re: [VOTE RESULT] InetAddress unbounded cache patch backport
>
> On 1/18/07, Noel J. Bergman <no...@devtech.com> wrote:
> > Norman Maurer wrote:
> >
> > > i put the property in the startup(....) method of
> > > org.apache.avalon.phoenix.launcher.Main . This method get called of
> each
> > > entry point (Main, CommonsDameonLauncher, DaemonLauncher).
> >
> > Oh good ... so now JAMES functionality is going to depend upon a local
> > modification to the container launching it?
>
> running in a container introduces a coupling of functionality to the
> container
So are we going to have a 2.3 based release that ist o be run in another
container?
Did I miss something?
> > Does anyone believe that's a
> > maintainable solution, as we look at alternative runtime environments?
>
> but i definitely take your point: just doing this would be an
> unmaintainable solution going forward
I keeping backward compatibility to jdk <1.3 a good thing when someone wants
to look forward?
> > Please do NOT put this into trunk, since it is not necessary. Also,
> keep in
> > mind that the faux TTL hack, if used, ought to be configurable.
>
> it seems to me that the debate has become unnecessarily polarised
>
> IMO we're in danger of losing focus
That was lost a long time ago. It is no objective discussion. It has never
been. It is 2 parties, who are incapable of looking at the others viewpoint.
That is sad!
> we need to elect a release manager who can shepherd the release
> through these difficult waters. we need to take a release branch ASAP
> so the short term push towards a release can be separated from medium
> term concerns about design and maintainability.
Really? I suggested this a long time ago. But certain people did not want to
do it. because of their own reasons. The Person that wanted to do it was
flamed. That is sad!
> releases are about those outside this circle of committers. for the
> next release, we should think about them, set aside our disagreements
> and do the right thing.
see previous paragraph.
> we should backport noel's fixes even if there design is less than
> elegant. we should fix every startup script that we can in case any
> calls have been missed even though this is an unmaintainable solution.
> we should write clearly in the release notes that JAMES may be
> effected by a known issue with some Sun JVMs causing memory leaks and
> note the fix for those running in other environments. all this should
> be done on the release branch.
So you are suggesting to do both? What is the benefit of doing both?
> but on trunk, we should implement the best medium term solution. this
> means implementing noel's fixes in a more elegant fashion.
I think it was pointed out, that Noels fixes broke some serious design
considerations.
I think the 2 parties should come together and work on a new solution, which
is suitable for everyone.
Juergen
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: [VOTE RESULT] InetAddress unbounded cache patch backport
Posted by Norman Maurer <nm...@byteaction.de>.
Ups,
i missed a word. Replace "i" with "i whould".
bye
Norman
Norman Maurer schrieb:
> Hi Stefano,
>
> i put the property in the startup(....) method of
> org.apache.avalon.phoenix.launcher.Main . This method get called of each
> entry point (Main, CommonsDameonLauncher, DaemonLauncher).
>
> Just my 2 cent ;-)
>
>
> bye
> Norman
>
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: [VOTE RESULT] InetAddress unbounded cache patch backport
Posted by Stefano Bagnara <ap...@bago.org>.
Norman Maurer wrote:
> Hi Stefano,
>
> i put the property in the startup(....) method of
> org.apache.avalon.phoenix.launcher.Main . This method get called of each
> entry point (Main, CommonsDameonLauncher, DaemonLauncher).
>
> Just my 2 cent ;-)
I think you're right, it is the best place.
I thought about adding a new entry point to not change phoenix, but it
is more code and less clean, so I will stick to your proposal.
Stefano
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
RE: [VOTE RESULT] InetAddress unbounded cache patch backport
Posted by "Noel J. Bergman" <no...@devtech.com>.
Norman Maurer wrote:
> i put the property in the startup(....) method of
> org.apache.avalon.phoenix.launcher.Main . This method get called of each
> entry point (Main, CommonsDameonLauncher, DaemonLauncher).
Oh good ... so now JAMES functionality is going to depend upon a local
modification to the container launching it? Does anyone believe that's a
maintainable solution, as we look at alternative runtime environments?
Please do NOT put this into trunk, since it is not necessary. Also, keep in
mind that the faux TTL hack, if used, ought to be configurable.
--- Noel
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: [VOTE RESULT] InetAddress unbounded cache patch backport
Posted by Norman Maurer <nm...@byteaction.de>.
Hi Stefano,
i put the property in the startup(....) method of
org.apache.avalon.phoenix.launcher.Main . This method get called of each
entry point (Main, CommonsDameonLauncher, DaemonLauncher).
Just my 2 cent ;-)
bye
Norman
Stefano Bagnara schrieb:
> Serge voted since the last update, so this is the final result.
> It has been a complicate and long vote, but we finally have a majority
> agreement on the
> java.security.Security.setProperty("networkaddress.cache.ttl" , "0");
> solution.
>
> The agreed solution is the one that we didn't do already so we have to
> code it: I will try to do the work on trunk asap first, then we can
> backport.
>
> Stefano
>
> Here is the detail of the vote result:
>
> Stefano Bagnara wrote:
>> 3 full weeks passed, and this is an update of this running vote.
>>
>> Stefano Bagnara wrote:
>>> 1) Backport the custom static access to DNSServer.
>>> http://svn.apache.org/viewvc?view=rev&revision=470929
>>
>> -1 Stefano (binding)
>> -0 Norman (binding)
>> -0 Joachim
>> +0 Danny (binding)
>> +1 Noel (binding) (*)
> -0 Serge (binding)
>
>>> 2) Backport sun jvm specific fix to JAMES-679:
>>> http://svn.apache.org/viewvc?view=rev&revision=473041
>>
>> +1 Stefano (binding)
>> +1 Norman (binding)
>> +0.9 Joachim
>> +0 Danny (binding)
>> -1 Noel (binding) (*)
> -0 Serge (binding)
>
>>> 3) Define where to add the
>>> "java.security.Security.setProperty("networkaddress.cache.ttl" ,
>>> "0");" apply it to trunk and backport it (if you vote this please
>>> tell your preferences about the place to add this code).
>>
>> +0.8 Stefano (binding)
>> +0.5 Norman (binding) (updated to +1 if the code is placed in
>> phoenix-loader)
>> +1 Joachim
>> +0 Danny (binding)
>> -1 Noel (binding) (*)
> +1 Serge (binding) Where norman said is fine.
>
>> (*) Noel did not vote but wrote this: "Any option that does not
>> eliminate the use if InetAddress and unify the cache structure is
>> unacceptable to me." that I "interpreted" as "+1" for "1)" and "-1"
>> for "2)" and "3)"
>>
>> Each solution received at least a -1. The current total (sum) for
>> each solution for binding votes is the following (in brackets you see
>> the result counting the not-binding votes too):
>>
>> 1) +0 (+0)
>> 2) +1 (+1.9)
>> 3) +0.8 (+1.8)
>>
>> Even if this currently gives the majority to my preferred solution I
>> will keep the vote open for a while more, for anyone willing to add
>> something after this summary because, as you can see, a single vote
>> can still change the whole result.
>>
>> I will close this on January, the 18th.
>>
>> Stefano
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
>> For additional commands, e-mail: server-dev-help@james.apache.org
>>
>>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
> For additional commands, e-mail: server-dev-help@james.apache.org
>
> !EXCUBATOR:1,45af4d9b39411758032478!
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
[VOTE UPDATE] InetAddress unbounded cache patch backport
Posted by Stefano Bagnara <ap...@bago.org>.
3 full weeks passed, and this is an update of this running vote.
Stefano Bagnara wrote:
> 1) Backport the custom static access to DNSServer.
> http://svn.apache.org/viewvc?view=rev&revision=470929
-1 Stefano (binding)
-0 Norman (binding)
-0 Joachim
+0 Danny (binding)
+1 Noel (binding) (*)
> 2) Backport sun jvm specific fix to JAMES-679:
> http://svn.apache.org/viewvc?view=rev&revision=473041
+1 Stefano (binding)
+1 Norman (binding)
+0.9 Joachim
+0 Danny (binding)
-1 Noel (binding) (*)
> 3) Define where to add the
> "java.security.Security.setProperty("networkaddress.cache.ttl" , "0");"
> apply it to trunk and backport it (if you vote this please tell your
> preferences about the place to add this code).
+0.8 Stefano (binding)
+0.5 Norman (binding) (updated to +1 if the code is placed in
phoenix-loader)
+1 Joachim
+0 Danny (binding)
-1 Noel (binding) (*)
(*) Noel did not vote but wrote this: "Any option that does not
eliminate the use if InetAddress and unify the cache structure is
unacceptable to me." that I "interpreted" as "+1" for "1)" and "-1" for
"2)" and "3)"
Each solution received at least a -1. The current total (sum) for each
solution for binding votes is the following (in brackets you see the
result counting the not-binding votes too):
1) +0 (+0)
2) +1 (+1.9)
3) +0.8 (+1.8)
Even if this currently gives the majority to my preferred solution I
will keep the vote open for a while more, for anyone willing to add
something after this summary because, as you can see, a single vote can
still change the whole result.
I will close this on January, the 18th.
Stefano
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: [VOTE UPDATE] InetAddress unbounded cache patch backport
Posted by Serge Knystautas <sk...@gmail.com>.
On 1/7/07, Stefano Bagnara <ap...@bago.org> wrote:
> 3 full weeks passed, and this is an update of this running vote.
>
> Stefano Bagnara wrote:
> > 1) Backport the custom static access to DNSServer.
> > http://svn.apache.org/viewvc?view=rev&revision=470929
>
> -1 Stefano (binding)
> -0 Norman (binding)
> -0 Joachim
> +0 Danny (binding)
> +1 Noel (binding) (*)
-0
> > 2) Backport sun jvm specific fix to JAMES-679:
> > http://svn.apache.org/viewvc?view=rev&revision=473041
>
> +1 Stefano (binding)
> +1 Norman (binding)
> +0.9 Joachim
> +0 Danny (binding)
> -1 Noel (binding) (*)
-0
> > 3) Define where to add the
> > "java.security.Security.setProperty("networkaddress.cache.ttl" , "0");"
> > apply it to trunk and backport it (if you vote this please tell your
> > preferences about the place to add this code).
>
> +0.8 Stefano (binding)
> +0.5 Norman (binding) (updated to +1 if the code is placed in
> phoenix-loader)
> +1 Joachim
> +0 Danny (binding)
> -1 Noel (binding) (*)
+1. Where norman said is fine.
--
Serge Knystautas
Lokitech >> software . strategy . design >> http://www.lokitech.com
p. 301.656.5501
e. sergek@lokitech.com
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
RE: [VOTE] InetAddress unbounded cache patch backport
Posted by "Noel J. Bergman" <no...@devtech.com>.
>>> Make sure our container use an expiration for cached dns data
>>> https://issues.apache.org/jira/browse/JAMES-679
>>> This one is a workaround that would avoid JAMES-592 to happen, with no
>>> changes to the code.
>> It disables the cache, and that means taking a performance hit on most
>> lookups. I get 100's of 1000s of connections daily, and they do tend to
>> come in waves from the same IP, so I would not get the benefit from
having
>> already done the lookup. Plus, when dnsjava goes to process the IP, we
>> would not have already populated it into the cache.
> You told that the IPs are very different in your request and hardly
> repeated (you told this).
As I said, they tend to come in batches. Over the past 20 hours, we have
had about 150K connections, of which about 10K were duplicates within a
fraction of a second. These would result in redundant queries, as would
others over a period of time.
I really don't understand why you steadfastly refuse to allow anyone to
apply the same quality of fix to JAMES that we have already applied to
trunk. Unless that is your actual goal: to prevent effective changes on v2,
so that only trunk can be developed.
--- Noel
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: [VOTE] InetAddress unbounded cache patch backport
Posted by Stefano Bagnara <ap...@bago.org>.
Noel J. Bergman wrote:
> Stefano Bagnara wrote:
>
>> In the mean time I fixed the following DNSServer related bugs in Trunk
>
> I can review the code changes, but I seem to recall that we can much
> backport the entire DNSServer from trunk, so long as we preserve the static
> method rather than change the deployment descriptors.
>
> A couple of specifics:
>
>> DNSServer does not properly cache MX lookups for CNAMEd domains
>> https://issues.apache.org/jira/browse/JAMES-672
>
> We should review this again, because there are rules against allowing a
> CNAME as the target of an MX record.
You (probably) misunderstood the problem. I spoke about MX lookups for
CNAMEd domains and not of CNAMEs used as MX records. This is a
completely different story ;-)
Btw feel free to overview that code: 2 more eyes are always helpful.
In the issue comment I explained exactly what was the problem and what
are the iteresting rfc paragraphs. I also added a test case for this
problem, so it should be really easy to review it.
>> Make sure our container use an expiration for cached dns data
>> https://issues.apache.org/jira/browse/JAMES-679
>
>> This one is a workaround that would avoid JAMES-592 to happen, with no
>> changes to the code.
>
> It disables the cache, and that means taking a performance hit on most
> lookups. I get 100's of 1000s of connections daily, and they do tend to
> come in waves from the same IP, so I would not get the benefit from having
> already done the lookup. Plus, when dnsjava goes to process the IP, we
> would not have already populated it into the cache.
You told that the IPs are very different in your request and hardly
repeated (you told this). So it should not change to much your
performance ;-)
> The correct fix is in trunk (and in my patch). I don't understand why
> people insist on forcing a crippled fix on v2.3 when we have already made
> the correct one in trunk.
"Correct" or I would better say "appropriate" seems to be subject to our
technical ideas.
>> This is why I remove the "full backport from trunk" from the options,
>> because as Noel pointed out, we would break assembly.xml compatibility
>> and we cannot do this in a point release.
>
> As I said, I will need to review the two branches, but we can look at
> backporting the entire DNSServer from trunk, so that we do not have major
> code differences between the two. All that we need to do for compatibility
> is introduce the static method in the v2.3 branch so that the client code
> can call it without the assembly issue.
The main purpose of my latest fixes in trunk has been to remove any
static usage of the Lookup class. This means that you will have to
change the code to backport it if you don't want to change the assembly.
Using a single static will be not enough. You will have to switch every
configuration/attribute of dnsserver to static fields. I believe this is
not a good choice for 2.3.1, too much changes considering we have
alternative workarounds.
>> 3) Define where to add the
>> "java.security.Security.setProperty("networkaddress.cache.ttl" , "0");"
>> apply it to trunk and backport it (if you vote this please tell your
>> preferences about the place to add this code).
>
> IIRC, it must happen before other things so placement in a container
> enviroment is interesting. I'm offline with no Internet access at the
> moment, so I can't check.
>
> Personally, I'd backport the DNSServer fixes, reintroduce the static method,
> and if we can find the right place add the networkaddress.cache.ttl as a
> catch-all for bad third party code.
>
> --- Noel
I think I understand you, but please put also vote numbers in addition
to all this sentences, so your opinion can be officially counted in the
vote result.
Stefano
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
RE: [VOTE] InetAddress unbounded cache patch backport
Posted by "Noel J. Bergman" <no...@devtech.com>.
Stefano Bagnara wrote:
> In the mean time I fixed the following DNSServer related bugs in Trunk
I can review the code changes, but I seem to recall that we can much
backport the entire DNSServer from trunk, so long as we preserve the static
method rather than change the deployment descriptors.
A couple of specifics:
> DNSServer does not properly cache MX lookups for CNAMEd domains
> https://issues.apache.org/jira/browse/JAMES-672
We should review this again, because there are rules against allowing a
CNAME as the target of an MX record.
> Make sure our container use an expiration for cached dns data
> https://issues.apache.org/jira/browse/JAMES-679
> This one is a workaround that would avoid JAMES-592 to happen, with no
> changes to the code.
It disables the cache, and that means taking a performance hit on most
lookups. I get 100's of 1000s of connections daily, and they do tend to
come in waves from the same IP, so I would not get the benefit from having
already done the lookup. Plus, when dnsjava goes to process the IP, we
would not have already populated it into the cache.
The correct fix is in trunk (and in my patch). I don't understand why
people insist on forcing a crippled fix on v2.3 when we have already made
the correct one in trunk.
> With this vote I'm trying to fix the v2.3 branch backport for 2.3.1
> release (so this is not necessarily related to next-minor).
I appreciate that you are willing to come around.
> This is why I remove the "full backport from trunk" from the options,
> because as Noel pointed out, we would break assembly.xml compatibility
> and we cannot do this in a point release.
As I said, I will need to review the two branches, but we can look at
backporting the entire DNSServer from trunk, so that we do not have major
code differences between the two. All that we need to do for compatibility
is introduce the static method in the v2.3 branch so that the client code
can call it without the assembly issue.
> 3) Define where to add the
> "java.security.Security.setProperty("networkaddress.cache.ttl" , "0");"
> apply it to trunk and backport it (if you vote this please tell your
> preferences about the place to add this code).
IIRC, it must happen before other things so placement in a container
enviroment is interesting. I'm offline with no Internet access at the
moment, so I can't check.
Personally, I'd backport the DNSServer fixes, reintroduce the static method,
and if we can find the right place add the networkaddress.cache.ttl as a
catch-all for bad third party code.
--- Noel
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org