NOTE: This may be related to #980322: Problem (incompatibility?) with XMLSitemap module

Symptom: Download, install only the shorten main module and enable it. The logs are completely filled up with shorten "notice" messages "CURL failed to return an abbreviated URL from .", whether pages were accessed by logged-in user or more annoyingly by crawlers (hundreds of errors per minute).

Clues: The errors occur only on pages where service-links (share on FB, Twitter etc buttons) are enabled. Unchecking all the options (tokens, aliases etc) in the module admin interface does not change this.

Current workaround: Change the "Short Links" setting in service_links module to "Never". The default setting "Only when requested" seems to be the cause of the shorten errors upon page access.

[It is not clear to me which module is causing the problem, please transfer issue if needed]

Comments

ajzz’s picture

ajzz commented
Title: Error notices with service_links module? » CURL failed to return an abbreviated URL from .

This gets more intriguing. The error is back even with service_links module disabled (changed title to reflect that). It occurs when either of these two options are checked:

Generate a shortened URL for nodes for use as tokens
OR
Shorten aliased URLs where possible

In other words, the error can be avoided only when the above two options are unchecked and other modules such as service_links are instructed not to shorten links.

icecreamyou’s picture

icecreamyou commented
Status: Active » Postponed (maintainer needs more info)

What URL shortening service are you using?

Chad_Dupuis’s picture

Chad_Dupuis commented

Don't know if this is helpful in any way but I don't remember seeing this error before until I upgraded to the latest dev of varnish... Are you by chance running that as well? Now I get thousands of these errors in watchdog but haven't yet had a chance to see if it's a problem. The actual service links appear to work fine. I'm using is.gd if that's helpful and have twitter and facebook enabled for service links....

ajzz’s picture

ajzz commented

Good call IceCreamYou, the default was set to a custom shortener for our organization. If I switch the default and back to tinyurl and a valid bitly account , these errors disappear even with other the other module enabled. I'll try to see if the service was down temporarily and close the issue if that was the case.

ajzz’s picture

ajzz commented

@icecreamyou: i think the problem is related to the maximum number of queries one can make to our organization's shortening service. There are limits per minute, hour and day. When the cache is cleared by admin, any page access causes a few of these errors because the service is getting called multiple times per page access. This trips the "minute limit". This may explain why many CURL errors pop up when a search engine is indexing a site (with previous content) after the module is first installed.

Is it worth making a feature request for throttling the queries and building a preemptive cache? I'm still not clear why so many errors are created per page - I've noticed the page load-times suffer quite a bit due to that.

icecreamyou’s picture

icecreamyou commented

Is it worth making a feature request for throttling the queries and building a preemptive cache?

No. Shortened URLs are already cached. It's your admins' fault if they clear that cache.

I've noticed the page load-times suffer quite a bit due to that.

Each request for a shortened URL times out after 3 seconds, and the module will attempt twice to fetch a shortened URL (once with the primary service, and if that fails, then with the backup service). So if both of your services are timing out, that adds at least 6 seconds to the page load time per shortened URL request. (When the shortened URL is cached, the time to fetch it is negligible.)

Just another reason why you should cache shortened URLs.

icecreamyou’s picture

icecreamyou commented
Category: bug » support
Status: Postponed (maintainer needs more info) » Fixed
ajzz’s picture

ajzz commented

thanks for the feedback. just one more question: what is the expected behavior if I change to the custom shortener after all the links are already cached by some other service? will all the links expire in 3 weeks (or whatever is set) and the problem recur when cron runs? or are new links made upon page access (which might be slightly more staggered)? cheers!

icecreamyou’s picture

icecreamyou commented

what is the expected behavior if I change to the custom shortener after all the links are already cached by some other service?

The cached version of a link is returned until the cache expires. Note, however, that links are added to the cache when they are generated, so they don't all expire at exactly the same time.

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.