That is very interesting. I assume the connection would timeout though if it doesn’t get a response?
Nothing to do with the ACK but is anyone using the User Service Plugin? I just restarted this and our memory usage surprisingly dropped by about 300MB? I will have a look at the source code in this also to see if I can see any potential issues.
Official JiveSoftware developers dont work actively on this project anymore, so there is only a group of users who try to fix issues and answer basic questions. It seems that there is only a small number of users doing load tests, so there is not much information about this.
We’re now using Tsung to load test rather than Grinder and we’re getting the same issues.
Does anyone know of an Openfire installation being used in any large-ish scale production environment? We’re at the stage where I think we’re going to have to abandon Openfire and use something like ejabberd : (
Open-source can be frustrating sometimes. I’ve now reported this in Ubuntu Launchpad (try upstream), Gnome Bugzilla (try upstream) and now Freedesktop.org. I wish there was only one place to do this.
My patch disconnected all idle clients (clients that had not been sent any data for a while). As you’ve found, that’s not the best of solutions. Instead, the code should detect write timeouts. Luckily, MINA appears to offer that functionality.
I’ve modified the patch to detect write-timeouts. I haven’t been able to test this yet, but could one of you give it a try?
We’re testing now. To run the patch simply check out the Openfire source, add the relevant line (or use Eclipse -> Patch -> Apply) then build the openfire jar using the Ant script.
Just as an aside, what we’re planning to do at some point is pull a network cable on our load test clients and see how Openfire deals with the sudden disconnection. If the patch works presumably it shouldn’t run out of memory.