| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
| |
| |
| |
| | |
Non-existent did not seem entirely accurate for this case
|
| | |
|
| | |
|
| |
| |
| |
| |
| | |
Less to type if per chance the next commit also wants to access
sessions.
|
| |
| |
| |
| |
| |
| | |
To ensure that if a session is replaced after it has gone into
hibernation, it does not come back and cause trouble for the new session
(see previous commit).
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
The resumption_token is removed when the session is closed via the
pre-session-close event, signaling that it cannot be resumed, and
therefore no hibernation timeout logic should be invoked.
Fixes that if a session somehow is replaced by a new one using the same
resource (which is the common behavior), the old session would still be
around until it times out at which point it sends `<presence
type="unavailable"/>` which would look as if it came from the new
session, ie appearing offline to everyone including MUCs.
|
| |
| |
| |
| | |
Meld keeps messing up indentation when I merge and rebase...
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
This overloads that flag a bit, but it has the intended effect of
stopping outgoing_stanza_filter() from queueing stanzas.
Fixes a traceback because of the queue having been removed somewhere
around here, since it is no longer needed.
Thanks Martin for reporting
|
| |
| |
| |
| |
| |
| |
| |
| |
| | |
This brings back the queue size limit that was once added, then removed
because destroying the session when reaching the limit was not great.
Instead, the queue wraps and overwrites the oldest unacked stanza on the
assumption that it will probably be acked anyway and thus does not need
to be delivered. If those discarded stanzas turn out to be needed on
resumption then the resumption fails.
|
| |
| |
| |
| |
| | |
Extending the timeout by poking the watchdog, and letting it go on
resumption, should be much better than the previous method.
|
| |
| |
| |
| |
| |
| |
| |
| | |
All that was a complicated way to limit the number of resumable
sessions. Let's control resource usage some other way. This leaves the
essence of mapping resumption tokens to live sessions.
This keeps resumption state across reloads.
|
| | |
|
| |
| |
| |
| |
| |
| |
| |
| |
| | |
This allows clients that try to resume a session after a server restart
to at least know which of their pending outgoing stanzas were received
and which need to be re-sent.
This removes the limit on how many of those counters are kept, which
should be fixed eventually.
|
| | |
|
| |
| |
| |
| |
| | |
Since nothing uses it. Some equivalent functionality may return in the
future.
|
| | |
|
| |
| |
| |
| |
| |
| |
| | |
I have no idea what is going on in this code, which session is which?
Something has one of the sessions as an upvalue which is where the
filter checks for it.
|
| |
| |
| |
| |
| | |
Encountered what looks like a bug where after *many* resumptions, part
of the queue was not acked.
|
| |
| |
| |
| | |
Maybe it works now with the session patching in the previous commit
|
| |
| |
| |
| |
| | |
The number of places where the session is an upvalue to its own methods
is too high!
|
| |
| |
| |
| |
| |
| |
| |
| | |
As per a86ae74da96c the 'session' object here is the wrong session, so
the attempt to block stanzas from being added to the queue twice did not
work causing something of a leak.
Instead we have a leak of the previous session.
|
| |
| |
| |
| | |
The attempted fix completely broke everything after resumption.
|
| |
| |
| |
| |
| |
| | |
a86ae74da96c caused the stanza queue to double on resumption because
session.send() keeps a reference to the session which is what gets
passed to filters, so the added flag was not seen in the filter.
|
| |
| |
| |
| | |
To aid in debugging
|
| |
| |
| |
| |
| |
| | |
This should rule out error replies to PEP notifications, which come from
the account bare JID, and would be reflected back to it if they can't be
delivered for some reason, e.g. s2s problems.
|
| |
| |
| |
| |
| | |
Including the payload of the stanza that caused the error is optional
and we're generally not doing it anywhere else.
|
| |
| |
| |
| |
| | |
Mistake introduced in cbe524ed1a6a. Removing because this is a query to
the bare JID where the error origin matches the resulting stanza 'from'.
|
| |
| |
| |
| |
| |
| | |
The numeric error codes seems to have been removed from the examples in
XEP-0045 version 1.24, and were deprecated even by RFC 3920 in 2004,
only allowed for backwards compatibility.
|
| |
| |
| |
| |
| |
| | |
I spend several minutes confused over where the bug was until I
remembered I had set myself as visitor in the previous debug session.
This would have helped.
|
| |
| |
| |
| |
| | |
Allows inferring whether Direct TLS was used, or perhaps which SRV
record was chosen. Not shown by default.
|
| |
| |
| |
| |
| | |
It was previously set to the hostname, not the users bare JID which
would be correct.
|
| |
| |
| |
| |
| | |
This allows overriding it in cases where it is not equal to module.host,
like say, in mod_pep
|
| |
| |
| |
| | |
Is it not odd that um.set_roles() takes `nil` to mean global?
|
| | |
|
| |
| |
| |
| |
| | |
If you already know the account, from say the server contact info, then
this confirms their admin status.
|
| |
| |
| |
| | |
Can these even be seen?
|
| | |
|
| |
| |
| |
| |
| |
| |
| |
| | |
Needed to e.g. grant admin rights on a component, or grant non-local
users local privileges.
Leave the same host syntax for convenience, since this might be the
common case.
|
| |
| |
| |
| |
| | |
This would allow e.g. granting admin status without changing the config
and without a restart.
|
| | |
|
| | |
|
| |
| |
| |
| |
| | |
This makes it easier to reschedule or otherwise manipulate the timer
from e.g. the shell, which is handy for debugging.
|
| |
| |
| |
| | |
It was lost in 6f4790b8deec when switching to mod_cron.
|
| |
| |
| |
| |
| | |
Prefer 'prune' over 'delete' since it more strongly implies removal of
excess.
|
| | |
|
| |
| |
| |
| |
| | |
Before aa60f4353001 each loop had its own counter, seems incrementing of
one of them was lost. But only one is needed anyhow.
|
| | |
|
| |
| |
| |
| |
| |
| | |
Before mod_cron this job ran less frequently than the upload removal
job. Running them at the same frequency seems wasteful somehow, plus the
total should not drift away from the true value that fast.
|
| | |
|
| |
| |
| |
| |
| | |
Makes it more generic so new periods (e.g. weekly etc) can be added
easily.
|