AnsweredAssumed Answered

New MUC module

Question asked by mikeycmccarthy on May 17, 2012
Latest reply on May 20, 2012 by mikeycmccarthy

Hi all,


Apologies for the lack of contribution to the group for a while, it has been super busy at work. I'm still actively involved at work with Openfire but just haven't had that much of a chance to commit community wise.


A proposal I had regarding MUC...I really want to contribute but personally find working with the code kind of hard in terms of its modularity and coupling, static methods etc (don't take this as a criticism!). On the other hand I find Tinder really easy to work with and I use it a lot. What do people think about slowly pulling out some of the MUC stuff into it's own library just like Tinder is? You could have a really concise, well tested and easy to work with module (by which I just mean a jar) that Openfire then pulls in with its build system. The project could be in Git or SVN, and use Maven or Gradle or whatever anyone else wanted as a build tool?




Just as an aside of what we're up to here in case you are interested...


We've recently upgraded our Openfire to 3.7.1 and are seeing average daily MUC activity of ~5K concurrents and even had that rise to ~12K the other day! We have seen some performance problems but they all seem to be at our end, and I've been rewriting many plugins as components using Guus's helpful bit of documentation (the Achilles Heel post) as a great guide. We've looked into PEP but proved with a Tsung load test that there is definitely a memory leak in there, so at one stage we might get some bandwith to investigate that.