It should not be there afterwards. Noticed that it seems to fire some
time after resumption claiming that the queue size is nil, implying
that it may hold a reference to an expired session somehow.
Many of these fall into a few categories:
- util.cache size, must be >= 1
- byte or item counts that logically can't be negative
- port numbers that should be in 1..0xffff
Both in the flushing and active states the right thing to do is skip
directly to returning the data. Also in any unknown state, like if the
filter is somehow left behind on module unload.
Statistics from my server shows a high rate of very short buffer hold
times, most of which are the result of replies to pings or other iq
traffic, or mod_smacks acks and ack requests just after a flush was
completed.
This grace period should eliminate noise and quick flipping between
flushing and inactive mode.
Since it changes the state to "flushing" while doing just that.
Attempting to remove the filters from a session that does not have them
should be a safe noop.
E.g. mod_smacks could queue an <r>, which would be more likely to be
included in the same write and TCP segment as the previously buffered
data, reducing syscalls and network packets needing to be sent.
The default of 0.001..100.0 did not feel suitable here. This might be
better. Longer is better and hold times less than a few seconds is
generally undesirable.
This is either dead code or actually a type error, but catching that
should be the responsibility of the session.send function. This type
check is left since everything after it assumes a stanza object.
These last few commits aren't meant to change any behavior and it did
mark things not stanzas as important, but those would have been mostly
raw strings which are now specially handled.
Single space character is sent by mod_c2s when a session has been
silent for some time. This should account for the vast majority of raw
strings passing through here. If this is not the case then having stats
to say otherwise will be interesting.
To make it easier to find implemented Experimental XEPs later. Also at
the time of this commit it has been Proposed as mentinoed in the
comment but hopefully that will be resolved soon.
A large share of `<presence type=error>` appears to be noise from large
public channels and failed presence probes. The later at least should
count as presence updates, which are currently considered unimportant.
See also 8cecb85e4bc4 which is partly reverted here. The intent there
was probably mostly about message (delivery) errors, which should be
considered important.
Only guard the actual pausing of outgoing data on the method existing.
This prevents the filters from lingering in case something happened to
the connection. Removing already removed filters should be a safe noop.
Kim Alvefur