HTTP_Request2_SocketWrapper would never time out on an fgets() call as
discussed in issue #281https://git.gnu.io/gnu/gnu-social/issues/281
I'm patching it here by setting the socket to non-blocking mode and
using stream_select to wait until the timeout. This patch or some
similar variant must be implemented in HTTP_Request2_SocketWrapper
to avoid the same issue for other users.
I noticed that each time a notice was accessed it'd do a remote lookup
with HEAD (and continue despite 404 etc.) and then another attempt to
download the resource. If this wasn't successful new attempts would be
made for each loading of the resource, which is extremely resource
intensive.
Whenever we can say "it's been n seconds since the last attempt" we
could probably enable this again - or just manually reload remote
thumbnails (as part of the StoreRemoteMedia plugin etc.)
No requests we do externally should ever take more than 60 seconds. This
could probably be changed for downloading video or whatever for any cache
plugins that want to store data locally, but in general I think even 60s
is way longer than I expect any outgoing requests should take.
This affects everything using HTTPClient, our helper class, and thus all
hub pings, subscription requests, etc. etc.
The value, afaik, includes connect_timeout and if it takes 10 seconds to
establish a connection only 50 seconds is available to transfer data.
use Notice_prefs instead of adding a new field. The rationale here
is simply that the Notice table was _huge_ and I rant into issues
with /tmp filling up when altering the tables. So let's just create
a new table instead.
use Notice_prefs instead of adding a new field. The rationale here
is simply that the Notice table was _huge_ and I rant into issues
with /tmp filling up when altering the tables. So let's just create
a new table instead.
Conversation will now start storing remote URL
The namespace features don't work the way they were written for here
so I fixed that, making the ostatus: namespace properly looked up and
then the homegrown getLink function looks for what is back-compat with
StatusNet etc. if I remember correctly.
