Presence changes are not being broadcasted to other connected resources

Details

Type: Bug
Status: Closed
Priority: Critical
Resolution: Fixed
Affects Version/s: 2.6.2
Fix Version/s: 3.0.0
Component/s: Core
Labels:
None

Acceptance Test - Add?:
No

Description

1) Log into the server from 2 different clients
2) Change the presence to away in one client
3) The other client should get a presence change notification

Step 3 is not hapenning.

Activity

Ascending order - Click to sort in descending order

Hide

Permalink

Les Bowen added a comment - 06/05/06 07:55 PM

I believe this is the bug that I wote about in my post: http://www.jivesoftware.org/community/message.jspa?messageID=122045

Show

Les Bowen added a comment - 06/05/06 07:55 PM I believe this is the bug that I wote about in my post: http://www.jivesoftware.org/community/message.jspa?messageID=122045

Hide

Permalink

Sam Stainsby added a comment - 06/07/06 10:14 AM

I have switched off LDAP and SSL and still get this problem.

Any chance of a 2.6.3 release? This is holding up our deployment. Should we try an older verison, or is 3.0.0 due out Real Soon Now (TM).

Show

Sam Stainsby added a comment - 06/07/06 10:14 AM I have switched off LDAP and SSL and still get this problem. Any chance of a 2.6.3 release? This is holding up our deployment. Should we try an older verison, or is 3.0.0 due out Real Soon Now (TM).

Hide

Permalink

Sam Stainsby added a comment - 06/08/06 04:46 AM

To add more detail, I've been looking at shared rosters today. The presence problem seems to go away if you restart the wildfire server after creatign the shared roster, in all cases, except when using LDAP as the provider for users and groups. So there may be two separate problems here.

Show

Sam Stainsby added a comment - 06/08/06 04:46 AM To add more detail, I've been looking at shared rosters today. The presence problem seems to go away if you restart the wildfire server after creatign the shared roster, in all cases, except when using LDAP as the provider for users and groups. So there may be two separate problems here.

Hide

Permalink

Les Bowen added a comment - 06/08/06 11:51 PM

That is my assessment as well. After creating groups (without LDAP), I had to reinitiate contact from each client. that could be done by disconnecting everyone and then reconnecting. But restarting wildfire ensures that all cients are disconnected. And likewise, it's still a no-go with LDAP.

And Sam, I believe that the problem did not exist in 2.6.1. there are a few other bugs that have surfaces from the 2.6.2 release that are significant problems, since we used them in the 2.6.0 and later releases. I'm considering a downgrade so that I can get the LDAP hooked in.

Show

Les Bowen added a comment - 06/08/06 11:51 PM That is my assessment as well. After creating groups (without LDAP), I had to reinitiate contact from each client. that could be done by disconnecting everyone and then reconnecting. But restarting wildfire ensures that all cients are disconnected. And likewise, it's still a no-go with LDAP. And Sam, I believe that the problem did not exist in 2.6.1. there are a few other bugs that have surfaces from the 2.6.2 release that are significant problems, since we used them in the 2.6.0 and later releases. I'm considering a downgrade so that I can get the LDAP hooked in.

Hide

Permalink

Sam Stainsby added a comment - 06/09/06 04:22 AM

Don't bother trying 2.6.1 .. I found exactly the same problem, at least with LDAP users/groups and group-based shared rosters.

Maybe time to switch back to ejabberd and suffer scripts and cron jobs to update the group-based rosters.

Show

Sam Stainsby added a comment - 06/09/06 04:22 AM Don't bother trying 2.6.1 .. I found exactly the same problem, at least with LDAP users/groups and group-based shared rosters. Maybe time to switch back to ejabberd and suffer scripts and cron jobs to update the group-based rosters.

Hide

Permalink

Les Bowen added a comment - 06/22/06 09:16 PM

Just did a little debugging... I am now in 3.0.0 beta, on OS X 10.4.6, with LDAP and MySQL.

Wildfire starts up without a hitch. Nothing unusual in debug or any other log files.

When the first user logs in, I get a bunch of output into debug, as the server looks through the LDAP setup and parses users and such. Nothing unusual. No errors.

Same goes for when the second user logs in. No errors, nothing unusual, other than the first user gets no presence notification. But this is not in the log files.

First user disconnects...

debug output is:

