powered by Jive Software

Infinite loop in packet interceptor?

I have run into an interesting bug. I’m building a fall back email plugin, and I am sending email messages to users, then sending a message packet back to the room/chat thread as the user that is not online to indicate that an email was sent to the user. However, when I send this message to a room, I get another packet to intercept ( the confirmation packet), and thus end up in an infinite loop. Am I missing something? I thought that if a packet is sent from the server, then it will not be marked as incoming to the packet interceptor:

My confirmation packet generator looks like this: ( the message_packet is the packet received, the to_jid, is the room, and the from_jid is the user that was offline.

private void sendConfirmationMessage(org.xmpp.packet.Message                                              message_packet,                                              JID to_jid, JID from_jid) {
            // Send a message back to sender stating that we sent an             // email
            org.xmpp.packet.Message confirmation_message =                 new org.xmpp.packet.Message();             String from_email_addr;
            try {
                String[] results = getUserInfo(from_jid);
                from_email_addr = results[2];
            catch (UserNotFoundException exc) {
                Log.debug("FallbackEmailPlugin: "                           + "Unexpected error while generating conf message");
            }             confirmation_message.setType(message_packet.getType());
            String thread = message_packet.getThread();
            if (thread != null) {
            String conf_subject = message_packet.getSubject();
            if (conf_subject != null) {
                confirmation_message.setSubject("Re:" + conf_subject);
                "I'm not online, but I've been sent a message at"
                + " my email address: " +

From my understanding of how packet routing works in Openfire, any message enters the interceptPacket method for 4 times in the following order:

  1. incoming && !processed

  2. incoming && processed

  3. !incoming && !processed

  4. !incoming && processed

At least this is what my quick and dirty test within an XML Console and Openfire Log has revealed.

So, if this is true, make sure that you encapsulate your code for each of these four cases. This way you will avoid the infiite loop.

What I have is incoming && !processed, I would expect that the packet that I

am sending out to have incoming = false and processed = false, but that does

not appear to be the case.

What I meant is that from my previous testing, any message has this lifecycle of being sent into an interceptPacket method for 4 times. Firstly, as an incoming message, as seen to the server, and then as an outgoing message, from server’s peprspective.

In your case, you should check the session environment for an additional information.

You can call session.getAddress() for an additional clue if the message originated from within your plugin or from a client connection.

Hopefully, this time I expressed my thoughts a bit better

I’ll give that a try.

I ended up using the getNumClientPackets() functionality of the session, as anything sent from the server will not have client packets, that removed my infinite loop.