Mar 4, 2011 2:49 PM
Message loss while timeout
-
Like (0)
When a client loses the connection to the server without properly closing it, for example because of a typical cyclic DSL-disconnect or if the network-cable is pulled out, the server doesn't seem to recognize this and every message sent to this client is simply dropped until the client's timeout period is over and the status of the client is automatically set to offline.
I'm experiencing this problem at least since Openfire 3.3, but I guess it was always the way it is now. There are comments on the board dating back to 2005 about this. In Openfire 3.7 on Debian Lenny (x86_64) with Sun Java JRE 1.6.0_22, there is still the same problem. I think this is a horrible and often hidden bug and an unacceptable experience for users to drop their messages without any notice.
Please fix this soon!
I think what you ask is a protocol support for XEP-0184: Message Delivery Receipts. Plain XMPP does not support this out-of the box. Both, the client and server must support this XEP.
We would also like to see this in a future version of OF (and also Smack API).
No, not exactly. I want a bug to be fixed that loses messages. If XEP-0184 notifications would be implemented the bug would have gotten more attention. I'm simply asking for the server to recognize if messages sent to a client via TCP aren't delivered and in that case, disconnect the client and store the messages as offline messages, which are delivered if the client reconnects. Currently the server doesn't check this and seems to drop every message as delivered which was pushed into the TCP stream.
I tend to agree with you.
aef wrote:
..... to recognize if messages sent to a client via TCP aren't delivered ...
This might be possible if using TCP/IP ACK or the TCP sequence number to identify each byte of data that is sent. This is currently not done in OF and also not XMPP community-wide. Most (if not all) messages are delivered in asynchronous mode (see public void deliverRawText(String text) in NIOConnection.java).
I notice that XMPP Ping is now implemented.
As I said earlier I agree with you. After checking the OF 3.7.1 Open Issues, I see that many bugs still exist!
The next release of 3.7.1 should look at bug fixing and not at adding new features! The following bugs may be related to your problem:
Your request is valid, however we should note that OF 3.7.0 was pretty much an effort lead and done in major parts by Guus alone. He is most helpful to new developmers. If you are providing development ressources, the project would move ahead. Doing so would greatly help the overall project. To my experience, it takes a week to have a seasoned developer at speed with OF/Spark development.
We (aef and I) are looking at using OF for a production environment. When I look at the OF 3.7.1 requirements list I am afraid that it is not aiming for a short release cycle, i.e. bug fixing. Openfire is a great software but some bigger XMPP projects are looking for alternatives to OF like OSW (see http://groups.google.com/group/onesocialweb/msg/44b170b3c218824d).
In my opinion there should be a OF 3.7.1 maintenance release that just looks at blockers and major bugs. Client disconnects seems to be an issue with OF 3.7.0 as multiple community messages indicate.
What is the long term vision in terms of the OF project planning, roadmap and future versions (major.minor[.maintenance[.build]])?
A roadmap requires a somewhat stable and continously working community. Guus is doing large parts of the technical work. The more people are actually writing code, the better the roadmap gets.
If OF is a great software in you opinion: Make it even better by writing code and participate in the discussion (for example by drafting a road map).
Walter, Guus,
You are right, but I cannot write stable code. I can help with testing. Ideally would be an overall Igniterealtime roadmap that includes Openfire, Spark, Tinder, Smack API and XIFF API.
Below is my proposal for OF 3.7.1. The idea is stolen from the ignite realtime web site:
The next version aims to make Openfire more stable. Future versions will look at requirements of the XSF roadmap which has identified several high-priority initiatives which include:
Version 3.7.1, Q3 2011 - Q4 2011 | Future |
|
|
*Plan as of March 11, 2011. Subject to change; we make no promises on future releases. :-)
Your vote counts! We prioritize work on new features and improvements based on community feedback. The top ten issues (by votes) are listed below. You can also view the fulllist.
To cast your own votes, visit the issue tracker, login (or create an account), then click to vote for an issue while viewing the issue report.
Issue | Votes |
| 69 |
| 56 |
| 30 |
| 26 |
| 25 |
| 22 |
| 16 |
| 13 |
| 13 |
| 12 |
| 11 |
| 10 |
aef wrote:
No, not exactly. I want a bug to be fixed that loses messages. If XEP-0184 notifications would be implemented the bug would have gotten more attention. I'm simply asking for the server to recognize if messages sent to a client via TCP aren't delivered and in that case, disconnect the client and store the messages as offline messages, which are delivered if the client reconnects. Currently the server doesn't check this and seems to drop every message as delivered which was pushed into the TCP stream.
To me XEP-0184 looks exactly what you are asking. Because application layer xmpp can't check TCP status. It needs some mechanism to check if message was delivered, so XEP-0184 looks fitting. XMPP Ping probably is not enough in this case. I have filed this, but can't say when and who can implement this: