here is one login with only 2 msn contacts. for every msn contact i get :
1 roster update
1 unavailable (sometimes it’'s like the other 2 status messages)
2 status messages (always identical) - only for online contacts
i have one user that has unbelievable amount of msn contacts (~ 1000). and there are sometimes about ~3000 packets send in only 1/2 minute (1 MB traffic). and the most of that is not really needed.
i understand that the roster update is being send to the client, because something could have changed sine the last login, but the status message are annoying. also it would be a nice feature to turn of this roster updates to save bandwith on mobiles. the correct roster will be sent anyway on the next login.
these log i have stripped from my internal test-server. but the behavior is the same on the live environment.
another NPE i got with the last version on this thread:
2007.06.05 00:02:50 [org.jivesoftware.openfire.gateway.BaseTransport.processPacket(BaseTransport.java:411)] Exception while processing packet: java.lang.NullPointerException
at org.jivesoftware.openfire.gateway.protocols.msn.MSNSession.logIn(MSNSession.java:118)
at org.jivesoftware.openfire.gateway.protocols.msn.MSNTransport.registrationLoggedIn(MSNTransport.java:89)
at org.jivesoftware.openfire.gateway.BaseTransport.processPacket(BaseTransport.java:324)
at org.jivesoftware.openfire.gateway.BaseTransport.processPacket(BaseTransport.java:166)
at org.jivesoftware.openfire.component.InternalComponentManager$RoutableComponent.process(InternalComponentManager.java:490)
at org.jivesoftware.openfire.roster.Roster.broadcastPresence(Roster.java:590)
at org.jivesoftware.openfire.handler.PresenceUpdateHandler.broadcastUpdate(PresenceUpdateHandler.java:258)
at org.jivesoftware.openfire.handler.PresenceUpdateHandler.process(PresenceUpdateHandler.java:100)
at org.jivesoftware.openfire.handler.PresenceUpdateHandler.process(PresenceUpdateHandler.java:88)
at org.jivesoftware.openfire.handler.PresenceUpdateHandler.process(PresenceUpdateHandler.java:151)
at org.jivesoftware.openfire.PresenceRouter.handle(PresenceRouter.java:123)
at org.jivesoftware.openfire.PresenceRouter.route(PresenceRouter.java:69)
at org.jivesoftware.openfire.spi.PacketRouterImpl.route(PacketRouterImpl.java:75)
at org.jivesoftware.openfire.SessionPacketRouter.route(SessionPacketRouter.java:134)
at org.jivesoftware.openfire.SessionPacketRouter.route(SessionPacketRouter.java:73)
at org.jivesoftware.openfire.multiplex.MultiplexerPacketHandler.route(MultiplexerPacketHandler.java:164)
at org.jivesoftware.openfire.net.MultiplexerStanzaHandler.processRoute(MultiplexerStanzaHandler.java:89)
at org.jivesoftware.openfire.net.MultiplexerStanzaHandler.processUnknowPacket(MultiplexerStanzaHandler.java:96)
at org.jivesoftware.openfire.net.StanzaHandler.process(StanzaHandler.java:258)
at org.jivesoftware.openfire.net.StanzaHandler.process(StanzaHandler.java:153)
at org.jivesoftware.openfire.nio.ConnectionHandler.messageReceived(ConnectionHandler.java:132)
at org.apache.mina.common.support.AbstractIoFilterChain$TailFilter.messageReceived(AbstractIoFilterChain.java:703)
at org.apache.mina.common.support.AbstractIoFilterChain.callNextMessageReceived(AbstractIoFilterChain.java:362)
at org.apache.mina.common.support.AbstractIoFilterChain.access$1100(AbstractIoFilterChain.java:54)
at org.apache.mina.common.support.AbstractIoFilterChain$EntryImpl$1.messageReceived(AbstractIoFilterChain.java:800)
at org.apache.mina.filter.codec.support.SimpleProtocolDecoderOutput.flush(SimpleProtocolDecoderOutput.java:62)
at org.apache.mina.filter.codec.ProtocolCodecFilter.messageReceived(ProtocolCodecFilter.java:200)
at org.apache.mina.common.support.AbstractIoFilterChain.callNextMessageReceived(AbstractIoFilterChain.java:362)
at org.apache.mina.common.support.AbstractIoFilterChain.access$1100(AbstractIoFilterChain.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(ExecutorFilter.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)
Hi notz, these look like logs from your client, not from openfire. Can I get a copy of the debug logs from the server itself? I’‘ve got a grande scheme to revamp the contact list handling overall, but I’‘m generally curious about why there’‘s so many multiples. I can’'t tell “why” from these logs. =)
i have now debugged the current trunk version for my problems:
1.) roster update
i see that you already check if something have changed and only send the update if something has changed, but for me the groups always change, so there have to be something wrong on that check
The priority really doesn’‘t make a difference in how I approach the issues. ICQ is still listed as an unstable transport for now anyway. There’‘s still a lot of work that’‘ll need to be done to it before I’'ll be moving it to stable.
Hrm. Yes that’‘s definitely a bad check. Thanks for looking into that! I’'ll look at it later today. Thanks for the patch you posted in a different reply!
2.) why we need the initial presences on msn transport ? i don’'t think that they are nedded
Well I can tell you that when I -didn’‘t- do them, people would complain. You’‘ll come online and folk who have been online for hours won’‘t show up until their presence changes. Some folk’‘s clients send presence updates a -lot- so it appears like you get an initial presence from them when you are really getting a change. If that behavior has changed I’'m certainly willing to entertain not doing the initial settings. Other protocols behave differently from this. OSCAR, for example, gives you your buddy list and then you must wait for status notifications just like any other one. Much more siimilar in behavior to XMPP if you ask me. By logging in you are effectively “precense probing” everyone. I like that behavior a lot better.
3.) this function is called twice in the MSNListener on login for online contacts:
public void contactStatusChanged(MsnMessenger messenger, MsnContact friend) {
Interesting. I wonder why it’‘s called twice? That’‘s supposed to be reactionary. Bah. Well the big thing I’‘m planning on doing is to rework the contact handling entirely. Instead of sending contact statuses on the fly, I’'m going to store them, and only send when something has changed.
notz wrote:
so there is one initial presence, and two times these message where friend.getStatus() is both times the same
i have now debugged the current trunk version for my problems:
1.) roster update
i see that you already check if something have changed and only send the update if something has changed, but for me the groups always change, so there have to be something wrong on that check
Well, the oddest thing. This morning I went to make sure I was still having the problem before I posted and it appears to be gone (rather randomly because I didn’‘t change anything). Just for information though I’'m going to enable the debug logs so if the problem reoccurs I can send a copy of them.
OS Version: Gentoo Linux
Java version: 1.5.0_11 Sun Microsystems Inc
Openfire version 3.3.1
I haven’'t run any versions earlier than this current beta.
Client: Psi 0.10
I wasn’'t logged in from multiple resources when the problem occurred.
and both are the same and should not trigger the changed flag
Hrm. Yes I see your point. I originally thought was just going to make groups -be- an empty list if it was null, cut down on the checks. Lemme think through how best I want to do it. Thanks!
Well, the oddest thing. This morning I went to make sure I was still having the problem before I posted and it appears to be gone (rather randomly because I didn’‘t change anything). Just for information though I’'m going to enable the debug logs so if the problem reoccurs I can send a copy of them.
OS Version: Gentoo Linux
Java version: 1.5.0_11 Sun Microsystems Inc
Openfire version 3.3.1
I haven’'t run any versions earlier than this current beta.
Client: Psi 0.10
I wasn’'t logged in from multiple resources when the problem occurred.
Nope, I mean I literally did nothing. After I posted my message yesterday I walked away from the system till this morning and everything was working great again. Uptime for Openfire is around 12 days right now.
Ive found that most of the time when i login, i will get a popup about yahoo users requesting authorization. These users were people i blocked years ago on yahoo. I deny the request and uncheck the box to add them to my roster in spark but they continue to popup as authorization requests on login.
I noticed that the XMPP/Google Talk gateway ticked is closed and we can expect this to be in the 1.1.0 release. Will there be another beta, so we can test this before the release.
After I posted my message yesterday I walked away from the system till this morning and everything was working great again. Uptime for Openfire is around 12 days right now.