is it illegal to send a presence update to multiple joined MUCs using the same szanza id?
Str4tocasterhas left
Str4tocasterhas joined
Str4tocasterhas left
Str4tocasterhas joined
jonas’
maybe
jonas’
It is up to the originating entity whether the value of the 'id'
attribute is unique only within its current stream or unique
globally.
jonas’
you’re fulfilling neither of those .. requirements .. in that case
ralphm
But treating ids as unique in its own is bound to give you grief, so better take the addressing into account.
Ge0rG
oh god who wrote that code? `if (packetID != null ? !packetID.equals(packet.packetID) : packet.packetID != null) {`
ralphm
Oops
Steve Killehas joined
lorddavidiiihas left
Ge0rGhas left
lorddavidiiihas joined
Ge0rG
So I was just sending the same presence packet to multiple @to MUCs, to my own participant JID, but it turns out only to work randomly. And from the logs it seems to have uncovered another unrelated bug.
Ge0rG
Oh my. You can't send-change-send the same Packet object in smack3.
ralphm
I think there's an assumption that clients don't repeat stanza ids on outbound traffic, but can't find the reference. As a recipient, you probably want to associate with the sender and recipient address. I'm pretty sure there are a lot of exploitable/buggy implementations.
ralphm
*especially* with MUC
Ge0rG
the problem is that I give smack3 a reference to the Packet object, not a copy. So by changing the JID, all of the enqueued references are sent to the same JID
ralphm
Haha
Ge0rG
which explains why the MUC status update happens randomly in a subset of MUCs
ralphm
That's a bad idea to try anyway
Ge0rG
because race conditions between enqueue and send thread.
Ge0rG
flow: does smack4 create a local copy of a Packet that you pass to sendPacket()?
ralphm
Yeah, once you send a stanza, don't touch it. I'm many libraries and languages.
ralphm
In
Ge0rG
See, I was just trying to be smart and to re-use resources.
Ge0rG
also, should I set the same priority for MUCs as for my normal presence, or just keep it at 0?
tahas joined
jonas’
aioxmpp would behave the same
Ge0rG
the nicest thing is, when I was debugging the user report, single-stepping through the code made the bug vanish.
jonas’
but it also has a convenient way to duplicate a stanza, so...
jonas’
oh, a heisenbug
ralphm
No, presence to MUC is directed and you can do whatever
Ge0rG
And I was short of telling the user they are crazy. After they provided logs, I got suspicious, because the 0198 logger told me the packet is not being counted, which should never happen after <enable/>
flowhas left
flowhas joined
flow
Ge0rG, no, that wouldn't be sensible, as you had to pay the copy operation for every sendStanza() whereas I'd assume only a minority calls would benefit from it
flow
but Presence has a copy constructor
flowhas left
flowhas joined
Ge0rG
flow: not in smack3 ;)
flow
yeah, I can't really comment on five year old code
Ge0rG
flow: it might be a good idea then to add a @warning to the docs, telling to never submit the same Packet twice.
Ge0rG
C++ has some sophisticated ownership management cruft around that. I don't think there is any way to enforce that in Java though
flow
I'm not sure if it justifies a warning since it is common for sink like functions that you hand over ownership of the provided arguments, but a note to the javadoc sure can't hurt
Ge0rG
it's not going to prevent people from doing what I did, leading to hard to debug issues. But after they realize what they did wrong, they'll see the message in the docs and feel even more ashamed.
jonas’
hah
flow
patches welcome ;)
Ge0rG
I had to look up the semantics of Queue.contains() and single-step through Packet.equals() to be enlighted
flowhas left
flowhas joined
marchas joined
marchas left
marchas joined
goffihas joined
404.cityhas left
lumihas joined
APachhas left
APachhas left
APachhas joined
APachhas left
APachhas joined
ralphmhas joined
Andrew Nenakhovhas joined
APachhas left
Zashhas joined
guusdkhas left
APachhas left
APachhas joined
guusdkhas left
vanitasvitaehas left
vanitasvitaehas joined
genofirehas left
mrdoctorwhohas left
mrdoctorwhohas joined
Seve
Hey guys, I couldn't attend the meeting yesterday unfortunately, but congratulations to everyone and thank you very much Alex :)
jonas’
Seve, congratulations to you, too :)
guusdkhas joined
Ge0rG
and congratulations to jonas’ as well!
jonas’
thanks, but didn’t we have that yesterday or did I miss something? ;-)
Ge0rG
jonas’: I think I didn't congratulate you specifically.