powered by Jive Software

Issue with karma settings on server (critical?)

While developing an application for data-exchange with smack and running tests which connect many times in a row I encountered following issue:

If the server is has karma settings (connection ratio), it limits the number of sequential connections from one user/ip (?) to a certain amount per time.

If this occures, smack produces unhandled

‘‘java.io.EOFException: no more data available’’ and /some times/ ‘‘java.net.SocketException: Connection closed by remote host’’ Exceptions and falls to unpredictable behaviour.

This is reproducable:

Configure your server with karma-settings e.g.

10

10

1

1

-6

10

(which is the default here)

and try to connect more than 10 times in a short period.

Florian

Florian,

There is no possible way for Smack to handle this gracefully. If the server simply shuts down the connection with no warning, what can Smack do about it? However, there is a ConnectionListener API that you can use to detect connections failing when errors occur. I’'d suggest using that in your application.

Do you have any other suggestions about ways we could handle server karma better?

Regards,

Matt

Hi Matt,

unfotunately not. I’‘m not very deeply in the jabber protocol so that I knew which messages (and if any) are involved in this case. I just thought, that an exception here is a bad thing, since there is no possibility in catching it. But I’'m going to have a deeper look in that ConnectionListener and see what it can do.

By the way: Lost connection is another issue, which I don’'t know how it is handled by know. But first of all I look at the Listener.

Thanks & regards,

Florian Bantner

Florian,

Lost connections can be handled using the ConnectionListener feature. Please let me know if you can find any improved ways of handling karma is Smack.

Regards,

Matt

Hi Matt,

seems like I’'ve got the wrong version? In my Version (1.1.1) there seem to be no ConnectionListener. (At least a grep returns nothing for that)

My testing at the moment: Pulling the plug and waiting what happens. Currently it’'s a java.net.SocketException which seems to end the PacketReader thread in the parsePackets() method.

But if it was for my decission, some kind of ‘‘ConnectionListener’’ whould be exacly what I’'m looking for. Perhaps some kind of default-policy for lost connections aka. ''try again in 30 seconds) which would implement a CL-interface would be an easier solution for the common use. Should be enough if you could overwrite that.

Regards,

Florian

Florian,

Sorry about that – should have mentioned that ConnectionListener is part of the daily builds and will be in the upcoming 1.2 release. Daily builds are at:

http://www.jivesoftware.com/xmpp/smack/dailybuilds.jsp

I think a reconnect policy is a good idea, but it is something that should be implemented on top of Smack using the ConnectionListener feature, rather than Smack handling it for you.

Regards,

Matt

Hi Matt,

Now I got it. Seems to be exactly what I was looking for. I will have a closer look at it tomorror (it’'s 4:30 am here).

For the policy. Not that I would need it very urgently. But I think it would be a great deal of convenience for developing the ‘‘standard’’ chat-client. I would imagine it in a way perhaps a little similar to swings Component-Model architecture:

DefaultConnectionListener extends CL {

connectionClosed(){

// Do reconnecting according to default-policy

// and notify the user-Listener via the connectionOpened() method

// same thing for closedOnError()

}

}

The DefaultConnectionListener would be added to any connection by default.

Adding an connectionOpened() method to the CL would have the additional advantage, that the connect method could run asynchonous. I feel, that such a method whouldn’‘t do harm anyway (gives a little bit more symetry: imagine two listeners. One of them reconnects. What’'s the simplest way for the other one to take notice of it?)

Of cause there has to be a way of removing this default-behaviour, but the ‘‘normal’’ client would be much simpler to implement:

class Client extends CL {

main(){

c = connect();

c.addConnectionListener( this )

}

connectionOpened(){

//do visual Stuff: e.g. showLink

}

connectionClosed(){

//do visual Stuff: e.g. hideLink

}

}

instead of having the reconnection methods build in a way

that thy can be called every disconnect.

So much for my 5 cents. But like I saied: I don’'t feel an urgent need for that. I do have to implement this stuff by my own since I have to fit spezial needs. It would eventually a little bit easier this way, but the main work lies somewhere else.

Anyway. I do really like this library and think it’'s great work.

Regards,

Florian