Does Smack API have a throttle/input rate limit mechanism?

Smack Smack Dev
1

Hi all,

Does Smack API have a throttle/input rate limit mechanism? I ask because if I get lots of messages in a short abount of time, it looks like Smack sends them back to the server with an XMPP error status.

Assuming there is a throttle mechanism, is there a way to control/deactivate it? If it is not possible to do so where is is located? I was not able to find it in the code.

Thanks,

Gabriel

2

No it does not.

Could you elaborate more on the messages send back with an error status? And maybe have a look at https://github.com/igniterealtime/Smack/wiki/How-to-ask-for-help-or-report-an-is sue

3

Hi Flow,

ok, bummer… Smack sends back the message the server sent it as an XMPP error message as stated above (e.g. type=‘error’). It works fine if I limit the send rate from the server but then my application is no longer responsive enough. This happens with several message types so it is not only one type of message that causes problems. Here is an example of the message Smack sends to the server (with body omitted but as I said dramatically different msgs have this issue so I believe this is independent of the msg body).

Service not available.

I am using Smack: 4.0.2

Thanks,

Gabriel

4

Are you 100% sure that it’s Smack that sends those error messages? It’s more likely the server that does so.

5

Maybe 95%, I don’t see why the server would sent it to itself setting the “from” field to be the user. I also turned off throttling in the server because it was kicking the client off since it was flooding the server with these messages. I will keep on looking of course but I am fairly sure the server is not doing this.

6

Hold any research into this, I may have found something, I will update youwhen I have more info.

7

Hi Flow,

I investigated a bit more, based on your question. I was effectively able to trace it down to the server and not the client. It did the to/from flipping but in my case since the msg originated from the server it was looking like the client sent it, it even tricked the server into thinking the client was flooding it with msgs.

Thanks for your time and hard work,

Gabriel