Jive Messenger throughput limit?

Openfire Openfire Support
1

Hi,

Here is the background on my situation – if you want to skip directly to the problem, just skip the next 2 paragraphs.

We are developing an application which uses XMPP as it’'s transport layer to communicate amongst a set of distributed services that together implement the functionality of our application. In other words, we have bots that do various jobs and chat amongst themselves via XMPP in order to do these jobs. There is no human interaction anywhere on the network. We have fairly high performance requirements (~1000 msgs/second pumped through the system).

We have been using jabberd 2.0s6 with some success but have found it very unwieldy and encountered a bug which drastically reduces the stability of our solution. I am investigating Jive Messenger as an alternative, and one the first things I did was run my performance test which runs 50,000 messages through the system (each message is small – right around 255 bytes total. The messages are sent to chat rooms where they are picked up by various other bots and processed.

Using jabberd, the 50,000 messages from my performance test bot all make it through sooner or later… using Jive Messenger I get about 15 of them and then I get about 15 ERROR lines (with no text) and then the connection to my performance test bot is closed.

So the bottom line is that it looks like either Jive Messenger has some sort of rate limiting feature which closes a connection to a user that appears to be trying to flood a chat room (or perhaps a user trying to flood it’‘s connection period, etc). Or, there’‘s a bug that is triggered if too many messages are sent too quickly which causes the users’’ connection to be closed.

I haven’'t seen any references to anything like this online, nor have I found anything in the documentation about rate limiting, nor have I found anything in the configuration that looks like it would control this, if it is a feature and not a bug.

Has anyone had any similar experiences, or has anyone else done any high-volume/high-throughput tests either successfully or unsuccessfully?

Also, for what it’'s worth, this is what I see in the debug log:

2005.03.02 18:50:16 Connect Socket[addr=/192.168.x.x,port=4436,localport=5222]

2005.03.02 18:50:17 Logging off @[host]/[resource] on org.jivesoftware.messenger.net.SocketConnection@eb7331

And this is what I see in the error log:

java.net.SocketException: Connection reset

at java.net.SocketOutputStream.socketWrite(Unknown Source)

at java.net.SocketOutputStream.write(Unknown Source)

at sun.nio.cs.StreamEncoder$CharsetSE.writeBytes(Unknown Source)

at sun.nio.cs.StreamEncoder$CharsetSE.implFlushBuffer(Unknown Source)

at sun.nio.cs.StreamEncoder$CharsetSE.implFlush(Unknown Source)

at sun.nio.cs.StreamEncoder.flush(Unknown Source)

at java.io.OutputStreamWriter.flush(Unknown Source)

at java.io.BufferedWriter.flush(Unknown Source)

at org.dom4j.io.XMLWriter.flush(XMLWriter.java:244)

at org.jivesoftware.messenger.net.SocketConnection.deliver(SocketConnection.java:1 79)

at org.jivesoftware.messenger.spi.SessionImpl.deliver(SessionImpl.java:234)

at org.jivesoftware.messenger.spi.SessionImpl.process(SessionImpl.java:228)

at org.jivesoftware.messenger.MessageRouter.route(MessageRouter.java:67)

at org.jivesoftware.messenger.PacketRouter.route(PacketRouter.java:84)

at org.jivesoftware.messenger.PacketRouter.route(PacketRouter.java:63)

at org.jivesoftware.messenger.muc.spi.MUCRoleImpl.send(MUCRoleImpl.java:207)

at org.jivesoftware.messenger.muc.spi.MUCRoomImpl.broadcast(MUCRoomImpl.java:810)

at org.jivesoftware.messenger.muc.spi.MUCRoomImpl.send(MUCRoomImpl.java:741)

at org.jivesoftware.messenger.muc.spi.MUCRoomImpl.sendPublicMessage(MUCRoomImpl.ja va:723)

at org.jivesoftware.messenger.muc.spi.MUCUserImpl.process(MUCUserImpl.java:202)

at org.jivesoftware.messenger.muc.spi.MUCUserImpl.process(MUCUserImpl.java:112)

at org.jivesoftware.messenger.muc.spi.MultiUserChatServerImpl.process(MultiUserCha tServerImpl.java:709)

at org.jivesoftware.messenger.MessageRouter.route(MessageRouter.java:67)

at org.jivesoftware.messenger.PacketRouter.route(PacketRouter.java:84)

at org.jivesoftware.messenger.net.SocketReadThread.readStream(SocketReadThread.jav a:191)

at org.jivesoftware.messenger.net.SocketReadThread.run(SocketReadThread.java:109)

Any advice, hints, pointers to information, issues, etc. would be much appreciated. Thanks.

John

P.S. With the exception of this one issue, Jive Messenger seems to be vastly superior to jjabberd in just about every way imaginable.

2

John,

In the last major performance test that we did, Jive Messenger had vastly superior message throughput compared to jabberd (1.x and current 2.x at the time). It’‘s possible there’‘s been a regression – if that’'s the case, we would treat the issue as a serious problem. Do you have any tips on how we can try to duplicate this issue locally?

Thanks,

Matt

3

The following code seems to do the trick for me…

import org.jivesoftware.smack.XMPPConnection;
import org.jivesoftware.smack.XMPPException;
import org.jivesoftware.smackx.muc.MultiUserChat; public class SimpleSpammer
{
     private static final String HOST = "yourhost.com";
     private static final String CONFERENCE_HOST = "conference." + HOST;
     private static final int PORT = 5222;
     private static final String USERNAME = "youruser";
     private static final String PASSWORD = "yourpw";
     private static final String RESOURCE = USERNAME;
     private static final String ROOM = "yourroom@" + CONFERENCE_HOST;
     private static final String NICK = RESOURCE;      
     public static void main(String[] args)
          throws XMPPException
     {
          XMPPConnection conn = new XMPPConnection(HOST, PORT);
          conn.login(USERNAME, PASSWORD, RESOURCE);
                // Note, this room must already exist....           MultiUserChat chat = new MultiUserChat(conn, ROOM);
          chat.join(NICK);
          for (int i=0; i<50000; i++)
          {
               chat.sendMessage("hi");
          }
          chat.leave();
          conn.close();
     }
}

When I run this against my server and watched from another client (Exodus specifically), I saw the spammer join and send 30 messages then leave the room. I got absolutely zero output on the console (stdout or stderr) from the program.

Let me know if I can provide any additional information… also, fwiw this is against v2.1.1 which is says was released 1/30/2005.

John

4

Hey John,

Thanks for the code. I converted it into a test case. I ran the test case with 50K messages and everything went fine. I’‘m using the latest nightly build whilst you were using the 2.1.1 version. However, I can’'t think of any fix we did that may solved this kind of problem. Could you run the following test case using the latest nightly build?

public void testMUCFlood() {
        try {
            int floodNumber = 50000;
            MultiUserChat chat = new MultiUserChat(getConnection(0), "myroom@" + getMUCDomain());
            chat.create("phatom");
            chat.sendConfigurationForm(new Form(Form.TYPE_SUBMIT));             MultiUserChat chat2 = new MultiUserChat(getConnection(1), "myroom@" + getMUCDomain());
            chat2.join("christine");             for (int i=0; i<floodNumber; i++)
            {
                chat.sendMessage("hi");
            }             Thread.sleep(200);             for (int i=0; i<floodNumber; i++)
            {
                if (i % 100 == 0) {
                    System.out.println(i);
                }
                assertNotNull("Received " + i + " of " + floodNumber + " messages",
                        chat2.nextMessage(SmackConfiguration.getPacketReplyTimeout()));
            }             chat.leave();
            chat2.leave();         } catch (Exception e) {
            e.printStackTrace();
            fail(e.getMessage());
        }

Let me know how it goes.

Thanks,

– Gato

5

It appears that the problem was that messages were getting queued and then the chat.leave() call was going through immediately and so the rest of the messages were not being sent because I was not in the room. Adding a Thread.sleep() call like in your test case fixed the problem. I’'m not sure why this was not the case with jabberd… but in any event, it appears that the problem is not with Jive Messenger itself.

Thanks for assistance! It looks like this may enable me to use Jive Messenger for this problem, which will be a godsend!

John