| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
| |
| |
| |
| | |
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.
|
| | |
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
With opportunistic writes enabled, writes can return what :onwritable()
returns, thus :onwritable() should return something sensible at each
spot.
Should prevent whatever caused
> Error writing to connection: (nil)
Tho this was probably harmless
|
| | |
|
| |
| |
| |
| |
| | |
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.
|
| | |
|
| |
| |
| |
| |
| | |
The value needs to be known in order to determine if additional uploads
can be accepted.
|
| |
| |
| |
| | |
Passing nil to the metrics system causes errors later.
|
| |
| |
| |
| |
| | |
Since reply.attr.to will be the .attr.from of the input we can check
this earlier and avoid constructing the reply at all.
|
| |
| |
| |
| | |
Did error_reply() not exist when mod_smacks was first created?
|
| |
| |
| |
| |
| |
| | |
Eventually the goal is to have daily tasks run while there is little
activity, but that will vary with the server and the usage patterns of
its users. This is a start anyway.
|
| |
| |
| |
| |
| | |
Merging those loops removes the miscounting that would occur in case a
file could not be deleted, so no need to limit it to that case.
|
| |
| |
| |
| |
| |
| |
| |
| | |
Not sure what the benefit of two separate loops was, perhaps reduced
memory usage by allowing archive query state to be garbage collected
before moving on to deleting files. Never measured so probably not so.
This simplifies a bit.
|
| |
| |
| |
| |
| |
| | |
This is probably a bad idea, as files that could not be deleted for some
reason will not be tried again. I was just thinking of what the 'task'
argument could be used for.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
| |
| |
| |
| |
| | |
A number of modules now have periodic tasks that need to run, e.g. for
cleaning out old messages or files. This has highlighted a need for
coordinating and optimizing scheduling of such tasks.
|
| |
| |
| |
| | |
It dates back to the initial commit in prosody-modules 9a7671720dec
|
| |
| |
| |
| | |
Mutating the stanza like this is Really Bad Practice.
|
| |
| |
| |
| |
| | |
`cached_stanza` can't be falsy because util.stanza.clone() would have
thrown rather than return nil, or `._cached=true` would have.
|
| |
| |
| |
| |
| | |
Turns out that if you destroy a session from inside prosody, it goes
into hibernation but stays connected and continues processing stanzas.
|
| |
| |
| |
| | |
Mostly sorted by name of import (sort -k4) and grouped by kind
|
| |
| |
| |
| |
| | |
In Lua, every value except `nil` and `false` are considered true in
boolean expressions, even `0` as here, which means this was dead code.
|
| |
| |
| |
| |
| | |
Non-stanza tables with an 'attr' field might be rare in Prosody, but
better to be Correct
|
| |
| |
| |
| |
| |
| | |
Given that the registry is scoped per user and the module is scoped per
host, there seems no point to checking or storing both username and host
here.
|
| | |
|
| | |
|
| |
| |
| |
| | |
Much cleaner.
|
| |
| |
| |
| |
| |
| | |
To allow modules to do things just before the session is closed. The
'(pre-)resource-unbind' events are fired after the stream is closed,
leaving no way to send something.
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
vim> Change "sevral" to:
1 "several"
2 "sacral"
3 "spiral"
4 "feral"
5 "serial"
jonas’> I choose 4.
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
If the connection is closed by the peer, any buffered data is given a
last chance to be sent (see f27b9319e0da). If the connection is Really
closed, no attempt to write will occur, instead epoll will raise the
error flag and :onreadable() will be invoked again, where it will try to
:close() again for the same reason, thus looping until the connection
somehow gets destroyed.
By clearing the _connected flag, the second time it passes :onreadable()
it should go directly to :destroy(), breaking the loop.
Thanks Link Mauve for reporting
|
| |
| |
| |
| |
| | |
This should skip the summary SQL query when not needed, ie when the
cached value can be used directly.
|
| |
| |
| |
| |
| | |
Otherwise a query for a set of ids may cause that value to be cached,
despite only covering a subset.
|
| |
| |
| |
| |
| |
| |
| | |
jid.join(true, ...) fails.
Since we don't know which users this affects, best to clear the whole
cache.
|
| |
| |
| |
| | |
More code, but less of it needs to run and no extra tracking is needed.
|
| |
| |
| |
| |
| | |
archive_store:delete(true) deletes messages for all users, which would
allow some simplification when this is supported.
|