Subject: Avatars, VCards, and Threading
Alex,
I have an interesting issue: After I have sent the jabber server my presence information, I receive a presence stanza for a given contact. From the presence stanza I check my hash value for the avatar and, finding that my avatar is old (hash values don't match), I request a new vcard for the affected contact. Here's where it gets funny. At this point, I *never* receive a vcard response until another message comes thru the connection. When something comes, and it could be another presence stanza or a chat message, only then does the vcard response 'pop out.' I've found that the source of the triggering message doesn't seem to matter.
The following XMPP trace is generated while I do:
At this point, I catch the fact that I've been given an avatar hash code, I check it and find that mine is out of date, so I request for an updated vcard:
The subsequent <iq> stanza comes in right after the previous write. From this point, the application just sits there waiting. It's not really in a deadlocked state, although. The gui is active, but as I said earlier, as soon as another xmpp stanza comes it, things start flowing again. In this particular case, I have another client (one who did not generate the previous prescence w/ avatar hash) go into an 'away' state. As soon as I do that, I immediately get the vcard response, followed by the presence stanza.
You'll notice the vcard response finally comes in, quickly followed by the presence stanza from the other user. It certainly sounds like some issue with threading, but it doesn't look like a full deadlock situation.
So, here are my questions:
1) Is there something I could be doing that is clogging up the xmpp queue?
2) If so, how is it then that it only stops (as far as I know) just vcard responses.?
3) The <iq> stanza that comes in right before the big pause, is there something I'm supposed to do with it?
4) Am I supposed to respond some way it? Otherwise, am I forcing the library into a "wait-for-response" state from the libraries?
5) Should I wait until a more appropriate time? How would I do that? Not wait() or sleep() I hope
6) Since the level I'm handling the the presence stanza is at the "XMPP connection level" (i.e. agsXMPP.XmppClientConnection OnPresence() handler) I don't have a form or window in which to do an Invoke(). Is there another way?
7) Any suggestions on how I might further debug?
Sorry for being so verbose. I wanted to make sure I presented the problem as clearly as possible. Looking forward to your response...
Thanks!
Gene
I have an interesting issue: After I have sent the jabber server my presence information, I receive a presence stanza for a given contact. From the presence stanza I check my hash value for the avatar and, finding that my avatar is old (hash values don't match), I request a new vcard for the affected contact. Here's where it gets funny. At this point, I *never* receive a vcard response until another message comes thru the connection. When something comes, and it could be another presence stanza or a chat message, only then does the vcard response 'pop out.' I've found that the source of the triggering message doesn't seem to matter.
The following XMPP trace is generated while I do:
- Query for Agents
- Request Roster
- Send my presence
**********
XMPP Write:
**********
<iq xmlns="jabber:client" id="agsXMPP_3" type="get" to="padfoot"><query xmlns="jabber:iq:agents" /></iq>
**********
XMPP Write:
**********
<iq xmlns="jabber:client" id="agsXMPP_4" type="get"><query xmlns="jabber:iq:roster" /></iq>
**********
XMPP Read:
**********
<iq xmlns="jabber:client" from="padfoot" id="agsXMPP_3" to="viking1@padfoot/Viking" type="error"><query xmlns="jabber:iq:agents" /><error code="501"
type="cancel"><feature-not-implemented xmlns="urn:ietf:params:xml:ns:xmpp-stanzas" /></error></iq>
**********
XMPP Read:
**********
<iq xmlns="jabber:client" id="agsXMPP_4" to="viking1@padfoot/Viking" type="result"><query xmlns="jabber:iq:roster"><item subscription="both" jid="mini2@padfoot" /><item subscription="both" jid="miranda1@padfoot" name="Miranda1" /></query></iq>
**********
XMPP Write:
**********
<presence xmlns="jabber:client"><status>Online</status><priority>10</priority></presence>
**********
XMPP Read:
**********
<presence xmlns="jabber:client" from="mini2@padfoot/MiniClient" to="viking1@padfoot/Viking"><status /><priority>10</priority></presence>
**********
XMPP Read:
**********
<presence xmlns="jabber:client" from="miranda1@padfoot/Miranda" to="viking1@padfoot/Viking"><priority>0</priority><x
xmlns="jabber:x:avatar"><hash>0ce2de4dcce0ee2939089566b65d295c3bd07a97</hash></x><status>Yep, I'm here.</status></presence>
XMPP Write:
**********
<iq xmlns="jabber:client" id="agsXMPP_3" type="get" to="padfoot"><query xmlns="jabber:iq:agents" /></iq>
**********
XMPP Write:
**********
<iq xmlns="jabber:client" id="agsXMPP_4" type="get"><query xmlns="jabber:iq:roster" /></iq>
**********
XMPP Read:
**********
<iq xmlns="jabber:client" from="padfoot" id="agsXMPP_3" to="viking1@padfoot/Viking" type="error"><query xmlns="jabber:iq:agents" /><error code="501"
type="cancel"><feature-not-implemented xmlns="urn:ietf:params:xml:ns:xmpp-stanzas" /></error></iq>
**********
XMPP Read:
**********
<iq xmlns="jabber:client" id="agsXMPP_4" to="viking1@padfoot/Viking" type="result"><query xmlns="jabber:iq:roster"><item subscription="both" jid="mini2@padfoot" /><item subscription="both" jid="miranda1@padfoot" name="Miranda1" /></query></iq>
**********
XMPP Write:
**********
<presence xmlns="jabber:client"><status>Online</status><priority>10</priority></presence>
**********
XMPP Read:
**********
<presence xmlns="jabber:client" from="mini2@padfoot/MiniClient" to="viking1@padfoot/Viking"><status /><priority>10</priority></presence>
**********
XMPP Read:
**********
<presence xmlns="jabber:client" from="miranda1@padfoot/Miranda" to="viking1@padfoot/Viking"><priority>0</priority><x
xmlns="jabber:x:avatar"><hash>0ce2de4dcce0ee2939089566b65d295c3bd07a97</hash></x><status>Yep, I'm here.</status></presence>
At this point, I catch the fact that I've been given an avatar hash code, I check it and find that mine is out of date, so I request for an updated vcard:
**********
XMPP Write:
**********
<iq xmlns="jabber:client" id="[b]agsXMPP_5[/b]" type="get" to="miranda1@padfoot"><vCard xmlns="vcard-temp" /></iq>
**********
XMPP Read:
**********
<iq xmlns="jabber:client" from="miranda1@padfoot/Miranda" to="viking1@padfoot/Viking" type="get"><query xmlns="jabber:iq:version" /></iq>
XMPP Write:
**********
<iq xmlns="jabber:client" id="[b]agsXMPP_5[/b]" type="get" to="miranda1@padfoot"><vCard xmlns="vcard-temp" /></iq>
**********
XMPP Read:
**********
<iq xmlns="jabber:client" from="miranda1@padfoot/Miranda" to="viking1@padfoot/Viking" type="get"><query xmlns="jabber:iq:version" /></iq>
The subsequent <iq> stanza comes in right after the previous write. From this point, the application just sits there waiting. It's not really in a deadlocked state, although. The gui is active, but as I said earlier, as soon as another xmpp stanza comes it, things start flowing again. In this particular case, I have another client (one who did not generate the previous prescence w/ avatar hash) go into an 'away' state. As soon as I do that, I immediately get the vcard response, followed by the presence stanza.
**********
XMPP Read:
**********
<iq xmlns="jabber:client" from="miranda1@padfoot" id="[b]agsXMPP_5[/b]" to="viking1@padfoot/Viking" type="result"><vCard xmlns="vcard-temp"><FN>Rocko Rox</FN><N><GIVEN>Rocko</GIVEN><MIDDLE/><FAMILY>Rox</FAMILY></N><NICKNAME>miranda1</NICKNAME><BDAY>2000-01-01</BDAY><GENDER>Male</GENDER><ADR><HOME /><STREET>10101 herecomesthestick way</STREET> <EXTADR>#101</EXTADR> <EXTADD>#101</EXTADD><LOCALITY>Northridge</LOCALITY> <REGION>ca</REGION> <PCODE>91326</PCODE> <CTRY>USA</CTRY> <COUNTRY>USA</COUNTRY> </ADR><ADR><WORK/> <STREET>liverallover street</STREET><EXTADR /><EXTADD/> <LOCALITY>Northridge</LOCALITY> <REGION>CA</REGION> <PCODE>91326</PCODE> <CTRY>USA</CTRY> <COUNTRY>USA</COUNTRY> </ADR><ORG><ORGNAME>BeatingContinuously, Inc</ORGNAME> <ORGUNIT>DuckDuckOwch</ORGUNIT> </ORG><TITLE>Mr.</TITLE> <ROLE>All-Around Beat-up sort of guy</ROLE> <URL>www.takesabeating.com</URL> <DESC>asdfasdfasddfasdf</DESC> <PHOTO><TYPE>image/bmp</TYPE> <BINVAL>Qk0KAgAAAAAAADYAAAAoAAAACwAAAA0AAAABABgAAAAAANQBAAAAAAAAAAAAAAAAAAAAAAAAonRqnG5mmW1ppH99t5qav6amt5qaoXx7kWZljV9ejF5dAAAAq3xv/fLn9Nq/+uHJ/////////////tau/8KF/7x5jV9eAAAAtYd5/Pfw4b+Y69fBGiOmERaaCQyR6NW+2riR/8KFkWZlAAAAxZ+P/Pz5/Pr3/Pv4JDCyDDffERaa/Pbt/eza/tato
Xx7AAAA17qs////////////Lj/ACzjnGiOm////////////t5qaAAAA4Me5VHPuTGnlQlzZOE7NCjjvJDCyGiOmERaaCQyRwKinAAAA38OxWXv1Cjn1Cjn1Cjn1Cjn1CjjvCzjnDDffERaat5qaAAAA3LWcWXv1WXv1VHPuTGnlCjn1OE7NLj/A
JDCyGiOmoXx7AAAA3K6O/P7+/diz++bRVHPuCjn1QlzZ/Pjz9t/H+dStk2dmAAAA3q+L/P7+/P7+/P7+WXv1Cjn1TGnlwqahpHx2p3putIV0AAAA4bGM/P7+/s6f/tWtWXv1WXv1VHPusoyD/Pr12aqJyL60AAAA4bGM/P7+/P7+/P7+/P7+/P7
+/P7+soV23KyLzMG3yNDUAAAA4bGM4bGM4LCM3K2K1qeH0KCEx5h/v5B7zsrFyNDUyNDUAAAA</BINVAL></PHOTO></vCard></iq>
**********
XMPP Read:
**********
<presence xmlns="jabber:client" from="mini2@padfoot/MiniClient" to="viking1@padfoot"><show>away</show><status /><priority>10</priority></presence>
XMPP Read:
**********
<iq xmlns="jabber:client" from="miranda1@padfoot" id="[b]agsXMPP_5[/b]" to="viking1@padfoot/Viking" type="result"><vCard xmlns="vcard-temp"><FN>Rocko Rox</FN><N><GIVEN>Rocko</GIVEN><MIDDLE/><FAMILY>Rox</FAMILY></N><NICKNAME>miranda1</NICKNAME><BDAY>2000-01-01</BDAY><GENDER>Male</GENDER><ADR><HOME /><STREET>10101 herecomesthestick way</STREET> <EXTADR>#101</EXTADR> <EXTADD>#101</EXTADD><LOCALITY>Northridge</LOCALITY> <REGION>ca</REGION> <PCODE>91326</PCODE> <CTRY>USA</CTRY> <COUNTRY>USA</COUNTRY> </ADR><ADR><WORK/> <STREET>liverallover street</STREET><EXTADR /><EXTADD/> <LOCALITY>Northridge</LOCALITY> <REGION>CA</REGION> <PCODE>91326</PCODE> <CTRY>USA</CTRY> <COUNTRY>USA</COUNTRY> </ADR><ORG><ORGNAME>BeatingContinuously, Inc</ORGNAME> <ORGUNIT>DuckDuckOwch</ORGUNIT> </ORG><TITLE>Mr.</TITLE> <ROLE>All-Around Beat-up sort of guy</ROLE> <URL>www.takesabeating.com</URL> <DESC>asdfasdfasddfasdf</DESC> <PHOTO><TYPE>image/bmp</TYPE> <BINVAL>Qk0KAgAAAAAAADYAAAAoAAAACwAAAA0AAAABABgAAAAAANQBAAAAAAAAAAAAAAAAAAAAAAAAonRqnG5mmW1ppH99t5qav6amt5qaoXx7kWZljV9ejF5dAAAAq3xv/fLn9Nq/+uHJ/////////////tau/8KF/7x5jV9eAAAAtYd5/Pfw4b+Y69fBGiOmERaaCQyR6NW+2riR/8KFkWZlAAAAxZ+P/Pz5/Pr3/Pv4JDCyDDffERaa/Pbt/eza/tato
Xx7AAAA17qs////////////Lj/ACzjnGiOm////////////t5qaAAAA4Me5VHPuTGnlQlzZOE7NCjjvJDCyGiOmERaaCQyRwKinAAAA38OxWXv1Cjn1Cjn1Cjn1Cjn1CjjvCzjnDDffERaat5qaAAAA3LWcWXv1WXv1VHPuTGnlCjn1OE7NLj/A
JDCyGiOmoXx7AAAA3K6O/P7+/diz++bRVHPuCjn1QlzZ/Pjz9t/H+dStk2dmAAAA3q+L/P7+/P7+/P7+WXv1Cjn1TGnlwqahpHx2p3putIV0AAAA4bGM/P7+/s6f/tWtWXv1WXv1VHPusoyD/Pr12aqJyL60AAAA4bGM/P7+/P7+/P7+/P7+/P7
+/P7+soV23KyLzMG3yNDUAAAA4bGM4bGM4LCM3K2K1qeH0KCEx5h/v5B7zsrFyNDUyNDUAAAA</BINVAL></PHOTO></vCard></iq>
**********
XMPP Read:
**********
<presence xmlns="jabber:client" from="mini2@padfoot/MiniClient" to="viking1@padfoot"><show>away</show><status /><priority>10</priority></presence>
You'll notice the vcard response finally comes in, quickly followed by the presence stanza from the other user. It certainly sounds like some issue with threading, but it doesn't look like a full deadlock situation.
So, here are my questions:
1) Is there something I could be doing that is clogging up the xmpp queue?
2) If so, how is it then that it only stops (as far as I know) just vcard responses.?
3) The <iq> stanza that comes in right before the big pause, is there something I'm supposed to do with it?
4) Am I supposed to respond some way it? Otherwise, am I forcing the library into a "wait-for-response" state from the libraries?
5) Should I wait until a more appropriate time? How would I do that? Not wait() or sleep() I hope
6) Since the level I'm handling the the presence stanza is at the "XMPP connection level" (i.e. agsXMPP.XmppClientConnection OnPresence() handler) I don't have a form or window in which to do an Invoke(). Is there another way?
7) Any suggestions on how I might further debug?
Sorry for being so verbose. I wanted to make sure I presented the problem as clearly as possible. Looking forward to your response...
Thanks!
Gene