First, I am pretty sure that at a mechanical level, FeedLand is correctly receiving rssCloud messages and processing them, on the A8C server.
But, we’re not going to be able to turn on all the wonderful features that come from this because there are issues raised by having more than one machine doing feed reads, and handling incoming rssCloud pings. In this post I’m going to explain the limits, and how we might approach this in a future version.
1. I have turned off websockets on feedland.org to test to see how feedlandHome works in this situation, and I fixed a bug there, and now am satisfied that this works. The fix was in feedlandHome so there’s no update needed for A8C. We should do that on the A8C instance as well because the whole websockets design, where users get notified of feed updates, depends on one and only one machine receiving updates, and that can’t be true in the VIP architecture.
2. If this were the only constraint (it isn’t) you would be able to test rssCloud functionality by causing a subscribed-to feed to update, and then reload a river that includes that feed. A new item should then appear, but it’s quite possible it won’t because there’s an internal cache that depends on being notified of feed updates, and it won’t get that update unless the feed was read on the same machine as the one you’re accessing to get the updated river.
3. I’m going to have to make a change to how that cache works, and add a fairly liberal timeout to the cache, so then you could test rssCloud updates as follows: Add a post to your feed. Wait X seconds. Reload a river that includes that feed. X is the amount of time before the cache expires.
4. We can make this work, but please let’s get something shipping first. We can tell users that reloading is the way to get the new stuff, and not promote the instant updates of rssCloud until we have a better way of doing this across multiple machines.
Hope this makes sense. If you have questions ask on the Slack channel and if necessary I will update this post.