On Fri, Feb 18, 2011 at 13:15, Sasha Dolgy <[email protected]> wrote: > Hi Bernd, > > I had a look at > org.apache.vysper.xmpp.state.resourcebinding.ResourceRegistry ... so the way > Vysper currently works today is that all sessions are stored in memory? If > vysper instance crashes, the resource id : session relationships aren't > persisted anywhere?
No they aren't. But since XMPP uses long-living TCP/IP connections, recovery from a server crash is equivalent to a client/server-reconnect anyway. This does not impose practical problems. (Leaving a reverse proxy setup aside.) However, a cluster of XMPP servers for the exact same domain(!) would need to share the ResourceRegistry datastructure. (You could also have a federation of XMPP servers, but that'd mean different users might have different account names like [email protected], [email protected].) > It's been years since I properly programmed .. Have only gotten involved in > Cassandra in the past four weeks and have made some significant mistakes and > successes along the way. For me, I am curious to deploy a compliant XMPP > solution that potentially will leverage the user information i persist in > cassandra. i started work on writing a module in my application for user > interactions (online / offline messages) only to stop suddenly late last > night and ask myself why i'm re-inventing a wheel .... Vysper can easily be embedded into other Java apps. Bernd > > -sd > On Fri, Feb 18, 2011 at 12:06 PM, Bernd Fondermann < > [email protected]> wrote: > >> On Fri, Feb 18, 2011 at 11:12, Sasha Dolgy <[email protected]> wrote: >> > Hi Niklas, >> > >> > The more I think about it, and the more I read, the vysper instances may >> not >> > need to be aware of each other ... this can be accomplished by all vysper >> > instances using a common storage provider. Similar to how we cluster >> http >> > servers ontop of a shared storage pool. >> >> To achieve this we would need to push even more state to storage >> providers than we do now. >> Hint: org.apache.vysper.xmpp.state.resourcebinding.ResourceRegistry >> must be shared on all instances. >> >> > It shifts the complexity down a level and makes mass deployment of new >> > instances much easier and doesn't overly complicate the current >> > implementation. >> > >> > If I make headway creating a storage provider interfacing with cassandra >> > i'll drop a note here. >> >> By all means, please do that! I think cassandra is the perfect backend >> for Vysper. >> If you'd contribute code, that would be awesome (I don't remember >> having used this word for some time.). >> >> Bernd >> > > > > -- > Sasha Dolgy > [email protected] >
