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?
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 .... -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]
