Persistent messaging service

[stephan]

Hi there,

I know IceStorm and think it's quite efficient and elegant. However, in some cases, one requires a persistent messaging service with guaranteed delivery of messages.
I wonder whether you're planning on doing such a service or whether you alternatively would support the creation of a gpl-ed one.

regs,

Stephan

[marc]

We currently have no plans for an event service with persistent events.

As for the 2nd part of your question, we support all developments for Ice, including GPL'd persistent event services

[stephan]

Hi again!

As for the 2nd part of your question, we support all developments for Ice, including GPL'd persistent event services

The thing I'm most worried about is how I can identify a message sink/ source after a restart, i.e. how I can give unique ids to those things. Obviously, IP numbers give a part of the unique identifier but aren't sufficient.
The big size idea is to have something like a sink/source manager on each machine which creates such UUIDs and all sinks/ sources might store the values they are being assigned in their own properties after they have been given such a number for the first time. After a restart, they simply re-load this number and re-use it. But that's not really elegant I fear.

Do you have better ideas?

regs,

Stephan

[matthew]

Originally posted by stephan
Hi again!



The thing I'm most worried about is how I can identify a message sink/ source after a restart, i.e. how I can give unique ids to those things. Obviously, IP numbers give a part of the unique identifier but aren't sufficient.
The big size idea is to have something like a sink/source manager on each machine which creates such UUIDs and all sinks/ sources might store the values they are being assigned in their own properties after they have been given such a number for the first time. After a restart, they simply re-load this number and re-use it. But that's not really elegant I fear.

Do you have better ideas?

regs,

Stephan

If you use the IceStorm design you don't need numbers or UUIDs to recognize the publishers and subscribers.

Each unique publisher of events is responsible for storing and reusing the proxy that was received from the Topic::getPublisher() call. Each unique subscriber is responsible for reusing the same proxy that is given to the Topic::subscribe() call.

Regards, Matthew

[stephan]

Hi Matthew!

Thanks for your reply.

Each unique publisher of events is responsible for storing and reusing the proxy that was received from the Topic::getPublisher() call. Each unique subscriber is responsible for reusing the same proxy that is given to the Topic::subscribe() call.

I'm aware of that. But IceStorm doesn't have to take care about since restarting of clients is not being handled by IceStorm. Or is it? If so, there'd just be persistency of messages to be added.

regs,

Stephan

[matthew]

Originally posted by stephan
Hi Matthew!

Thanks for your reply.



I'm aware of that. But IceStorm doesn't have to take care about since restarting of clients is not being handled by IceStorm. Or is it? If so, there'd just be persistency of messages to be added.

regs,

Stephan

I don't understand what you've written above

What does "client" mean above? When it comes to messaging services it is best to refer to publishers (that is those who publish messages), and subscribers (that is those who receive the published messages).

Regards, Matthew

[stephan]

Sorry.
OK, imho the problem arises, when either the publisher or subscribers are being restarted.
Let's take a subscriber. As long as it is online, all messages will be proceeded to the subscriber successfully (hopefully ).
If the subscriber is being shut down (for whatever reason), the messages will be lost (as the message service isn't persistent).
Furthermore, if the subscriber is being restarted, is it identified of being exactly the same subscriber as before (using the current IceStorm implementation)?
This would be necessary if the messages would be persistent. In this case, all pending messages would have to be delivered to the subscriber that was restarted.

regs,

Stephan

[matthew]

Originally posted by stephan
Sorry.
OK, imho the problem arises, when either the publisher or subscribers are being restarted.
Let's take a subscriber. As long as it is online, all messages will be proceeded to the subscriber successfully (hopefully ).
If the subscriber is being shut down (for whatever reason), the messages will be lost (as the message service isn't persistent).
Furthermore, if the subscriber is being restarted, is it identified of being exactly the same subscriber as before (using the current IceStorm implementation)?
This would be necessary if the messages would be persistent. In this case, all pending messages would have to be delivered to the subscriber that was restarted.

regs,

Stephan

Yes, that is the implication of making the service persistent. I don't really understand what your question is though. The point is you need some way to uniquely identify your subscribers and publishers so that the messages can be made persistent, and the service interface provides exactly this without having to resort of UUIDs for explicit identification of the subscribers and publishers identity. For the case of an event publisher each unique publisher would have to remember the proxy returned by the service. For an event subscriber each unique subscriber would have to use the same proxy identity that was passed to the Topic::subscribe() call each time it is restarted.

Regards, Matthew