Tried again - no joy.

I get this logged:

2007.06.01 23:04:53 [org.jivesoftware.util.log.util.CommonsLogFactory$1.error(CommonsLogFactory.jav a:87)

] Line=19 The content of element type "dwr" must match "(init?,allow?,signatures?)".

ICQ contacts still "awaiting authorization" but ICQ-users realy get auth-request... But when it accepted, gateway don`t change status of ICQ-contact..

Tested whith JAJC, Psi, Pandion etc...

GATE-234

- PLEASE increase priority of that problem, ICQ is most popular messenger, and only that bug prevent start new Openfire server...

is there a chance to get away from this duplicate presence messages on login ?

2007.06.04 12:08:39

i know it doesn''t matter on desktop clients, but on mobile handsets it''s a problem.

normally one of these presence messages (available/unavailable) per contact schould be enough or i''m wrong ?

no, i don''t get duplicate messages only duplicate presences.

here is one login with only 2 msn contacts. for every msn contact i get :

1 roster update not needed

1 unavailable (sometimes it''s like the other 2 status messages) not needed

2 status messages (always identical) - only for online contacts only 1 needed

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.

2007.06.04 20:09:47 <?xml version=''1.0''?>
2007.06.04 20:09:47 <stream:stream xmlns:stream=''http://etherx.jabber.org/streams'' xmlns=''jabber:client'' to=''test.im'' xml:lang=''de''>
2007.06.04 20:09:47 <?xml version=''1.0'' encoding=''UTF-8''?><stream:stream xmlns:stream="http://etherx.jabber.org/streams" xmlns="jabber:client" from="192.168.11.159" id="ur1evd4d0545a" xml:lang="de"></stream:stream>
2007.06.04 20:09:47 <iq id="10" type="set" to="test.im"><query xmlns="jabber:iq:auth"><username>666763076977</username><password>xxx</password></query></iq>
2007.06.04 20:09:47 <iq type="result" id="10" from="test.im" to="666763076977@test.im"></iq>
2007.06.04 20:09:47 <iq id="11" type="get"><query xmlns="jabber:iq:roster"></query></iq>
2007.06.04 20:09:47 <presence></presence>
2007.06.04 20:09:47 <iq type="result" id="11" to="666763076977@test.im"><query xmlns="jabber:iq:roster"><item jid="yahoo.test.im" name="Yahoo! Transport" subscription="both"><group>Transports</group></item>
<item jid="notz99@yahoo.test.im" name="notz99" subscription="to"></item><item jid="666766688669@test.im" name="mortn" ask="subscribe" subscription="none"></item>
<item jid="666766688650@test.im" name="mahatma" subscription="both"></item><item jid="666766688781@test.im" name="markus" subscription="both"></item><item jid="666763588076@test.im" name="Murph" subscription="both"></item>
<item jid="msn.test.im" name="MSN Transport" subscription="both"><group>Transports</group></item><item jid="666763076976@test.im" name="notz77" subscription="both"></item>
<item jid="tina94\40test.at@msn.test.im" name="tina" subscription="to"></item><item jid="notz\40test.at@msn.test.im" name="notz@test.at" subscription="to"></item>
<item jid="666769080712@test.im" name="test" ask="subscribe" subscription="none"></item></query></iq>
2007.06.04 20:09:48 <iq type="set" id="262-420" to="666763076977@test.im"><query xmlns="jabber:iq:roster"><item jid="notz99@yahoo.test.im" name="notz99" subscription="to"></item></query></iq>
2007.06.04 20:09:48 <presence to="666763076977@test.im" from="notz99@yahoo.test.im" type="unavailable"></presence>
2007.06.04 20:09:48 <presence to="666763076977@test.im" from="yahoo.test.im"></presence>
2007.06.04 20:09:48 <iq type="set" id="408-421" to="666763076977@test.im"><query xmlns="jabber:iq:roster"><item jid="notz99@yahoo.test.im" name="notz99" subscription="to"></item></query></iq>
2007.06.04 20:09:48 <presence to="666763076977@test.im" from="notz99@yahoo.test.im" type="unavailable"></presence>
2007.06.04 20:09:52 <presence to="666763076977@test.im" from="msn.test.im"></presence>
2007.06.04 20:09:53 <presence to="666763076977@test.im" from="notz\40test.at@msn.test.im"><status></status></presence>
2007.06.04 20:09:53 <presence to="666763076977@test.im" from="notz\40test.at@msn.test.im"><status></status></presence>
2007.06.04 20:09:53 <presence to="666763076977@test.im" from="tina94\40test.at@msn.test.im"><show>away</show><status></status></presence>
2007.06.04 20:09:53 <presence to="666763076977@test.im" from="tina94\40test.at@msn.test.im"><show>away</show><status></status></presence>
2007.06.04 20:09:53 <iq type="set" id="189-422" to="666763076977@test.im"><query xmlns="jabber:iq:roster"><item jid="tina94\40test.at@msn.test.im" name="tina" subscription="to"></item></query></iq>
2007.06.04 20:09:53 <iq type="set" id="440-423" to="666763076977@test.im"><query xmlns="jabber:iq:roster"><item jid="notz\40test.at@msn.test.im" name="notz@test.at" subscription="to"></item></query></iq>
2007.06.04 20:09:53 <presence to="666763076977@test.im" from="tina94\40test.at@msn.test.im"><show>away</show></presence>
2007.06.04 20:09:53 <presence to="666763076977@test.im" from="notz\40test.at@msn.test.im"></presence>

for icq contacts i get:

1 roster update

1 status message

this code change resolves the problem no. 1 for me:

List<String> curgroups = gwitem.getGroups();
if ((groups == null && curgroups.size() != 0) || (groups != null && !curgroups.containsAll(groups))) {
.
.
}

the problem is that you match an empty list against an null value or match to lists aigainst each other, what also is not working correct.

hi notz,

i am running a mobile application too and i used to have that problem until today. I have found the solution for the duplicate presences and also duplicate iq packets  (This happens,int the first connect after you restart the openfire server) in every gateways. Tomorrow i will be testing with my team.

hi daniel,

i am talking about  duplicate iq packets in the first connection and about lots of presence packets of just one user.

duplicate iq problems: when a user first connects to any service (msn, gtalk, icq etc), the gateway sync the roster. In this process, you get two iq packets per your contact. first iq contains only the jid with a "none" subscription, and then gateway sends another iq packet, which has the name of the user, for this user. So the first iq is sent by openfire because of the following code in the BaseTransport class.

// Create new roster item for the gateway service or legacy contact. Only

// roster items related to the gateway service will be persistent. Roster

// items of legacy users are never persisted in the DB.

RosterItem gwitem = roster.createRosterItem(contactjid, true, contactjid.getNode() == null);

in this code, while creating new roster item, gateway pushes the new roster item to the client, which i believe that it shouldn''t. Because in the next lines,  it will push the roster with:

roster.updateRosterItem(gwitem);

so the gateway should call the "createRosterItem" method with false in the 2nd argument, which decides pushing the newly created roster item.

lots of presence packets: in fact this is not a bug or error. but it is a thing that can be optimized. while we start the services (msn, gtalk etc, ''i do not know how you call these''), their listeners begin to listen and process what they get as soon as possible. but for the presences changes, we need to make presence listeners wait until we sync the rosters. Because in the "syncUsers()" method, we already send the initial prences of our roster items. (of course, this is not a solution for the msn UBX  packets, it is normal that you can get 2 presence for the user anyway.)

as a conclusion, by fixing (maybe wrong word) the above codes, i can sign an msn users, that has a 21 contacts, with just ~7kb in stead of ~18kb. Since my client is mobile ( http://www.cepteki.net  - english version is in progress) 11kb is really a big traffic.

after my tests, i will post my codes in here, so you can test that also.

(sorry for my poor english, i hope i was clear.)

for handling the presences, i have modified the msn library (jml.jar) and added some extra methods like

-MsnContactImpl

getOldCurrentMedia()

getOldPersonalMessage()

and also, i use MsnUserImpl to get the oldDisplayMessage and oldStatus. By the help of these methods, now i can track the users''s info, so that i can decide if i need to push or not.

This is also a solution for duplicate msn server''s presence commands. If you check you debug, you can see that msnp 11 can send one or more presence commands for one user. So sometimes, openfire need to send you "4" presence message for the same user. But now, it can''t

Now the only problem is the seperate presences i get from msn server. They are; NLN (FLN, IDL etc.)  and UBX. I think there is no solution for that.

Anyway, my tests are still in progress, i will let you know the updates.

I''ve just installed the latest version (which looking at the file modification times seemed to install ok).

However, no change in behaviour; when I log out of MSN my status remains and the lag is about 60 seconds today on changing status messages.

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.

Thanks,

Chad

Nope, I mean I literally did nothing. :-D 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.

--Chad