On 01/27/2010 10:21 AM, Andrew Stitcher wrote:
On Tue, 2010-01-26 at 17:27 -0500, Alan Conway wrote:
A work-in-progress fix to the management timer updates problem in a cluster.
Would appreciate any comments in particular on ways to get around the ordering
problem which not obvious to me:
https://issues.apache.org/jira/browse/QPID-2364
I haven't had a thorough look yet but some things come to mind:
1. If you've made Timer an interface with a small number of
implementations then I think this is the correct way to go. It's not
clear to me this is actually what you did.
I've added a second type of timer with 3 implementations. The existing Timer
remains for 3 reasons:
1. It supports absolute as well as periodic tasks and for this I only want to
support periodic tasks
2. Tasks for the new timer must be named so they can be co-ordinated across the
cluster.
3. There are several existing uses of Timer which should _not_ be multicast as
they deal with things without cluster-wide relevance (e.g. heartbeats) or that
already have cluster-safe solutions (e.g. message TTL)
2. PeriodicTimer is a crummy name. Call the Base interface Timer as it
is already or TimerBase. Then call the implementations StandaloneTimer
and ClusterSafeTimer or some names like that.
It is a crummy name. The name needs to be distinct from Timer, and should convey
"timer that you should use for periodic tasks that need to be co-ordinated in a
cluster". Any suggestions?
3. The ClusterSafeTimer implementation should be with the cluster code
not in qpid/sys.
It is.
4. I'm unclear whether all Timer events would need to ClusterSafe or not
or just some of them.
Just some see above. Currently only management periodic processing.
5. To get round the ordering issue perhaps hang on the multiphase plugin
load. Ie change Management init until all plugins loaded. Management
isn't a plugin itself is it. Perhaps I missed an important issue that
stops you doing this.
Maybe you need to register the ClusterSafeTimer with the Broker object
very early in the plugin init.
The trick is that management registers its tasks *before* plugin init.
I solved this with a 3rd timer implementation. It stores up tasks that are added
during init and delegates them to the real impl. The real impl is supplied by
the cluster plugin or broker supplies the standalone impl at the end of init if
there's no cluster plugin.
Hope these random thoughts help.
They do, thanks! Any ideas for a better name?
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:[email protected]
