Home Help Center

IceStorm/ Timer Service ideas

stephanstephan Member Stephan StapelOrganization: Stephan StapelProject: BristolNG
Hi there,

I was recently playing around with IceStorm and have some questions on it: I was wondering what would be the best design pattern for using IceStorm as a TimerService, raising messages in certain intervals.

The first question is whether this is useful at all since timers could also be raised within an application itself, maybe there is no reason at all to do that in a distributed way. Please feel free to give comments on that!

However, when raising these events through IceStorm, what would be the best possible way to do that?
I was thinking about a remote object (let's called it TimerFactory) that particular apps might register to.
On registering, such an app gets a string in return which gives the channel/ topic where the events are sent to so that the app might register itself as a receiver of those events.
In the TimerFactory, a certain function gets called every x seconds such that the factory is able to decide whether to launch subsequent events into the topics that currently exist.

I hope that this description is precise enough (otherwise I could post a sequence diagram on that issue for further explanation). However, if you have a better design pattern for such a service, I'd be really glad to hear about that.

Kind regards,

Stephan

Comments

  • michimichi Member Michi HenningOrganization: Triodia TechnologiesProject: I have a passing interest in Ice :-) ✭✭✭
    Re: How to use IcePatch

    If you want to send a message at regular intervals along the lines of a clock tick, it would probably be easiest to simply write a client that invokes an operation on some interface in the server at fixed intervals.

    If you want to send the tick to many servers, it might be easier to use IceStorm because that conveniently takes care of redistributing the message to interested parties. This is particularly useful if you want to decouple the tick producer from the tick consumers: with IcePatch, the tick producer doesn't need to know who the consumers are.

    Be aware thought that IceStorm isn't a real-time service. There will be some clock skew due to the delays introduced during by the redistribution of the messages. (The skew will get worse the larger the number of consumers and the shorter the interval between ticks.) (If your ticks are spaced a second or more apart, skew will be minimal though, unless you have very large numbers of consumers.)

    If all the consumers are on the same LAN, I'd consider using UDP as a transport if scalability becomes a problem: you'll get much higher throughput with less clock skew that way (at the cost of losing the occasional message).

    Cheers,

    Michi.
  • stephanstephan Member Stephan StapelOrganization: Stephan StapelProject: BristolNG
    Re: Re: How to use IcePatch

    Thanks for the rapid answer, Michi!
    Originally posted by michi
    If you want to send a message at regular intervals along the lines of a clock tick, it would probably be easiest to simply write a client that invokes an operation on some interface in the server at fixed intervals.

    But that would only be possible if the interface of the server is available to the client whereas this wouldn't be required when using IceStorm...

    What also came into my mind when thinking about that particular problem is: Can't you offer patterns for such situations to the community or your customers? I think it would make life really easier when not having to re-invent the wheel every time on such a new platform, e.g. I suppose that I wouldn't be able to use the full potential of Ice because it's so new...
    (Sorry for posting that issue into the Help Center!)

    Stephan
  • michimichi Member Michi HenningOrganization: Triodia TechnologiesProject: I have a passing interest in Ice :-) ✭✭✭
    Re: Re: Re: How to use IcePatch
    Originally posted by stephan
    But that would only be possible if the interface of the server is available to the client whereas this wouldn't be required when using IceStorm...

    Hmmm... IceStorm is a typed event service. You always need an interface to invoke on, otherwise it's not possible to invoke anything. Remember, Ice does not have the equivalent of the CORBA Any type.
    What also came into my mind when thinking about that particular problem is: Can't you offer patterns for such situations to the community or your customers? I think it would make life really easier when not having to re-invent the wheel every time on such a new platform, e.g. I suppose that I wouldn't be able to use the full potential of Ice because it's so new...

    To be honest, I haven't come across this requirement as something that is common. Can you explain what you are building and why the tick messages are needed?

    We are happy to put things into the platform if we can see that the feature will be useful to a majority of customers. On the other hand, if the feature isn't useful to a majority, or if it can be easily implemented without platform support, we are inclined to leave it out.

    One of the things that make Ice attractive is its simplicity. And a lot of simplicitly comes from making hard decisions about what not to put into the platform as much as what to put into it...

    (Sorry for posting that issue into the Help Center!)

    Seems as good a place as any to me! :cool:

    Cheers,

    Michi.
  • stephanstephan Member Stephan StapelOrganization: Stephan StapelProject: BristolNG
    Re: Re: Re: Re: How to use IcePatch
    Originally posted by michi
    Hmmm... IceStorm is a typed event service. You always need an interface to invoke on, otherwise it's not possible to invoke anything. Remember, Ice does not have the equivalent of the CORBA Any type.

    sure, but if I create an interface such as

    interface Timer
    {
    void timer(long elapsedtime);
    };

    and use that one as the "event-type", everything should be fine for every client that subscribes.

    To be honest, I haven't come across this requirement as something that is common. Can you explain what you are building and why the tick messages are needed?

    sure I can. Or at least try to. What I'm thinking about are two things:

    The first one is an EAI tool where I generally would want to use data synchronisation (data change propagation) on a pure event basis, i.e. I generally want to be notified by data changes.
    On the other hand, one could also imagine to do a full-synchronisation (e.g. to a remote location) on a time basis, i.e. every night.
    However, to keep things together, I was thinking about a Workflow module that also is an Ice object and is being triggered for action after certain time slices.

    The other thing is that I might want to monitor certain directories, i.e. to poll them. That would also be done time-based.

    The question which then arises is whether I have to do things with distributed objects and why not to use local timers which invoke a pure local action.
    However, when doing a clean distributed design, I assume that one would want to have a central time aka timer authority within its environment. Do you have a different opinion on that?

    Kind regards,

    Stephan
  • michimichi Member Michi HenningOrganization: Triodia TechnologiesProject: I have a passing interest in Ice :-) ✭✭✭
    Re: Re: Re: Re: Re: How to use IcePatch
    Originally posted by stephan
    sure, but if I create an interface such as

    interface Timer
    {
    void timer(long elapsedtime);
    };

    and use that one as the "event-type", everything should be fine for every client that subscribes.

    Right. But that would be the case too if you were to directly invoke from the client on the server -- the presence of IceStorm doesn't change that picture, no?
    The first one is an EAI tool where I generally would want to use data synchronisation (data change propagation) on a pure event basis, i.e. I generally want to be notified by data changes.

    OK. But that isn't particularly related to a timer, is it? I think that can be done simply by emitting an event when a piece of state changes. (This is one of the typical uses of IceStorm.)
    On the other hand, one could also imagine to do a full-synchronisation (e.g. to a remote location) on a time basis, i.e. every night.
    However, to keep things together, I was thinking about a Workflow module that also is an Ice object and is being triggered for action after certain time slices.

    The other thing is that I might want to monitor certain directories, i.e. to poll them. That would also be done time-based.

    I see. No problem -- but I suspect that this is too specialized to be provided as a platform service. (BTW, if you haven't done so, check out IceUtil::Time -- it's a time class that is useful for doing this sort of thing.
    The question which then arises is whether I have to do things with distributed objects and why not to use local timers which invoke a pure local action.
    However, when doing a clean distributed design, I assume that one would want to have a central time aka timer authority within its environment. Do you have a different opinion on that?

    Hmmm... That's a very general question (and this isn't exactly my area of expertise...)

    The way I see it, a distributed clock is useful mainly if you have a situation where multiple independent parties must agree on absolute time. If so, you can either run local timers in each part of the system (and rely on time being synchronized across all parties), or you can use a central clock that instructs parts of the system to do things at a certain point in time.

    If you use a central clock, the problem is that you have propagation delays and that, when the clock ticks, a part of the system that is down misses the tick.

    If you use local time, you no longer have central control and clocks may drift. So, the crucial question seems to be whether the system really is command-driven, and the fact that commands arrive at specified intervals is just coincidental, or whether the system is time driven, in which case there really is no need for a central clock, provided that you can keep clocks synchronized (such as with ntp).

    So, I'd probably try and work out whether your system is command-driven or time-driven. If the former, I'd go with the centralized approach. If the latter, I'd probably go with synchronized clocks and local timers.

    Cheers,

    Michi.
Sign In or Register to comment.