I have an install of Openfire 3.6.4. We are able to use the system fine, but we are now testing using multiple resources for users who want to use mobile devices. Ideally we would like messages sent to all resources so that if someone forgets to logout or set away status, the message gets to the user.
I found references to route.all-resources being set to true to make this happen. I’ve set this on the server (and restarted openfire) but the behavior hasn’t changed at all. It still sends to the location a last message was sent from, and/or based on status.
I’ve checked and the clients I’m using are all setting the same priority (in this case they are set to 0, maybe that is an issue?).
Should the route.all-resources property still work in this version of openfire?
Yes. All the clients using the same account (but obviously different ‘resources’) have the same priority set. As I’m testing both my clients, iChat on a Mac, and Beejive on an iPhone, are set to priority 0.
Over lunch I got a few IM’s in, and it appears that they may actually be going to multiple locations, but some are being delayed. The first one, which I have the best sense of time on since I was in my office, was 5 minutes late. In that case it could have been an issue with the Beejive software as they are using the new push system and many details are still being hammered out.
I do know that previous to that, right after I brought the server back online I was only getting messages to one or the other though, and it wasn’t a delay.
I’m going to do a bit more playing this afternoon.
**EDIT: **it is definitely sending only to one resource. I have two iChats, one Spark, and Beehive all running, and responses always come back only to the client I sent a message from last.
Spark is the only one with a different Priority set, it is 1 as apposed to the others being 0. I’m going to look to see how to change that now, although a quick run through the menus didn’t reveal it. Since all the others are the same though, I kind of doubt it is the priority.
We are seeing the exact same behavior. I added route.all-resources in server -> server manager -> system properties, and restarted the server. I have pidgin logged in from two different locations to the same JID, both priority 1, and when I send a message from another JID, it only ends up going to one client.
I have verified this, using a small test that I’ve attached to the JIRA issue. I cannot find any problem here. I’ve added a bit of clarification in the issue itself.
Well, in our use the behavior is at best incorrect, at worst inconsistent. Typically a message will only go to the last client to send, as described above.
Randomly though it will send to multiple clients, but typically when this occurs it will only be one, maybe two, messages, then it goes back to only sending to the last client used to reply to a message.
Basically the issue makes mobile use a no go. Most users forget to set their status to away or offline when they leave their office, as many times they get a call or visit and have to run out to deal with something. Then new messages only go to their office machines and not their mobile devices.
A solution for us would be exactly what Barki127 requests. If there was an optional setting that made the server ignore the priority system and automatically send the messages to all logged in clients. This of course assumes that there isn’t some underlying bug that is occurring to some of us in rare situations that would still affect that solution.
Well, in our use the behavior is at best incorrect, at worst inconsistent. Typically a message will only go to the last client to send, as described above.
Randomly though it will send to multiple clients, but typically when this occurs it will only be one, maybe two, messages, then it goes back to only sending to the last client used to reply to a message.
Could you provide me with a dump of traffic for all affected resources, possibly annotated with “this is what we see in the client” kind of remarks.
I have used Openfire in a very large domain that focusses on mobile devices for a long time - we never had these kind of problems.
shawnparr wrote:
Most users forget to set their status to away or offline when they leave their office, as many times they get a call or visit and have to run out to deal with something. Then new messages only go to their office machines and not their mobile devices.
That is best solved by introducing an “auto-away” feature in the (office) clients. If a particular device (say, a laptop or PC) is idle for a certain amount of time, a client should automatically set a logged in session to ‘away.’ This presence should include a priority level that is lower than the ‘available’ priority in the mobile device.
The big advantage of this solution is that you don’t have to force a protocol usage that contradicts the guidelines of the XMPP specifications. From past experiences, I’ve learned that taking this road will prevent a lot of future problems. The downside is that you’ll have to have at least some control over your clients.
I will address the proposed solution an a reply to Barki127.
Hmm, before I go grabbing a dump, maybe this could explain it. In the info.log file I see a couple items like this:
2009.12.24 23:04:45 Packet sent to unreachable address
2010.01.04 08:06:07 Packet sent to unreachable address
With the ‘to’ address ending in ‘/Shawn Parr’s iPhone’ and ‘/spark’ does that mean a client is trying to send to specific resource rather than the JID of the user (and thus any appropriate resource)? If that is the case it may be mainly an iChat issue. I’d have to test how it behaves when sent messages from Spark rather than iChat to see if spark is also doing it.
This is a snippet of the XMPP specifications as defined in RFC 3921. Section 11, paragraph 1.4 reads:
(…) For message stanzas, the server SHOULD deliver the stanza to the highest-priority available resource (if the resource did not provide a value for the element, the server SHOULD consider it to have provided a value of zero). If two or more available resources have the same priority, the server MAY use some other rule (e.g., most recent connect time, most recent activity time, or highest availability as determined by some hierarchy of values) to choose between them or MAY deliver the message to all such resources. However, the server MUST NOT deliver the stanza to an available resource with a negative priority; if the only available resource has a negative priority, the server SHOULD handle the message as if there were no available resources (defined below). (…)
The suggested feature where a server delivers a message stanza to all (non-negative priority) available resource is not explicitly forbidden by the specification. It does however conflict with the recommended rules of stanza handling.
As the feature is not forbidden by the specification, I will not oppose such a feature to be added to Openfire. I do however *not recommend *users to use such a feature. You should carefully investigate the full implications of using such a feature and weigh them, before applying.
Alternative, and more recommended patterns that might help you are:
Use an ‘auto-away’ feature on clients, that drops their priority under the priority of other, but more ‘available’ resources. This causes messages to be routed to the most active resource.
Make sure that availability modi have similar priorities in different clients (e.g: ‘away’ has the same priority level in all clients). This can be used in combination with the existing route.all-resources setting (which doesn’t go against the recommendations made in the specs) to achive the desired functionality.
In specific cases (where there’s control over the client that sends the messages) it might be appropiate to send the message to all resources (using full JIDs), instead of just one resource (the bare JID). THe client can either resend the same message, or apply extended stanza addressing, as defined in XEP-0033.
Additional options can exist that are applicable to your setup.
I strongly recommend to use the solution that fits best to your setup. Don’t be tempted to pick the solution that seems the easiest to apply. In most non-trivial domains, this will eventually bite you in the ass.
An XMPP address (called a “JID”) usually comes in one of these forms (although others are valid too):
user@domain
user@domain/resource
The former is called a bare JID. The latter is a full JID.
Stanzas (XMPP packets) that are sent to a full JID are required* to be delivered to that specific resource, as you guessed. If it is addressed to a bare JID, the sender is basically asking the domain to determine where to deliver the stanza.
Note that your log snippet contains IQ stanzas, not message stanzas. These IQ stanzas have a very specific set of rules determining when to use bare or full JIDs. Additionally, it’s not clear to me if those logged stanzas are the original stanzas (as sent by the client). The addresses might have been rewritten by the server.
That aside, it is odd at best that these warnings were logged. The could indeed indicate a problem. It would be interesting to know if the problems that you’re experiencing can be linked to any specific client.
almost always true. Stuff like privacy settings might cause the server to react differently. It’s highly unlikely that you’re affected by these exceptions though.
Sorry, but i think the developers are simply not interested to implement this feature. And this is the reason why the server is only crap for the most companys.
Maybe if someone wants custom behaviour (i.e. that which does not adhere to the spec), they can build it themselves instead of expecting others to do it for them for free.
They can even supply a patch if they wish and it would at least be considered to be rolled into the product.