Return-Path: Mailing-List: contact tomcat-dev-help@jakarta.apache.org; run by ezmlm Delivered-To: mailing list tomcat-dev@jakarta.apache.org Received: (qmail 14041 invoked from network); 20 Jul 1999 21:43:26 -0000 Received: from mercury.sun.com (192.9.25.1) by apache.org with SMTP; 20 Jul 1999 21:43:26 -0000 Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id OAA03248 for ; Tue, 20 Jul 1999 14:43:25 -0700 (PDT) Received: from taller.eng.sun.com (taller.Eng.Sun.COM [129.144.174.34]) by engmail2.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with SMTP id OAA00795 for ; Tue, 20 Jul 1999 14:43:25 -0700 (PDT) Received: from eng.sun.com by taller.eng.sun.com (SMI-8.6/SMI-SVR4) id OAA01985; Tue, 20 Jul 1999 14:43:22 -0700 Message-ID: <3794EE1F.A98D643B@eng.sun.com> Date: Tue, 20 Jul 1999 14:46:07 -0700 From: James Todd Organization: Sun Microsystems X-Mailer: Mozilla 4.61 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: tomcat-dev@jakarta.apache.org Subject: Re: request for review: server/config discussion References: <3794DCB6.D7A9872E@eng.sun.com> <3794E650.D038BB6A@algroup.co.uk> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Ben Laurie wrote: > Much as I like the idea of notifying config changes, I think it is > likely to lead to trouble. Here's the problem in a nutshell: either you > notify in detail what the changes are, in which case we are looking at > horrendous complexity and likely lots of interesting failure modes, or > you just say "it's changed" in which case you only need a single module > that requires a restart (canonical example: Apache listeners - these > cannot change without a restart) and every change gives you a restart > anyway. > this is why i'm presently (informally in this list and a small bit more formally in the discussion doc) piloting the idea of "passive" notification from the perspective of the config service. it could be that an api is provided via the service to "check" the freshness (born on date) of the data and leave it up to the client (eg server) to do with what it may with the results. another passive means might be to throgh some sort of exception indicating that "data you've obtained from me has since been modified." this just feels right at this stage in the game. we could up the ante a bit and consider an active notification scheme whereby the config service persists a reference to clients (listeners) and broadcasts changes accordingly. i'm a proponent of "passive" notification as 1) it is likely better then what is available today, 2) the api and subsequent implementations are rather trivial and 3) it doesn't too tightly couple subscribers of a service nor mandate too much behaviour. hope this helps, - james