<div dir="ltr"><div>Hi All,</div><div><br></div><div>I presented a session at the Evergreen conference related to replacing XMPP/Ejabberd with Redis.  </div><div><br></div><div><a href="https://github.com/berick/Presentations/blob/master/Evergreen-2022/osrf-redis.md">https://github.com/berick/Presentations/blob/master/Evergreen-2022/osrf-redis.md</a><br></div><div><br></div><div>Following the session, Mike, Galen, and I had a good discussion in the dev "room" about how best to leverage Redis features.  Mike suggested trying Redis Streams and Consumer Groups in lieu of Redis Lists, which were used in my proof of concept, because Streams have some benefits over lists.  In short, you can collect a lot more information about the state of a stream and those subscribed to the stream.</div><div><br></div><div>Based on that discussion, I've posted working branches that replace Lists with Streams.</div><div><br></div><a href="https://git.evergreen-ils.org/?p=working/OpenSRF.git;a=shortlog;h=refs/heads/user/berick/lpxxx-redisrf-streams-v2">https://git.evergreen-ils.org/?p=working/OpenSRF.git;a=shortlog;h=refs/heads/user/berick/lpxxx-redisrf-streams-v2</a><br><div><br></div><div><a href="https://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/user/berick/lpxxx-redisrf-streams-v2">https://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/user/berick/lpxxx-redisrf-streams-v2</a><br></div><div><br></div><div>There's still a lot to do, but I wanted to share.  Also, I have follow up thoughts/questions.</div><div><br></div><div>Streams support message acknowledgements (XACK message) and message redelivery.  I'm curious if/when/how/where this might benefit us in practice.  I'm having some trouble seeing the value.</div><div><br></div><div>A client has to actively request a Stream message, they're not just dropped onto the network.  Presumably, if the client is requesting it, it has the capacity to process it.  E.g. Listeners won't pull more messages if they have reached max children. </div><div><br></div><div>The scenarios where an ACK would not get delivered are a service/worker crash or non-graceful shutdown.  If a service crashes, there's a decent chance it crashed because of the message, meaning we probably don't want to reprocess it anyway.</div><div><br></div><div>ACK's and message reprocessing raise other questions about how long after a message is sent does it make sense to reprocess it after a failure.  Similarly, I'm guessing we'd never attempt to reprocess messages sent directly between clients and workers, since the messages would be meaningless out of context.</div><div><br></div><div>Other thoughts?  Am I missing anything?  </div><div><br></div><div>-b</div><div><br></div><div><br></div><div><br></div><div><br></div></div>