Since upgrading Openfire from 3.4.2 to 3.4.3 my MSN transport keeps on dropping the connection and reconnecting immediately. I’m using IM Gateway 1.2.1a.
My logs (error, warn, and info) don’t show anything abnormal at the time this happens.
I didn’t have this problem at all with 3.4.2 which I installed just a couple of days ago. I don’t think I’m experiencing this with the Yahoo! and AIM transports. I’m using messenger.hotmail.com:1863 as the host.
When it happens my client indicates that my MSN contacts have all logged off, then right back on again. To my contacts, I have logged off and right back on again.
Any idea what is happening here?
Thanks!
Well I have seen this behaviour occasionally, but it hasn’t never relate to client and IM gateway with me, it just happends… With ‘native’ client in windows and other clients including IM gateway… Then again it isn’t (too) common here so it doesn’t bother me that much.
I think there is a bug, because after I disabled MSN buddy icons in the options this behavior stopped BUT avatars still appear.
So the actual avatar functionality isn’t being disabled by telling it not to support avatars, but telling it not to support avatars stops it from disconnecting.
Weird.
Almost without exception, clients cache their own copies of the avatars and will use them if they can’t find a server side one. So if you’ve seen an avatar at some point, it’ll stick with you for at least a little while. These things appear to “time out” after some period of time, probably defined by the person writing the avatar support in the client.
That’s a possibility, but I don’t think that is the case. I seem to almost distinctly remember disabling Avatar support previously resulting an instant loss of buddy icons in Pidgin. At any rate, it’s been a week almost and the icons are still there.
I shall try logging in from another PC and will post back with a definite answer in any case.
Well as a Pidgin and Adium X user, I can tell you that I’ve migrated between versions of the IM Gateway plugin that supports avatars and don’t support avatars and my avatar has remained for a long time. I really don’t know what would trigger the avatars to vanish from cache eventually. Maybe they don’t. But I know the two of them cache avatars and keep them around. I even noticed this when switching from the python based transports to the IM Gateway plugin before it had avatars. I had to wipe my entire profile to get it to clear.
Hmm… Again I gave little time and experimented… Mine MSN doesn’t get disconnected so that I’d see it, but contacts have said I was offline… So essentially after awhile basically whole MSN stops transport working… (maybe all transports, but I have like 5 other network contacts versus 100 MSN contacts)…
What happends is that at some point I see only X MSN contacts, no matter do I log out and back again, and seemingly can talk to them but as said, they see me offline… This comes… what I’d say… in an hour or so from openfire restart… But I can’t say exactly as there are no indication from anything being wrong at my part, log ons and offs jsut stops comes and so on…
Now I again disabled avatars from IM Gateway and so far whole thing seems to work as should… Some hours now passed… Will report how it works under longer run…
I hope taht it would be just some stupid typo somewhere in the code, so it wouldn’t be major pain in the ass to fix in the future…
Well, there are known issues with the MSN Transport’s avatar support that account for this behavior. My only concern is that isn’t really even disabling buddy icon support.
laugh yes … it is… clients cache avatars/vcards.
I just verified that the disabling is working.
Hmh… okay… After a night I see exact same behaviour with MSN transport as before, so there definately is now some pretty serious problem with (at least) MSN transport… Or would this go into same category as my first problem reported here where atleast developer can’t reproduce failure? :-p
That is correct. I use MSN pretty extensively and it hasn’t shown a problem. =/ No disconnects on my end. The only big current problem that I can reproduce is the custom nicknames being overwritten. Openfire itself shouldn’t have anything to do with this either.
Would you like an testingaccount on my server so you could see what happends? I don’t know what else I could offer in order to solve these weird problems I seem to be plagued with.
I’ve been seeing this issue for quite some time where MSN keeps dropping and then reconnecting - sometimes as often as 2-3 times an hour. If I switch to Adium the connection is rock-solid, so I’m pretty sure this isn’t an MSN issue but something specific to the gateway plugin.
Is there anywhere I can find debugging information or any other logs that might be of use to help figure out why this is happening?
Have you tried disabling Avatar Support for the MSN gateway?
You mean buddy icons? I haven’t tried disabling them yet, but I’ll try that now and see if the connection is more stable.
Yes, Buddy Icons… But not from the client; rather in the Openfire admin center in the IM Gateway transport settings page under the “MSN Transport” section.
Yes, Buddy Icons… But not from the client; rather in the Openfire admin center in the IM Gateway transport settings page under the “MSN Transport” section.
Regarding the avatars, If turning them off stabilizes the connection, … well first off, again I can’t reproduce this. I’ve been connected to MSN just fine, no disconnects. =( That said, couple of questions …
do y’all have a -lot- of MSN contacts? maybe post me an approximate number.
I’m wondering if either there’s a protocol violation (which should be visible in the debug logs) -or- we’re breaching some sort of rate limiting. Hard to say without being able to see things as they occur. =(
If any of you can join me in the weekly chat this week, I might be able to get some more info out of you about it. Maybe even have you try it on my own server to see if you experience the same behavior.
Well, I disabled avatars and so far I haven’t had any disconnects, so we’ll see.
I have probably around 30 MSN contacts, I think.
Was it happening -that- regularly that a couple of minutes was enough time to test it breaking?