Re: Configuration, take2

[Alexey Parshin <alexeyp@gmail.com>]

In a cluster, it may make sense to have a network exchange of configs :)

On 4/29/05, Ilya A. Volynets-Evenbakh <ilya@total-knowledge.com> wrote:
> Come to think of it - it may make sense - i.e. in large cluster,
> where bunch of app servers share config...
> Don't know.. Maybe it doesn't...
> 
> Alexey Parshin wrote:
> 
> >Well, since we figured out - it would be one such object in the
> >memory, SQL implementation doesn't make sense anymore.
> >
> >On 4/29/05, Ilya A. Volynets-Evenbakh <ilya@total-knowledge.com> wrote:
> >
> >
> >>Since it is two days after tomorrow already, I'm making executive-level
> >>desision ;-)
> >>1. We'll have Configuration as "main" object. That is it'll create all
> >>application containers,
> >>    load/unload servlets, etc.
> >>2. Configuration is going to be an abstract interface, that will be
> >>extended to provide
> >>    persistant storage interface
> >>3. There will be semi-rigid structure for now
> >>    Global server params
> >>       Application
> >>          AppName (used as session cookie name)
> >>          SessionTimeout
> >>          Param
> >>          Param
> >>          ...
> >>          Servlet
> >>              Param
> >>              Param
> >>              ...
> >>          Servlet
> >>          ...
> >>       Application
> >>          AppName (used as session cookie name)
> >>          SessionTimeout
> >>          Param
> >>          Param
> >>          ...
> >>          Servlet
> >>              Param
> >>              Param
> >>              ...
> >>          Servlet
> >>          ...
> >>       ...
> >>4. I'll write one implementation (probably similar to web.xml)
> >>5. HSquirrel will write SQL-based implementation
> >>
> >>Today is still not too late to object - tomorrow there will be too much
> >>code written ;-)
> >>
> >>
> >>Alexey Parshin wrote:
> >>
> >>
> >>
> >>>.zZz. :)
> >>>
> >>>Let's talk tomorrow..
> >>>
> >>>On 4/26/05, Ilya A. Volynets-Evenbakh <ilya@total-knowledge.com> wrote:
> >>>
> >>>
> >>>
> >>>
> >>>>After even more thought, there is yet another question:
> >>>>who will monitor config changes, and who will trigger reload of relevant
> >>>>parts?
> >>>>i.e. we could make ServerConfigElement class, that provides
> >>>>registerChangeListener
> >>>>interface, and have all interested parties (like RequestDispatcher,
> >>>>ServletContainer etc.)
> >>>>register listeners and reload servlet on config change.
> >>>>Or we could have ServerConfig class actually be the one that *creates*
> >>>>all the objects,
> >>>>and feeds them to RequestDispatcher (i.e. through addServlet function).
> >>>>Then it would
> >>>>be ServerConfig implementer's responsibility to make sure all relevant
> >>>>servlets are reloaded
> >>>>on configuration change.
> >>>>
> >>>>Can someone think of real-life scenarios? I'm too sleeppy right now ;-)
> >>>>
> >>>>   Ilya.
> >>>>
> >>>>Ilya A. Volynets-Evenbakh wrote:
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>>Wait wait... Why are we even talking about "changing". Generally I presume
> >>>>>that if config is changed, it is changed by admin, and then whole domain
> >>>>>that
> >>>>>change affected gets reloaded. I.E. if it was servlet-specific param,
> >>>>>servlet is reloaded
> >>>>>and if app-level, then all servlets in that app... In case of Java-based
> >>>>>app servers,
> >>>>>whole app is always reloaded (and in case you change one of server
> >>>>>config files,
> >>>>>it's your job as admin to make sure server finds out about that).
> >>>>>
> >>>>>In that light, it makes no sense to keep config itself (as in "XML DOM")
> >>>>>in memory. Instead there
> >>>>>are certain objects that get created as a result, and they exist as long
> >>>>>as their domain exists.
> >>>>>i.e. right now I only have one ServletContext - it's just a static
> >>>>>variable that is initialized on startup.
> >>>>>However, when we create whole "Application" support, there will be
> >>>>>multiple contexts - one per app.
> >>>>>App-level parameters will be kept there. Then there is ServletContainer
> >>>>>object - these can keep per-servlet
> >>>>>params. etc.
> >>>>>
> >>>>>Alexey Parshin wrote:
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>>I'm not that concerned about enforcing yet. However the speed and ease
> >>>>>>of use for the 1 is the best. We keep everything in memory, we save
> >>>>>>changes from time to time. Every changed option group can be
> >>>>>>validated, and we can always define the validation routine.
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>--
> >>>>Ilya A. Volynets-Evenbakh
> >>>>Total Knowledge. CTO
> >>>>http://www.total-knowledge.com
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>
> >>>
> >>>
> >>>
> >>--
> >>Ilya A. Volynets-Evenbakh
> >>Total Knowledge. CTO
> >>http://www.total-knowledge.com
> >>
> >>
> 


-- 
Alexey Parshin,

Senior DBA,
Tactical Telesolutions,
San Francisco