On 2/1/07, David Woldrich <[EMAIL PROTECTED]> wrote:
Do I have your attention yet? :)
Yes :-)
I understand there are architectural thingies in James to consider and
phoenix and whatnot. I understand that there's a lot of time and
investment in the existing architecture. And I'm not sugges
On 2/1/07, Stefano Bagnara <[EMAIL PROTECTED]> wrote:
Unfortunately I think that hot redeployable mailets are far away,
the biggest issue is that you would have to move all "in process"
messages to a save point that you know will allow them to continue
after you have changed the whole processi
Author: bago
Date: Fri Feb 2 11:57:28 2007
New Revision: 502706
URL: http://svn.apache.org/viewvc?view=rev&rev=502706
Log:
Revert r473041 because we voted for the Security.setProperty solution instead
of the sun specific one (JAMES-679 / JAMES-592)
Modified:
james/server/trunk/phoenix-bin/b
Author: bago
Date: Fri Feb 2 12:04:26 2007
New Revision: 502713
URL: http://svn.apache.org/viewvc?view=rev&rev=502713
Log:
Applied a default 300seconds ttl to InetAddress positive cache (JAMES-679 /
JAMES-592)
This can be tuned via the System property "networkaddress.cache.ttl". Setting
it to 0
+1
Thx for took care :-)
bye
Norman
[EMAIL PROTECTED] schrieb:
> Author: bago
> Date: Fri Feb 2 12:04:26 2007
> New Revision: 502713
>
> URL: http://svn.apache.org/viewvc?view=rev&rev=502713
> Log:
> Applied a default 300seconds ttl to InetAddress positive cache (JAMES-679 /
> JAMES-592)
> Thi
As we decided in "[VOTE RESULT] InetAddress unbounded cache patch
backport" I will backport this fix on the v2.3 in 3 days.
While working on the fix I decided to publish the Security.setProperty
configuration as a system property so that the default behaviour of the
phoenix laucher jar is not
