Hi
where should we spend some dev hours in Openfire? We were thinking about updating some libs to current versions and refactoring parts.
Anything that deserves special attention?
Fastpath is already in the making…
Walter
Walter,
Stepping thru Jira issues and triaging, tackling issues there is my best suggestion.
daryl
I agree with all suggestions made so far. Just to throw in another.
Pubsub does not have an admin console UI. It would be very helpful to be able to see and manage pubsub nodes/items and their permissions form admin console just like MUC rooms.
And if we make that effort, we might as well do user vCards as well
2 Likes
Well, I think we will start getting some libs inside OF up to newer versions. We were thinking about replacing some lib Mina against Netty and the XML parser against a “faster” version. The students I am working with are looking for bigger target than features 
I can agree on vcards management. But we can not break Spark . . .
From a feature POV
- OF-446 Stream Mangement (part of XEP-302, Sever Compliance Suite 2012, Advanced Server). Hopefully this will make it one day in OF.
- OF-103 Multiple Resources in Groupchat (see also OF-178)
Also OF-159, along with some s2s integration test cases. A few months ago the latest released openfire version was unable to connect to the majority of XMPP servers because the s2s dialback implementation was broken.
I know that features aren’t done within a few man hours. But OF also has some memory leaks to fix
I would suggest starting with low risk items in Jira, as there was a push a little while ago to try and get a new release out. Assuming that this is still something that we want to get done soon, I don’t think we would want to risk delaying it even longer (it has been a long time already) by introducing new bugs.
I would like to see Guus weigh in on this one.
IMHO, I think the lib upgrades is a good idea. It would also be nice to leave the version numbers on the jar files so it is actually obvious what versions we are using.
Agree it would be good to try to get a release out soon.
As an alternative if you want to take on something a bit more substantial, you could do the work in a separate branch, at least until 3.7.2 is out of the chute. We took this approach with the Pubsub refactor, and had no trouble merging the changes back into the trunk when the work was (mostly) complete.
Also to that end, +1 for a Pubsub admin console (per Dele’s suggestion above). A few of us have been thinking along similar lines, but haven’t made much headway yet.
In any case, thanks for the help! It’s encouraging to see ongoing development from the community.
Branching is mandatory for sure.
Any specific idea about the memory leaks?
The only leak I know of was PEP related, but we are pretty sure that is fixed in trunk with the refactoring in pubsub.
Can’t say where the leaks are. And i have PEP disabled for years and it was running smoothly for months with the default JVM settings. But some 6 months ago i had to increase JVM memory and still have to restart the server every month, because it just climbs and never releases the memory. The load should be similar for years. Maybe it is related to some java updates, because Openfire is the same.
hi ,
How about implementing cluster in clean way ? I searched for cluster of openfire , i didn’t get any step-by-step solution …
Thanks
Rahul Akula
Maybe a nice guide on how to identify the leaks would be nice (e.g. take and analyze heap dump) and how to put this information in a good bug report. That would be a nice student project.
There are some docs made by LG like this http://community.igniterealtime.org/docs/DOC-1033 But i’m afraid to dive into such debugging Also, if it can be done without affecting the server, then fine. But i don’t want to bring my server to knees to take a dump