powered by Jive Software

Presence Problems

Hi,

I’m using Openfire 3.3.2, Enterprise 3.3.2, Spark 2.5.6, and Pidgin 2.1.1. Also using LDAP from Windows 2003 AD with AD group filtering enabled.All groups are shared to all other groups. Loggin in and out and basic messaging functionality works fine.

Users aren’t getting notified when people log in/out, or change their status. The only way to force an update of the current users on the system is to log out and log back on.

I’ve restarted the server, and only let one user log in. Here’s the error log from the one user. (All other users give similar errors):

2007.09.06 20:32:46

[org.jivesoftware.openfire.ldap.LdapGroupProvider.getGroupNames(LdapGroupProvide r.java:383)

] Error getting groups for user: tuser2@blah.com

javax.naming.CommunicationException: Request: 419

cancelled; remaining name ‘’

at com.sun.jndi.ldap.LdapRequest.getReplyBer(Unknown

Source)

at com.sun.jndi.ldap.Connection.readReply(Unknown Source)

at com.sun.jndi.ldap.LdapClient.getSearchReply(Unknown

Source)

at com.sun.jndi.ldap.LdapClient.search(Unknown Source)

at com.sun.jndi.ldap.LdapCtx.doSearch(Unknown Source)

at com.sun.jndi.ldap.LdapCtx.searchAux(Unknown Source)

at com.sun.jndi.ldap.LdapCtx.c_search(Unknown Source)

at

com.sun.jndi.toolkit.ctx.ComponentDirContext.p_search(Unknown Source)

at com.sun.jndi.toolkit.ctx.PartialCompositeDirContext.search(Unknown

Source)

at

com.sun.jndi.toolkit.ctx.PartialCompositeDirContext.search(Unknown Source)

at

javax.naming.directory.InitialDirContext.search(Unknown Source)

at org.jivesoftware.openfire.ldap.LdapGroupProvider.getGroupNames(LdapGroupProvide r.java:367)

at

org.jivesoftware.openfire.group.GroupManager.getGroups(GroupManager.java:343)

at

org.jivesoftware.openfire.roster.Roster.<init>(Roster.java:94)

at

org.jivesoftware.openfire.roster.RosterManager.getRoster(RosterManager.java:92)

at

org.jivesoftware.openfire.user.User.getRoster(User.java:289)

at

org.jivesoftware.openfire.handler.IQRosterHandler.manageRoster(IQRosterHandler.j ava:200)

at

org.jivesoftware.openfire.handler.IQRosterHandler.handleIQ(IQRosterHandler.java: 105)

at

org.jivesoftware.openfire.handler.IQHandler.process(IQHandler.java:48)

at

org.jivesoftware.openfire.IQRouter.handle(IQRouter.java:300)

at

org.jivesoftware.openfire.IQRouter.route(IQRouter.java:104)

at org.jivesoftware.openfire.spi.PacketRouterImpl.route(PacketRouterImpl.java:67)

at

org.jivesoftware.openfire.net.StanzaHandler.processIQ(StanzaHandler.java:289)

at

org.jivesoftware.openfire.net.ClientStanzaHandler.processIQ(ClientStanzaHandler. java:79)

at org.jivesoftware.openfire.net.StanzaHandler.process(StanzaHandler.java:254)

at

org.jivesoftware.openfire.net.StanzaHandler.process(StanzaHandler.java:153)

at

org.jivesoftware.openfire.nio.ConnectionHandler.messageReceived(ConnectionHandle r.java:132)

at org.apache.mina.common.support.AbstractIoFilterChain$TailFilter.messageReceived (AbstractIoFilterChain.java:703)

at

org.apache.mina.common.support.AbstractIoFilterChain.callNextMessageReceived(Abs tractIoFilterChain.java:362)

at

org.apache.mina.common.support.AbstractIoFilterChain.access$1100(AbstractIoFilte rChain.java:54)

at

org.apache.mina.common.support.AbstractIoFilterChain$EntryImpl$1.messageReceived (AbstractIoFilterChain.java:800)

at

org.apache.mina.filter.codec.support.SimpleProtocolDecoderOutput.flush(SimplePro tocolDecoderOutput.java:62)

