It is doable. One option is to have a message aggregator that listens for messages from multiple message clients. The aggregator can do message persistence. A side benefit of an aggregator is in preserving orders across distributed message clients. Persistence is done to local file system. Then there is a message distributor daemon that actually distribute the message to actual message consumers who listens on a different group.<br>
<br>While this method works, there are a couple of reason why it is not ideal:<br>1. if the aggregator is down, message is lost(?). For asynchronous message delivery, ideally, a success return code means that message has been persisted (not necessarily delivered). If the local spread client can do the persistence, then there is less of a chance of dropped messages. Pulling the existence of an aggregator on every message delivery is both expensive and still not 100% sure of persistence.<br>
2. the aggregator that persists message need to synchronous with the dsitributor daemon while reading/writing to the local file system. While it is not that difficult, it will be better it is not implemented case by case, but rather by a component of a mesaging platform.<br>
<br>I read the spread user manual. The user manual is more a spread introduction literature plus an api reference manual. I can't find more indepth architecture discussion on spread's internal. E.g. spread will retry a message delivery if there is a network failure. That means it maintains an internal buffere. However, how big is the buffer and how large each message can be? <br>
<br>Is there any white paper on spread? Any related projects that has done file system based message persistence with reader/writer synchronization?<br><br>thanks,<br><br>-john<br><br><div class="gmail_quote">On Sat, Mar 15, 2008 at 9:13 AM, Rodrick Brown <<a href="mailto:rodrick.brown@gmail.com">rodrick.brown@gmail.com</a>> wrote:<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div><div></div><div class="Wj3C7c">On Sat, Mar 15, 2008 at 5:47 AM, John Song <<a href="mailto:delphi329@gmail.com">delphi329@gmail.com</a>> wrote:<br>
> Hi:<br>
><br>
> I am looking to build a message relay system using spread. One of the<br>
> requirement is being able to replay messages in order. One way is to have a<br>
> listener subscribe to the group and persist messages on disc. Later on, if<br>
> replay is needed, then a spread client can read the message from the disc<br>
> and resent. The problem is I can't guarantee the listener will always<br>
> alive. Does spread internally persist messages? I.e. if a client sends a<br>
> message to the group and there is no subscribed listener, will spread simply<br>
> discard the message?<br>
><br>
> Any other open source projects, except JMS, that will be better for that<br>
> kind of relay/replay system?<br>
><br>
> thanks,<br>
><br>
><br>
<br>
</div></div>Why not implement multiple listeners? And have them both backup each<br>
other you can see when other members join/leave groups so it should be<br>
fairly easy to setup some kind of fail over scenerio where you can<br>
keep the messages persisted using multiple listeners<br>
<br>
> _______________________________________________<br>
> Spread-users mailing list<br>
> <a href="mailto:Spread-users@lists.spread.org">Spread-users@lists.spread.org</a><br>
> <a href="http://lists.spread.org/mailman/listinfo/spread-users" target="_blank">http://lists.spread.org/mailman/listinfo/spread-users</a><br>
><br>
><br>
<font color="#888888"><br>
<br>
<br>
--<br>
Rodrick R. Brown<br>
<a href="http://www.rodrickbrown.com" target="_blank">http://www.rodrickbrown.com</a><br>
<a href="http://www.linkedin.com/in/rodrickbrown" target="_blank">http://www.linkedin.com/in/rodrickbrown</a><br>
</font></blockquote></div><br>