After checking Openfire logs I saw something like:
rid 123456 > 123455.
It turned out, that I’ve sent a with a an unexpected rid, e.g. Openfire expected 123455, but I’ve sent 123456 instead (before sending 123455).
In your logs in the mailing list, you sent:
2962056780
2962056781
2962056780 (I suspect this to be the problem).
Although I believe according to the spec, an XMPP Connection Manager should just return a cached element for cases, when an ack was not received and the client tries to resend an old message (with old rid).
I still remember that this was a problem related to Openfire. Back in 2011 when we used Openfire in production we ran into the exact same issues. I won’t go any further here, just wanted to let you know that such problems exist.
The problem is that we need folks to take the extra step of solving the problem by looking at the Openfire source code and posting a fix that we can apply. There is no one free to look at issues as they are reported. The few people who are available just look at issues that affect them.
Yes punjab improved the starvation by extending the timeout delays to around 12 hours where the default http-bind from open fire was causing the timeout in matter of minutes in some cases, this was primarily happening on slow connections,
I will try to enable debug and catch the problem and report later, thanks for everyone’s support on this matter