We have added a call to acquia_agent_check_subscription() in our installation profile. This ensures a ready to run site after a successful site install.

Unfortunately the site installation process has become quite slow on our development environments and the result is that acquia_agent_check_subscription() fails with a "Message too old" error.

Acquia_agent.module uses REQUEST_TIME as timestamp in the subscription checking and since REQUEST_TIME is set early in a request this can diverge too much from the actual time the subscription checking is done during site install (or other slow process, i.e. very slow cron jobs or in test cases).

Attached is a patch that generates a timestamp based on the current time the first time subscription checking is done and uses that timestamp instead of REQUEST_TIME.

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

arnested’s picture

Status: Active » Needs review
FileSize
1.81 KB
coltrane’s picture

Good point. Using REQUEST_TIME has been an issue with Acquia Search and since D6 Connector is fine with time() let's switch to it. However, I don't see the need for a new function, can you elaborate on why you added it?

Here's a patch with just time().

Note: Due to the priority of https://drupal.org/node/2077981 I'm planning a new release of the Connector soon. Apologies for the short notice but if you feel strongly about this new function and static var please let me know ASAP or else I'll probably be applying this time() patch.

coltrane’s picture

Title: Acquia Agent: Message is too old » Message is too old errors during insallation and simpletests
coltrane’s picture

Title: Message is too old errors during insallation and simpletests » Message is too old errors during installation and simpletests

  • Commit ad44520 on 7.x-2.x by coltrane:
    Issue #2217015 by coltrane: Message is too old errors during...
coltrane’s picture

Status: Needs review » Fixed
arnested’s picture

However, I don't see the need for a new function, can you elaborate on why you added it?

I was not 100% sure whether the timestamp needed to be the same throughout a request (REQUEST_TIME is) so just to be sure I added a layer of indirection where I could store it an a static variable.

Status: Fixed » Closed (fixed)

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

magtak’s picture

The same bug exists in the 8.x-1.x branch.

Submitting patch that addressed it in the same way.