at org.apache.mina.filter.codec.ProtocolCodecFilter.messageReceived(ProtocolCodecF ilter.java:200)

at

org.apache.mina.common.support.AbstractIoFilterChain.callNextMessageReceived(Abs tractIoFilterChain.java:362)

at

org.apache.mina.common.support.AbstractIoFilterChain.access$1100(AbstractIoFilte rChain.java:54)

at

org.apache.mina.common.support.AbstractIoFilterChain$EntryImpl$1.messageReceived (AbstractIoFilterChain.java:800)

at org.apache.mina.filter.executor.ExecutorFilter.processEvent(ExecutorFilter.java :266)

at

org.apache.mina.filter.executor.ExecutorFilter$ProcessEventsRunnable.run(Executo rFilter.java:326)

at

java.util.concurrent.ThreadPoolExecutor$Worker.runTask(Unknown Source)

at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown

Source)

at java.lang.Thread.run(Unknown Source)

Any suggestions?

-Tony

More information:

If I disable group sharing completely, and then add a user manually, I get state changes correctly. When I enable the sharing of groups, it breaks again. This makes me think I have something going on with the way groups are configured. Here’s my group filtering line from the conf file:

<groupSearchFilter> <![CDATA[(|(CN=zLIST HELP) (CN=zLIST ASKHOMER: AskHomer Live)(CN=zLIST ITS: ITS Area staff)(CN=zLIST RIS: Research & Information Services)(CN=zLIST ACCESSRV: Access Services Staff)(CN=zLIST COLLSERV: Collection Services Staff)(CN=zLIST DODD: DRC Area Staff)(CN=zLIST ADMINOFF: ADM Staff)(CN=zLIST RCLCALL: Regional Campus Libraries Staff)))]]></groupSearchFilter>

Could something be wrong there?

Hi,

When you were setting up openfire, and entered your group settings, were you able to test this to see if you were entering the correct search filter?

I have something much simpler in my AD setup, <groupSearchFilter>(objectClass=group)</groupSearchFilter>

-Will

My current search filter string works fine. I can see just the groups I want to see, and people can log in and get grouped correctly.

The main problem now is that people’s state changes do not get passed along at all after logging in. This is making things rather useless, especially for our FastPath users, since they aren’t sure whther another user on the system is available or not.

-Tony

Could you send a copy of your logs into support at jivesoftware.com? Any common thread on when the users don’t get/set their update status?

Log files sent. Thanks for helping.

-Tony

Tony,

I didn’t see anything helpful in the logs. I think there are a couple possible things that could be happening.

  1. The updated presence packets are being sent and dropped somewhere along they way (server or network)

  2. The updated presence is being received but not interpreted/applied correctly.

To address possibility number 1 could you install the stats plugin here :

http://wiki.igniterealtime.org/download/attachments/229451/loadStats.jar

This will create a stats.txt in your log directory. It should tell us if your server is having issues sending out packets in timely fashion.

To address issue number 2 I would use the Spark debugger. To get access to this, log out of Spark then click “Advanced”-Check the “Start Debugger on startup” box. This should launch the debugging window when you login. What you want to look for is messages that are marked as “Presence Received”

If you see any packets that are marked as “Presence Received”, could you send me the xml?

Cheers,

Nate

For the debug in spark, I ran it, and after my initial login (where I get initial presence messages), I never get anymore presence packets. I do show me sending packets when I change my status, and I had 3 users all changing their statuses and logging in and out, but I never got any of their presence notifcations. I’ll e-mail the log of raw received packets so you can see.

I ran the stats plugin for a few hours, and am e-mailing that log as well.

Thanks again for helping.

Tony

Just to test, I removed the group filter completely and had 2 users login. They added each other manually to their rosters. We opened the Spark debugger, and the presence packets were sent and received as expected anytime the user changed status. Hopefully that might help in diagnosing this problem.

-Tony

FYI, I upgraded to 3.3.3 over the weekend, but the problem still persists. Have you had a chance to look into this further?

-Tony

Just a follow up to this… we found the problem and of all things it ended up being an extra parentheses at the end of my group filter. Thanks to Nate for spending so much time on helping me fix it.