Glyn, How about a variation of your "Engine Replacement" based on EngineConfiguration *versioning*. This can make it easy on the resources (won't require another Engine instance) and simple for config providers. Here is how it would work:
When request first comes in: - Engine calls getConfig() like right now - The Engine then calls config.getVersionStamp() and places it in the request context parameters Any subsequent processing of request in a chain of handlers: - Engine calls getConfig(requestContext.getConfigVersionStamp()) When deploying/undeploying/redeploying - The config provider would take care of proper versioning procedures. No other component has to care about it. Our current file/simple providers won't have to change a bit. They won't support versioning (i.e. it's always latest anyways). And then, if a config provider is implemented over a DB or JNDI it can support versioning properly, thus allowing for safe dynamic config changes. Let me know what you guys think about it. I can submit a few code changes to implement this, I needed it myself :). -- Igor Sedukhin .. ([EMAIL PROTECTED]) -- (631) 342-4325 .. 1 CA Plaza, Islandia, NY 11788 -----Original Message----- From: Glyn Normington [mailto:[EMAIL PROTECTED]] Sent: Friday, February 01, 2002 4:37 AM To: [EMAIL PROTECTED] Subject: RE: Subsystem responsibilities: WSDD Igor, Let's be clear: as things currently stand, changing the configuration of an engine while requests are being processed can give unpredictable results (like the case in your second paragraph below). This is not good. The current notification mechanism (AxisEngine.refreshGlobalOptions) prompts the engine to reload its global options from the EngineConfiguration, but doesn't solve the above problem. The problem we need to solve is that changing an engine's configuration should not affect requests which have already started executing against that engine for the reasons you point out. Glen and I discussed a couple of approaches. Here's my current thinking... Locking ------- A simplistic locking solution could have some rather nasty effects on a production system. Such a scheme would hold off new requests while allowing existing requests to complete (their traversal of the configured Chains and Handlers) before allowing an EngineConfiguration to be replaced. One difficulty is that requests may hit network delays before completing their traversal and so new requests could be held up for an extended period of time. Another difficulty is that, since there is currently no per-request state in an engine, there is no easy way for an engine to know that incomplete requests are still using an engine instance. Adding per-request state is obviously possible but is likely to impact request performance. If -- and it's a BIG 'if' -- there are scenarios involing a distributed (i.e. via the network) loop back to an engine instance that is being reconfigured, then we could hit a distributed deadlock, so we'd probably need some kind of timeout so that new requests (including any looping back) would not block indefinitely waiting for the engine to be reconfigured. Engine Replacement ------------------ A scheme which would be less disruptive to the flow of requests would be to ensure that any particular request runs to completion against a fixed EngineConfiguration while new requests are allowed to pick up a replacement EngineConfiguration. The simplest way to achieve that is replace engine instances wholesale (i.e. modify a deep copy or reconstruct from scratch) and switch new requests to the new engine instance but allow existing requests to use the former engine instance(s). Doug pointed out that this makes reconfiguration relatively expensive in terms of pathlength, but I have tried to argue that, when it matters, the frequency of reconfiguration is orders of magnitude lower than request frequency, so the pathlength of reconfiguration is irrelevent (unless it ran into tens of millions of instructions or more). And there may be other alternatives. I hope Glen will share his current thinking. My comment #5 below simply reflected that Glen and I had discussed this issue, not that we had concluded what to do about it! Glyn "Sedukhin, Igor" To: [EMAIL PROTECTED], Glyn Normington/UK/IBM@IBMGB <Igor.Sedukhin cc: @ca.com> Subject: RE: Subsystem responsibilities: WSDD 31/01/02 23:33 Glyn, How exactly is notification in 5 should be done? Should it be done at all? Engine builds the pipeline dynamically when request comes. It does not seem to cache handlers in any way (unless I missed something). That is it'll ask EngineCongiguration everytime, and so, if the information was updated in the configuration provider, it'll be used right there. Why notify the enhine then? My biggest concern is (and was for a while) consistency of the pipeline when deployment and request processing are done at the same time. For example, a request is a half way through the chains and then an independent thread is redeploying something. The other half of the chains can already be processed with the updated deployment info which obviously may not be consistent with the processed first half. :) This may become quite a problem in a production system that cannot be brought down for redeployment. I thought that we should change the AxisEngine to provide a momentary locking capability based on a resource sync. -- Igor Sedukhin .. ([EMAIL PROTECTED]) -- (631) 342-4325 .. 1 CA Plaza, Islandia, NY 11788 -----Original Message----- From: Glyn Normington [mailto:[EMAIL PROTECTED]] Sent: Thursday, January 24, 2002 4:51 AM To: [EMAIL PROTECTED] Subject: Subsystem responsibilities: WSDD Glen Daniels and I are working to improve the modularity of Axis's "configuration" subsystem and are collecting together the WSDD-related responsibilities and removing them from the non-config. parts of Axis such as AxisEngine. We discussed this on the 'phone yesterday and put some sandbox code in a 'config-work' cvs branch which we aim to improve and merge into the main trunk in the next few days. Here are some points we discussed: 1. The configuration, e.g. as defined in WSDD, defines factory classes, options, and scopes for various handler types. 2. The configuration from an engine's perspective consists of a handler 'registry' (i.e. a collection of factories) and some 'global' options. We should introduce an EngineConfiguration interface to provide access to this configuration information by an engine. 3. Three is a fairly close relationship between configuration providers and the registry. Both are really part of the "configuration" subsystem. The engine should ideally not be aware of the distinction between configuration providers and registries so long as it has access to the EngineConfiguration that it needs. 4. The engine should not be directly involved in the details of how the configuration is constructed or modified as that tends to pull in types which are specific to particular configuration mechanisms such as WSDD. 5. An engine's configuration should be modified by getting hold of its EngineConfiguration, modifying that, and then notifying the engine so it can refresh its global options (and potentially other information). Glyn
