Version: 0.7.1 (using KDE KDE 3.1.3) Installed from: SuSE RPMs Compiler: Gcc 3.3 OS: Linux Yesterday I got the following message from my jabber-server: I'll try to translate it, but I'll keep it attached for german readers - the original will certainly be better than my translation. The newest release of kopete seems to cause a problem. The session-managers of amessage go down more often these days. The problem seems to be caused by a (each time different) user who uses kopete as his jabber-client. These kopete-users send without a break identical transport-rename-commands to the server. This causes high loads on the session-manager, so that it isn't able to answer incoming messages in a reasonable time anymore. If you use kopete: Please switch to a different jabber-client until the problem was found and fixed. German original: Es scheint ein Problem mit der neuesten Version von Kopete zu geben. Dieser Tage gehen die Session-Manager von amessage
I received the same message. I am also using 0.7.1. I installed Kopete from the Source with a Mandrake 9.1.
This is strange, I never came across it. Do you actually have transports on your contact list? If possible, can you enable debugging at the configure stage and see if the packets show up on the debug console? A small log excerpt would probably help a lot. Does it happen at login stage immediately or is there a trigger?
Every user on one of the amessage servers gets the warning about please not using Kopete at the moment. I had to "broadcast" this message as there is no feature in the server to send messages to only users of a special client or client version. Actually the server does not even know which client a user is using. Not every user using Kopete is causing these problems, but there are several users, that are causing problems and all of them are using Kopete. (I know this by asking them which client they use and because they are using the Resource "Kopete".) If the problem happens it is always that Kopete renames _one_ of the transports on the roster all the time. E.g. one user renamed the AIM transport between "Netübergang: AIM" and "AIM" all the time in both directions by sending <iq> sets with a <query xmlns="jabber:iq:roster"/> element in it. When I notice that this happens I think I always noticed that the corresponding transport has been down. I am not sure which event implies the other. Is kopete trying to log in again to a transport, that is offline?
Kopete does not really support transports yet, so it won't do anything transport specific. The only thing Kopete can knowingly do is register with a transport. For everything else, it treats them like normal contacts. It could be that users using transports nevertheless and trying to rename the transport causes Kopete to get stuck in a loop. Since the rename packet is guaranteed to only be sent out once, I don't understand yet why it would get sent out repeatedly.
I cannot reproduce this. I registered an account tigloo@amessage.de, registered with the ICQ gateway, disconnected and reconnected. Nothing happened. I renamed the transport, nothing happened, not even after reconnecting. I need to get exact steps to reliably reproduce the behavior - maybe someone can create an account for me where it happens and let me access it? At least a full debug log is required, otherwise I can't work on this. Since by design there is no way that the Jabber plugin will get into an endless loop sending out the same packets over and over, I currently have to suspect that another part of Kopete is responsible or that there is an error on the server side.
Adding kopete-devel@kde.org and asking for help: could a few people using the Jabber plugin please test this with one of the amessage servers?
Since there have been no further reports about this bug, I'm lowering the priority and severity again. AFAIK this is the only bug preventing a 0.7.2 release and we should try to get 0.7.2 out of the door, especially concerning the fact that it might make it on the next SuSE distro with an updated MSN protocol. In case this bug turns out to be a fault in Kopete's protocol implementation, I'd much rather release 0.7.3 as soon as there has been more evidence and a potential fix.
There have been no further reports or follow-ups, even though the bug is now three weeks old. I am taking this one very seriously, but I'll have to close it if there won't be any incidents after the next few weeks.
I even don't get any message from my jabber-server a-message.de regarding this problem. Maybe it wasn't really kopete's fault?
No further reports or follow-ups, so I'll close it. Till: If you think this one should stay open, feel free to reopen. :)
It did occur once again, apparently not in the frequency as before but still it did happen. Matthias sent me a packet dump, it's almost impossible to diagnose it without the corresponding debug log though. I'd like to keep this open until the next major release after 0.8, if it went away by then, it was temporary. Otherwise I'm hoping to get ahold of more information.
If this is to stay open for such a long time it's not a 0.7, nor a 0.8 version :) Martijn
Subject: Ihre Mail an segfault_ii@web.de For english text read below. Hallo! Ich bin bis zum 23.01.04 voraussichtlich nicht zu erreichen. Ihre eMail habe ich erhalten, werde jedoch erst am 23.01.04 darauf antworten k
Does this bug still happen? With major changes in the Jabber code coming up and no follow-ups to this, I am inclined to close it after I merged the new Jabber library.
Hallo Till! Okay meinerseits f
The new Jabber code has been merged to HEAD this afternoon, with Matthias having given his approval I'll close the bug for now. Let's hope it won't come back. :)