powered by Jive Software

Limits on load / Karma?

This feels very n00bie-ish of me, so apologies in advance.

I’m looking into the possibility of setting a limit on data/messages sent from openfire server to clients within a specific timeframe.

The Jabber concept of Karma seems related to this, but I can’t find good info on support for this in Openfire.

(I am open to this being due to a failure in my search methods… )

From a very helpful properties page (my new favourite page!):

http://www.igniterealtime.org/community/docs/DOC-1061

I have come across a couple of properties which may relate to this, but not certain they are the right ones:

xmpp.command.limit

or some kind of adaptation related to: xmpp.parser.buffer.size

Does anyone have any info (anything at all VERY much appreciated) relating to this or anything related to data throttling/flood control/load limits/etc ?

Thanks for your time and thank you for Openfire !

I’m not aware of any Karma features in Openfire.

Thank you for your reply wr00t

Still hunting around for related functionality.
I have come across a couple of things just now regarding throttling. In a couple of old archived discussions Gaston Dombiak mentioned that it was being worked on - example at the bottom of this thread:
http://www.igniterealtime.org/community/message/141685#141685

Also I found in the source some throttle tests by Matt Tucker, implying that it has been implemented, but I can’t seem to spot adjustable variables/properties regarding this, so hopefully someone out there knows where those might be located.

I’m not sure at the moment whether investigating the ConnectionManagers further might be useful or a step in the completely wrong direction.

Any comments on me looking at the wrong things are as well appreciated as comments pointing me in the right direction

Thanks again wr00t

That’s a very old discussion so i won’tbe hoping they are still working on this. Jive is now focused on their commercial product.

I think Connection Manager is not exactly a karma feature. Yes, it takes the load from the server, but it doesnt limit anything as far as i understand.

Hehe, yep it is v old I purely meant that as a reference to it hopefully being in there and in fact I found a much more recent posting which seems to confirm further its existence in there, but doesn’t really give any detail.

In your view/experience, should these kind of limitations be placed elsewhere, before reaching Openfire itself?

To me it seemed like Openfire was the right central place to control this, rather than the numerous nodes sending and receiving to/from Openfire.

Thanks again for your time, I definitely feel like I am at least making headway here

In your view/experience, should these kind of limitations be placed elsewhere, before reaching Openfire itself?

To me it seemed like Openfire was the right central place to control this, rather than the numerous nodes sending and receiving to/from Openfire.

I think it would be easier to do this in Openfire itself. Connection Managers still could exist to make the natural load minimal, but that depends on the traffic you are expecting. And this limitations will take additional CPU power to process, so if there are lots of users and messaging (hundreds of thousands and more) then Connection Managers can be useful.

We are working from the expectation of at least hundreds, to potentially thousands of concurrent users (as maximum load), but we are propagating considerable amounts of binary data as well (in addition to the actual chats) with the obvious performance considerations. I will definitely need to study the Connection Managers a bit more to be clear on that part of the solution. Still hoping someone out there knows something about the throttling implementation specifically and will come across this message soon.

Thanks again!

So far I have only found issues surrounding the actual throttling, but not really a place for setting such a limit or a good place to alter that in code. Functionality for some related adjustment appears to exist, but not in an easily adjustable way it seems.

I had some great feedback from Wroot (thanks again ! ) but am really curious whether someone else has anything more to add. Different info, different viewpoint, previous experiences of dealing succesfully/unsuccessfully with a related issue perhaps? All help and comments of course greatly appreciated Thanks!