I am running mailchimp 7.x-4.7 with the latest libraries installed. I have had the module up and running fine for some time, (until about two days ago) with a successful api key installation that was pulling down lists nicely.

Here's the issue:
During some routine maintenance on my clients live site, mailchimp no longer displays the created lists that it has been seeing for over 4 months now. I've done much research on this issue with none of the proposed solutions seeming to apply to my situation. When I attempt to refresh the mailchimp lists I get the following mailchimp error message in my logs:

An error occurred requesting list information from MailChimp. "503: akamai_503 - "

Which causes the following php error:

Notice: Undefined property: stdClass::$detail in Mailchimp\MailchimpAPIException->__construct() (line 21 of /home/hertim6/public_html/sites/all/libraries/mailchimp/src/MailchimpAPIException.php).

I read that as the mailchimp server is not responding with a reply (hence the 503) which is causing the php error to be thrown as seen in the screenshot attachment below. This is what I see on the clients live site.

I also have an exact duplicate of the client site subdomained on my test server. (Our test server was recently migrated to https around the same time this error began. While the client server is http).

When I test the module on my test server (https), everything works fine. Lists are pulled down from the mailchimp server as designed. However, when I try to call from the client server (http), it seems mailchimp is not responding to the call? You can see this behaviour in the attachment, server_call.png The 156.x.x.x IP is the clients IP, while the 209.x.x.x IP is my test server. The 156.x.x.x call you see was when I uninstalled and reinstalled the mailchimp module as if setting it up from new. That is the only call I have gotten from mailchimp on the clients website. Every time I refresh lists I get the same error as in the screenshot.

The only difference between the two accounts that I can see, is that one resides on a test server (https) while the other is http?

Anyone have a guess on what's going one here?

CommentFileSizeAuthor
#4 broken-server.png113.43 KBCooper188
#4 working-server.png118.21 KBCooper188
server_call.png121.23 KBCooper188
Screen Shot 2016-11-21 at 08.39.56.png79.71 KBCooper188
Support from Acquia helps fund testing for Drupal Acquia logo

Comments

Cooper188 created an issue. See original summary.

MaskOta’s picture

MaskOta CreditAttribution: MaskOta commented

We have run into this issue today aswell.

It seems that this is not related to the module but your IP being blacklisted by the akamai firewall.

Other people have this issue (sorry about the wordpress link :) )
https://wordpress.org/support/topic/503-service-unavailable-22/

Cooper188’s picture

Cooper188 CreditAttribution: Cooper188 commented

Thanks for the reply.

Wow that's a bummer. I have requested a dedicated IP from my provider. We'll see how it works out.

Cooper188’s picture

Cooper188 CreditAttribution: Cooper188 commented
FileSize
working-server.png118.21 KB
broken-server.png113.43 KB

So..... I was indeed on a server that had a shared IP address that I was on. I have since been issued a dedicated IP address which is significantly different from the shared address.

However, the issue persists.

I have cleared all the caches through drush, and the mailchimp plugin refresh (on the list tab) as well.

I have issued the command that was given in the article from two different servers, and received two different reply's. As can be seen in the working-server.png, the call to mailchimp is made and accepted, a 200 reply is returned, then all the customer information is listed out, (which is not displayed in the image). The broken-server.png shows a very similar start, but the return is 503 Service Unavailable. No customer information was returned.

It seems I'm back where I started. :(

MaskOta’s picture

MaskOta CreditAttribution: MaskOta commented
Status: Active » Closed (won't fix)

On our end this problem has resolved on its own meaning it wasnt a module problem.

I think we can safely close this issue