How to block incoming chatroom messages?

Smack Smack Dev
1

We are running a application in which each user register itself in a single chatroom and then sends some packet periodically to that chatroom.

There’s a single user/listener that is listening to that chatroom and parsing the incoming packets.

Now what is happening is that every other user also get the same packet from other users as all join same chatroom.

We want to remove this thing so that only single user who is listening the room should get the packets and other user should not get the other user packets.

Please help as this is very urgent.

2

This sounds like bad design. Why are you using chatrooms and not private chats?

daryl

3

Thanks a lot Daryl for the quick response.

Yah it seems like we have a flaw in our design.

So if we change it to private chat way as suggestion from you, we just want to confirm it with you like now we have around 2000-3000 user sending their packets periodically (just like heartbeat) to that single listener. So that single listener/user will not be flooded or can it be able to handle such incoming traffic?

Just an FYI , we frees the smack thread immedialely after receiving the incoming packet , so smack thread will no be blocked.

We are sending the data in a well formed XML and interval of packet sending is 60 secs.

Please provide your suggestion.

4

Private chats will be more efficient than having 2000-3000 chatrooms as there will be at least 2 more stanzas each time a user joins and then exits the room.

5

Thanks a lot Daryl for the quick response.

That way we will also reduce load on Openfire to deliever stanzas to each and every user and reduces the chances of openfire going OOME.

Actually we are having serious OOME in our openfire 3.7.1 and now I can say that the main reason is this chatroom thing.

We also analyzed the heap dumps everytime this OOME happen and it was internal queue of MINA which is failing. Because there was thousands of packet trasnfer which is not needed actually.

So again thanks a lot for your suggestion , we will implement this private chat thing and revert if any help needed.

Also we have following GC setting in our openfire , Please suggest if anything is mising or extra-

-server -Xms1024m -Xmx1024m -XX:+UseParNewGC -XX:+UseConcMarkSweepGC -XX:+CMSParallelRemarkEnabled -XX:SurvivorRatio=8 -XX:+UseCompressedStrings -XX:+UseStringCache -XX:MaxTenuringThreshold=31 -Xloggc:/opt/app/openfire/logs/gc.log -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=heapdump.hprof -Djava.net.preferIPv4Stack=true

Our server is - 2.6.18-164.el5xen i686 i686 i386 GNU/Linux (Single Processor)

6

Switching to private chats will probably not stop your OME issues from MINA. You really should run openfire on a 64bit system and 64bit JVM, providing its lots of memory. MINA issue may still happen if you do.

7

I think the appropriate solution for your problem is pubsub. You are defining a simple pubsub problem which has multiple publishers (2000-3000) and only one subscriber.

This is easily accomplished with a single node to which all users publish and only your listener subscribes, and hence will be the only one to receive the sent messages.

8

Thanks rcollier for the reply.

Now we got two solution one way to use private chat and the second way to use pubsub feature.

So which will be more helpful in our case as we have 2000-3000 users logged in at any time reducing the chances of openfire OOME as well.

9

Can you please help implementing or how to create global node which can be used by publishers and subscriber.

10

Have you tried the documentation? It sounds like you simply need to create a non-persistent node.

11

Thanks rcollier for the reply.

We found the documentation link very helpful.

We also have one more issue/concern with our application that every user is in the roster list of other user.

We have one group where every new user joins and automatically added to the roster list of other user.

What we need is every user should have only 2 users in its roster list (1 user is listener and one more).

This condition is valid for all 3000 users. That way we can reduce the cache size of roster and unneeded stanzes flow between roster list of other users.

Please help.

12

As this appears to be unrelated to your orignal question and the supplied answers, you should pose this as a new question.

13

I created a new post http://community.igniterealtime.org/message/229729#229729

Please have a look and provide your comments.