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 2007/01/08 01:04:51 UTC
[VOTE UPDATE] InetAddress unbounded cache patch backport
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 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