============
2006.06.22 13:07:49 Logging off <user>@<server fqdn>/<remote client id> on org.jivesoftware.wildfire.net.SocketConnection@28482b socket: 3acf34[SSL_RSA_WITH_RC4_128_SHA: Socket[addr=/<remote ip>,port=49227,localport=5223]] session: org.jivesoftware.wildfire.ClientSession@18c8ca status: 3 address: <user>@<server fqdn>/<remote client id> id: b97e019 presence:
<presence from="<user>@<server fqdn>/<remote client id>">
<priority>0</priority>
<x xmlns="vcard-temp:x:update">
<photo><hash></photo>
</x>
<c xmlns="http://jabber.org/protocol/caps" node="apple:ichat:caps" ver="429" ext="avcap avavail maudio"/>
<x xmlns="http://jabber.org/protocol/tune"/>
</presence>
============

Client is Apple iChat, but I get similar results from Spark.

I doubt this helps. If I can helps by debugging, I'm willing to help. I'm no developer by any means, but I know my way aroung a command line. So if there are any bugfizes for this, I'd be happy to help test them. Just let me know.

Show

Les Bowen added a comment - 06/22/06 09:16 PM Just did a little debugging... I am now in 3.0.0 beta, on OS X 10.4.6, with LDAP and MySQL. Wildfire starts up without a hitch. Nothing unusual in debug or any other log files. When the first user logs in, I get a bunch of output into debug, as the server looks through the LDAP setup and parses users and such. Nothing unusual. No errors. Same goes for when the second user logs in. No errors, nothing unusual, other than the first user gets no presence notification. But this is not in the log files. First user disconnects... debug output is: ============ 2006.06.22 13:07:49 Logging off <user>@<server fqdn>/<remote client id> on org.jivesoftware.wildfire.net.SocketConnection@28482b socket: 3acf34[SSL_RSA_WITH_RC4_128_SHA: Socket[addr=/<remote ip>,port=49227,localport=5223]] session: org.jivesoftware.wildfire.ClientSession@18c8ca status: 3 address: <user>@<server fqdn>/<remote client id> id: b97e019 presence: <presence from="<user>@<server fqdn>/<remote client id>"> <priority>0</priority> <x xmlns="vcard-temp:x:update"> <photo><hash></photo> </x> <c xmlns="http://jabber.org/protocol/caps" node="apple:ichat:caps" ver="429" ext="avcap avavail maudio"/> <x xmlns="http://jabber.org/protocol/tune"/> </presence> ============ Client is Apple iChat, but I get similar results from Spark. I doubt this helps. If I can helps by debugging, I'm willing to help. I'm no developer by any means, but I know my way aroung a command line. So if there are any bugfizes for this, I'd be happy to help test them. Just let me know.

Hide

Permalink

Steve Smith added a comment - 01/04/07 02:47 AM

We (Atlassian) are still seeing this issue with Enterprise 3.1.1.

Show

Steve Smith added a comment - 01/04/07 02:47 AM We (Atlassian) are still seeing this issue with Enterprise 3.1.1.

Hide

Permalink

Martin Drößler added a comment - 05/21/07 03:52 PM

The problem still exists in the current version.
When using LDAP, all contacts have subscription-status SUB_TO
but in org.jivesoftware.openfire.roster.Roster.broadcastPresence(Presence packet) the presence is only broadcasted
if (item.getSubStatus() == RosterItem.SUB_BOTH || item.getSubStatus() == RosterItem.SUB_FROM)

The best solution is to change the default subscription-status of LDAP-users to SUB_BOTH - or at least make it configureable.

Show

Martin Drößler added a comment - 05/21/07 03:52 PM The problem still exists in the current version. When using LDAP, all contacts have subscription-status SUB_TO but in org.jivesoftware.openfire.roster.Roster.broadcastPresence(Presence packet) the presence is only broadcasted if (item.getSubStatus() == RosterItem.SUB_BOTH || item.getSubStatus() == RosterItem.SUB_FROM) The best solution is to change the default subscription-status of LDAP-users to SUB_BOTH - or at least make it configureable.

Hide

Permalink

dede added a comment - 02/29/08 11:56 AM

Show

People

Assignee:

Gaston Dombiak

Reporter:

Gaston Dombiak

Vote (4)

Watch (4)

Dates

Created:

05/30/06 09:21 PM

Updated:

02/29/08 11:56 AM

Resolved:

06/25/06 05:11 AM