Not logged in. · Lost password · Register
Forum: MatriX and XmppDotNet RSS
MatriX XMPP Disconnections when UI busy
Avatar
rgcooper 2012-01-05, 12:36 #1
Member since Jan 2012 · 8 posts
Group memberships: Members
Show profile · Link to this post
Subject: MatriX XMPP Disconnections when UI busy
Hi Alex,

Please can you help with a situation we are seeing in our Silverlight XMPP application where the client disconnects from our Openfire server (using BOSH connection) when the application is busy - i.e. the UI thread is under heavy contention for resources. Is this an expected behaviour given that the sending/receiving of XMPP traffic in the API is done using the UI thread? It seems the disconnection occurs after about 65 seconds, and I'm trying to understand what settings I can alter to change the behaviour on either client or server. The application we have has many connections and data streams, and the XMPP chat is just one part of it, however, it's the only part that seems to drop connections quite frequently when put under load.

Any help or advice on where to start with this would be very much appreciated.

Rob
Avatar
Alex 2012-01-05, 13:46 #2
Member since Feb 2003 · 4449 posts · Location: Germany
Group memberships: Administrators, Members
Show profile · Link to this post
Hi Rob,

are you using sockets or Bosh?
For MatriX it doesn't matter if your Ui thread is busy or not. It keeps the connection alive. My assumption is that your Openfire server expects keep alive packets every X seconds and disconnects you when they don't arrive. Can you check this?

Alex
Avatar
rgcooper 2012-01-05, 16:53 #3
Member since Jan 2012 · 8 posts
Group memberships: Members
Show profile · Link to this post
Hi Alex,

We're using BOSH, but I'm not setting the KeepAliveInterval on the XmppClient. Is this property measured in milliseconds or seconds? What is the default value if I don't set it? I'm not sure what Openfire HTTP settings are applicable, I know there is xmpp.httpbind.client.idle, but the default value is 30 s and if not set by us wouldn't explain why it disconnects after 65 seconds. There is also xmpp.httpbind.client.requests.polling but this relates to empty message handling, and so doesn't seem related.

Ideally, I'd like to figure out if the connection is being dropped by the client or by the server, and if it is being dropped by the client what are the circumstances that cause the drop to occur.

Many Thanks,
Rob
Avatar
Alex 2012-01-05, 17:24 #4
Member since Feb 2003 · 4449 posts · Location: Germany
Group memberships: Administrators, Members
Show profile · Link to this post
KeepAlive works only for sockets and does nothing on Bosh because it sends a whitespace on sockets which is not possible on Bosh.
When Openfire kills inactive sessions I suggest to send XMPP pings every X minutes.

Alex
Avatar
rgcooper 2012-01-05, 17:29 #5
Member since Jan 2012 · 8 posts
Group memberships: Members
Show profile · Link to this post
I think this is where the problem lies: our client does send ping messages once every 30s, but if those pings don't get sent because the UI is busy then the disconnection seems inevitable. For our client, this would be seen as an unacceptable break in connection and thus unreliable, so I need to figure out how to get round it - if at all possible?

Rob
Avatar
Alex 2012-01-05, 17:31 #6
Member since Feb 2003 · 4449 posts · Location: Germany
Group memberships: Administrators, Members
Show profile · Link to this post
In reply to post #4
Other customers had the same problems with Openfire. The problem was solved with sending XMPP pings. So I guess Openfire closes your sessions.

Alex
Avatar
Alex 2012-01-05, 17:32 #7
Member since Feb 2003 · 4449 posts · Location: Germany
Group memberships: Administrators, Members
Show profile · Link to this post
Ya, or fix it on the server side when possible.

Alex
Avatar
rgcooper 2012-01-05, 17:37 #8
Member since Jan 2012 · 8 posts
Group memberships: Members
Show profile · Link to this post
In reply to post #6
Alex, ok thanks for your help.

So it looks as though it is Openfire that is killing our sessions - you mention other customers had the same problem. Did any of them report any changes to Openfire to workaround the problem?
Close Smaller – Larger + Reply to this post:
Verification code: VeriCode Please enter the word from the image into the text field below. (Type the letters only, lower case is okay.)
Smileys: :-) ;-) :-D :-p :blush: :cool: :rolleyes: :huh: :-/ <_< :-( :'( :#: :scared: 8-( :nuts: :-O
Special characters:

Forum: MatriX and XmppDotNet RSS