axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Sedukhin, Igor" <>
Subject RE: Subsystem responsibilities: WSDD
Date Mon, 04 Feb 2002 14:20:07 GMT

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 .. (
-- (631) 342-4325 .. 1 CA Plaza, Islandia, NY 11788

-----Original Message-----
From: Glyn Normington [] 
Sent: Friday, February 01, 2002 4:37 AM
Subject: RE: Subsystem responsibilities: WSDD


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

Glen and I discussed a couple of approaches. Here's my current thinking...


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!


                    Igor"                To:, Glyn Normington/UK/IBM@IBMGB
                    <Igor.Sedukhin       cc:                                          
          >             Subject:     RE: Subsystem responsibilities: WSDD
                    31/01/02 23:33                                                       


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

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 .. (
-- (631) 342-4325 .. 1 CA Plaza, Islandia, NY 11788

-----Original Message-----
From: Glyn Normington []
Sent: Thursday, January 24, 2002 4:51 AM
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

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).


View raw message