powered by Jive Software

PacketListener Asynchronous, is it true?

Hello All,

I’m implementing a PacketListener – an interface for asynchronously notifying you of incoming packets. If person A have is listenening for incoming packets…and Person B & C sends him messages. It seems message from B & C are delivered to A using a single thread. Which it should be done in two different threads. Is this the default behavior of PacketListener? Is any body noticed this before? My Code below.

class MyPacketListener implements PacketListener {

public void processPacket(Packet packet) {

if (packet instanceof Message) {

System.out.println(“Message is:”+((Message)packet).getBody());

try { System.currentThread.sleep(1000*5); } catch (Exception ex) { ; }




Message is: message 1 from A

Message is: message 2 from A

Message is: message 1 from B

Message is: message 1 from B

Why the call to sleep? It could be causing you to miss some events?

Thread.currentThread().sleep() is called to check that if one event’s processing is delayed…will this affect the new event. And what I observe is, It does affect. The other event doesn’t get fired, unless first event is processed. And I think two events should be independent of each other. API needs to be designed that way.

I believe that is how the event generator - event listener idiom is supposed to work. Events are generated and kept in a vector, when the listener “processes” an event it is removed. That way you get the events in the right order. The generators keep a vector for each listener that has registered with them.

You shouldn’t have to worry (or count on) about them being simultaneous - you can count on being notified of every event that happens (within reason, it seems if your event listener is blocked on sleeping, there might be some timeouts)…

An interesting read is this article:

Suns Java tutorial on event listeners:


Indeed, this is how Smack was implemented. It uses a single thread to notify packet listeners.

If you look at PacketReader.java you’ll see:

// Create an executor to deliver incoming packets to listeners. We’ll use a single

// thread with an unbounded queue.

listenerExecutor = Executors.newSingleThreadExecutor(new ThreadFactory() {

But why do you say that using more than one thread is “the right way” to do. Are you really experiencing a performance issue that would justify more than one thread. And you can always make your application create more threads to handle each received packet, thus making the listener notification return immediatelly.

Hi ,

I’m planning on using smack api as the chat server. Where anybody can start chat with the signee. I was assuming that for each user a separate thread was in use to invoke Packet Listener.

But after some testing it comes out a single thread is receiving and sending all the messages. I’m thinking this type of event handling might cause performance issues when hundreds of users try to communiate with single server user. It would have been great if he API act in the fashion of Web server. Delivering events independent of each other.

However any idea how I can make this multithreaded event listeners, such that for N receipients N Packet Listener threads exists.



Smack is client library and is used for implementing XMPP clients.

I think you can use built in features of Openfire plus Smack client features to have your chat.

Have a look at the Openfire forum and try to ask a question.

You should spawn a new thread to process your packet. The reason that Smack uses a single thread to process packets is to ensure that packets are handled in the order they are received. This makes the assumption that PacketListeners as implemented, will not take a long time to process each packet.



Your message

To: Bhopu

Subject: New message: “Re: PacketListener Asynchronous, is it true?”

Sent: Wed, 12 Sep 2007 11:51:51 -0400

did not reach the following recipient(s):