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
