powered by Jive Software

MSN Gateway

My MSN gateway gives the error: You were disconnected from MSN because your account signed in at another location.

I am not logged in anywhere else. I changed the password with MSN and Openfire. I rebooted. I deleted the account and recreated it. No obvious errors in the logs of the server or client.

Any ideas?

What version are you using?

1.0.2 of the gateway plugin. It has worked correctly for months until today. The variable that came into the mix is I logged out of spark several times real close together.

This happened to another account recently as well. It was resolved by changing the MSN account password.

You aren’‘t going to like my response. =) It’‘s fixed in trunk/pending 1.1.0. There’'s one and only one issue standing in the way of 1.1.0 being released at this time.

I kind of figured that would be the answer. Any Idea as to what causes this behavior in this version? Any suggestions to clear the error.

Yeah, poor handling of sessions. There was a lot of restructuring done to take care of it. =/

If you’'d like, check out this thread for a copy of the current trunk:

http://www.igniterealtime.org/forum/thread.jspa?threadID=27658&tstart=0

We get this too… one user at a time randomly.

I’'ve tried the following:

Deleting Login information (msn) from client, restarting spark, re-entering login information. Still fails.

Deleting Login information (msn) from Server page). Fails.

Tried removing entire account, then re-adding with same JID. Fails

Tried searching through our SQL database for any other reason but unable to find any refrence to broken hotmail address.

I have not tried restarting the server.

I have not tried waiting more than 20 - 30 minutes for it to clear itself up.

Removing account and registering a new JID works but is a PITA.

What version?

Gateway? that Beta 3 one… I believe its the latest available?

Crud, then that’‘s something that’‘s going to need to be debugged more. I’'ve never ever been able to reproduce it and beta 3 had the ‘‘fixes’’ in it.

Seeing as we have over 300 users and only a total of 4 reports of this… all randomly - none at the same time, I am having a hard time myself debuggin it.

Next time we get one, if there is anything I can do from here to help - just let me know,

Thanks,

josh

Do the same 4 report it? or is it a random 4 out of the 300?

4 users out of everyone have had it happen to their accounts once, not all at the same time - over the course of 4 weeks since i’'ve had the beta 3 gateway. If I re-register them with a new JID - they are okay (at least, they have been okay for the last few weeks.)

We had a total of 2 separate people have this happen with their MSN accounts. Time offline does not rectify the issue. The first account was fixed by the user logging into their msn profile and changing the password, while spark was disconnected. This had no effect on the other account (mine, grrrrr). What did fix it though was actually logging in via the MSN chat client and then logging out of the chat client. Then spark worked correctly.

We tried deleting login formation then closing spark, changing msn password, going back in and re-registering it with the Gateway but it had no effect…

I’'ve also searched through our entire SQL database for the username in question but can find no record of it at all…

Try using the real MSN messenger to login to the malfunctioning account then logoout and quit the MSN messenger. It worked for me.

It sounds to me like the MSN transport is leaving around a little in-memory, as I like to put it, “session poop” that’‘s keeping a “hidden” connection open in the background. Then you try to connect and it rightfully says there’‘s another session already. The big weirdness here is… why is logging in from your real client fixing it? I mean what’‘s different about what I’‘m doing when I log in that says “no bite me, session already in, you go away” whereas the standalone client is apparently going “all others will die”. Either way, how to determine is that little “poop” is hanging around . . . hard to say for a server with multiple accounts using it. Clearly something is triggering it that I haven’'t been able to reproduce yet. I could almost envision some scenario where:

  1. XMPP client connects/has MSN registration

  2. MSN connects and gets XXX response

  3. transport considers XXX a disconnection response and goes to reconnect

  • meanwhile - first session is still hanging around “somewhere”
  1. new connection attempt gets a “active session already” response and it punts and stops trying as it should

So what is this XXX response… and am I even barking up the right tree?

(clearly I’'m just brainstorming at the moment)

The problem on both machines was cause by a rapid succession of disconnects from the server. The first machine was cause by going from wireless to wired and back to wireless again. Mine was from exiting and relaunching several times trying to skin spark with my own logo.

You can reproduce these events causing it easily?