powered by Jive Software

Bug in directed presence? unable to route message reply after directed presence

Versions Tested: OpenFire 3.7.1, 3.7.0, 3.6.4

Error: org.jivesoftware.openfire.spi.RoutingTableImpl - Unable to route packet.

Packet should only be sent to available sessions and the route is not available.

  1. UserA@server and UserB@server are on each other’s rosters

  2. UserA@server/resource1 logs in and sends broadcast presence (available)

  3. UserB@server/resource1 logs in and sends broadcast presence (available)

  4. UserA@server/resource2 logs in and sends directed presence to UserB@server/resource1

  5. UserA@server/resource2 sends a message to UserB@server/resource1

  6. UserB@server/resource1 receives the message and replies to UserA@server/resource2

  7. UserA@server/resource2 does not receive the message as expected

It appears as though OpenFire does not route the message from UserB@server/resource1

to UserA@server/resource2 because the resource is not seen as available to it, even

after the directed presence. The base jids are already on each other’s rosters and both

are online, but UserA@server/resource2 is not seen as available. Does each individual

resource need to be on UserB@server’s roster?

There’s a similar bug that was closed/fixed in 3.5.0 but that fix was for (5) and

did not include (6). http://issues.igniterealtime.org/browse/JM-1275

http://issues.igniterealtime.org/browse/JM-920, which was closed needing

more information. http://community.igniterealtime.org/message/137025#137025

This use case appears to be covered by example 1 in rfc3921 section 5.1.4 but not

honored by OpenFire. http://tools.ietf.org/html/rfc3921#section-5.1.4

Our current inelegant work around is to send a broadcast presence in (4) from

UserA@server/resource2, instead of the directed presence. But this does not scale

when there are a large number of subscribers to UserA@server’s roster – adds

unnecessary traffic and load.

Here is debug output from the client and error messages seen from debug.log,

cleaned-up relative to the example above, when using directed presence.

himsg

hello therereply

2012.09.05 23:59:17 org.jivesoftware.openfire.spi.RoutingTableImpl - Unable to route packet. Packet should only be sent to available sessions and the route is not available. hello therereply

2012.09.05 23:59:17 org.jivesoftware.openfire.spi.RoutingTableImpl - RoutingTableImpl: Failed to route packet to JID: UserA@server/resource2 packet: hello therereply

The first log message is coming from line 298 of src/java/org/jivesoftware/openfire/spi/RoutingTableImpl.java after failing

on clientRouter.isAvailable().

if (clientRoute != null) {

if (!clientRoute.isAvailable() && routeOnlyAvailable(packet, fromServer) &&

!presenceUpdateHandler.hasDirectPresence(packet.getTo(), packet.getFrom())) {

Log.debug("Unable to route packet. Packet should only be sent to available sessions and the route is not available. {} ", packet.toXML());

routed = false;

}

[…]

The second error message is coming from line 246 of src/java/org/jivesoftware/openfire/spi/RoutingTableImpl.java inside

the routePacket() method.

if (!routed) {

if (Log.isDebugEnabled()) {

Log.debug(“RoutingTableImpl: Failed to route packet to JID: {} packet: {}”, jid, packet.toXML());

}

[…]

Confirming that it is !routed. But how do we get OpenFire to route for this other active, but non-available, resource?

1 Like

Thanks for the very detailed and thorough bug report. I don’t know if I am clever enough to help resolve this, but will note this report and try my best.