I have upgraded our OpenFire from 3.7 to 3.10. Most of our clients work just fine. But we have a Jabber.NET client that can receive okay from other client types (like Spark), but can not send messages. When the client based on Jabber.NET sends a message through the 3.10 OF server, I see the following in the debug logs:
2015.08.14 16:19:31 org.apache.mina.filter.codec.ProtocolCodecFilter - Processing a MESSAGE_RECEIVED for session 11
2015.08.14 16:19:31 org.jivesoftware.openfire.spi.RoutingTableImpl - Failed to route packet to JID: atlwave12297122971@172.22.1.81/IM packet: <message id="JN_16" to="atlwave12297122971@172.22.1.81/IM" from="atlwave12297422974@172.22.1.81/ViewPoint-d27b488e-c33b-43b9-a044-0975cbdfa266"><body>Message</body></message>
2015.08.14 16:19:32 org.jivesoftware.util.log.util.CommonsLogFactory - Closing statement 1232583 (belonging to connection 3) automatically
2015.08.14 16:19:32 org.jivesoftware.util.log.util.CommonsLogFactory - Closing statement eb3a80 (belonging to connection 3) automatically
2015.08.14 16:19:33 org.apache.mina.filter.executor.OrderedThreadPoolExecutor - Adding event MESSAGE_RECEIVED to session 9
Any thoughts on why this happens? If I flip back to using 3.7 - it works fine.
Thanks, Scott
Your xmpp.domain is set to the ip address and not some domain name? I am unsure if that is supported these days
Daryl - thanks for taking the time to look at this and response.
I don’t think the lack of a domain name is the issue. I use the Spark client and it sends using ip address all day long. we don;t have FQDN’s for these systems.
I looked at the message archive and discovered something else, the messages that are not getting routed have a “toJIDResource” of “IM”.
So - the client in question seems to send messages with a to address of: "atlwave12297122971@172.22.1.81/IM". On OpenFire 3.7, that gets translated into a message where the “toJIDResource” is still “null” and the “toJID” field is "atlwave12297122971@172.22.1.81/IM".
Switching over to OpenFire 3.10, I see that records added by the rogue client now have a “toJID” field that is missing the “/IM” (it’s just "atlwave12297122971@172.22.1.81") but now the “toJIDResource” field has an “IM” in it instead of null.
I honestly don’t know what all those fields are. But my guess is when the client puts the “/IM” onto the end, with OF 3.7 it would pass through. But with OF 3.10 - it invokes some other lookup that causes issues.
Any thoughts on this from anybody?
Just a follow-up. So for some reason this original client app using Jabber.NET was appending the “/IM” to the end of the address.
That worked in OF 3.7 - even if the resource was wrong. But in OF 3.10, it does not route.
Hope that helps someone.