> > What do you mean by "aggressive caching"? What you'd need isn't caching, > it's "aggressive distribution".
I would assume that looking up the presence of the user would need to be pretty fast, especially if it was potentially required for every stanza that the server received. I would assume that there'd be problems if each time it would say, require a lookup in an RDB to find the delivery endpoint of a user. For example, user A logs in to node A. User B sends a message from a different node. The cached presence information still shows user A as offline, so A's node just sticks that into offline storage and user B will see the message a split second later when he actaully completes the log in process. I would say that's an acceptable side effect over top of doing something like locking user A and B's session data increasing latency. In other words the caching would probably need to favor lookup time over absolute consistency. In a way yes. But as long as it uses ResourceRegistry to look up > the online-ness of users, it's no big deal. That leads me to another question. How exactly is that interface supposed to work. When I looked at the code in the 0.07 branch, it doesn't say much about what it's supposed to do. Should I clear out messages when getStanzasForBareJID(String) is caled? Or should I leave them there? I assume the returned Collection<Stanza> must be in the correct delivery order. If getStanzasForBareJID(String) is called, it wipes out the collection of data, but the relay to that user fails does the server call receive(Stanza) again in order to ensure that those messages aren't lost? User A sends user B a message and it goes into offline storage. User B logs back on, but his connection drops after the getStanzasForbareJID is called, but before receiving the message. Those messages are lost. However, if getStanzasForbareJID doesn't erase the pending messages, does that mean that the user will always get a stream of offline messages every time? In other words, nothing in that interface tells the underlying storage when it's okay to delete that data. At least not in 0.07. On Thu, Oct 11, 2012 at 11:06 PM, Bernd Fondermann < [email protected]> wrote: > On Thu, Oct 11, 2012 at 11:16 PM, Patrick Twohig <[email protected]> > wrote: > > It actually shouldn't be that hard (famous last words). I hadn't thought > > of Zookeeper, but I would assume any distributed storage with some > > aggressive caching would do quite well. > > What do you mean by "aggressive caching"? What you'd need isn't > caching, it's "aggressive distribution". > > > > > I noticed that there's the OfflineStorageProvider. What exactly is that > > used for? I'm assuming it's for XEP-016, storing messages while the user > > is signed off. > > correct. > > > Would that be affected at all by attempting this? > > In a way yes. But as long as it uses ResourceRegistry to look up the > online-ness of users, it's no big deal. > > > > > On Thu, Oct 11, 2012 at 8:30 AM, Bernd Fondermann < > > [email protected]> wrote: > > > >> On Thu, Oct 11, 2012 at 7:28 AM, Patrick Twohig <[email protected]> > wrote: > >> > I was curious if there was any "out of the box" support to run Vysper > in > >> a > >> > distributed mode. From the looks of the code, I didn't think so, but > I'm > >> > not 100% sure. If I were to hack the internals of the server to > support > >> > this where would be a good place to start? From looking over the > code, I > >> > see that there's a few different places worth looking (Specifically > >> > StazaRelayBroker). > >> > > >> > Specifically I noticed that there's StanzaRelayBroker which uses some > >> logic > >> > to determine whether or not a stanza should be delivered to a local > >> > session, or to another XMPP server. Unless, of course, there is some > >> logic > >> > I'm not understanding properly it appears that out of the box Vysper > will > >> > only operate as a single node. Is this correct? > >> > > >> > I suspect if it were possible to cluster the server (and it's already > not > >> > supported), we'd need to know the actual IP of the other node to which > >> that > >> > user is connected as the normal operation just will use the external > >> stanza > >> > relay to deliver the stanza to the actual node the user is on. The > >> > presence of each user could be stored in something like Terracotta and > >> then > >> > add an intermediate relay which would deliver the stanza to the actual > >> node > >> > in the cluster. Has this been tried before? > >> > >> Interesting question. > >> No, clustering a single XMPP domain over multiple Vysper instances is > >> not supported. > >> And it's a little bit harder to do than webserver clustering. > >> Propagation of presence info and multi-user chat is hard. You'd need > >> to put Vysper's ResourceRegistry (the central repository of online > >> users and their presences) into a Zookeeper cluster (or Terracotta or > >> whatever is suitable here), so every Vysper instance can determine > >> where to forward stanzas to. Note that every user can have multiple > >> concurrent sessions (desktop, smartphone etc.)! > >> > >> And you are right, stanza relay would not only have to differentiate > >> between internal (same XMPP domain) and external (other XMPP domain) > >> delivery, but also between 'local remote' (same XMPP domain, other > >> Vysper instance) delivery. > >> > >> Please keep the list updated about your progress! > >> > >> Bernd > >> >
