Hi and many thanks for this great module.
I have a problem, sometimes i have this problem (see the attachment).
How to solve this?

(I have to set -write errors only to the log- and no screen).
many thanks.
b

Comments

ethnovode’s picture

Dear Mailchimp developer,

I love your module and have the same problem with 7.x-1.0 from time to time :

Warning: fsockopen(): unable to connect to us2.api.mailchimp.com:80 (Connection timed out) in MCAPI->callServer() (line 1606 of /var/www/bi-strategia.com/html/sites/all/modules/mailchimp/MCAPI.class.php).
Warning: fsockopen(): unable to connect to us2.api.mailchimp.com:80 (Connection timed out) in MCAPI->callServer() (line 1606 of /var/www/bi-strategia.com/html/sites/all/modules/mailchimp/MCAPI.class.php)

Maybe I should try 2.0rc2 ;-)

mattcasey’s picture

subscribing. Perhaps the module can try re-sending a submission until it is able to go through?

bardill’s picture

> 6.x-2.x: Stable, large install base, mature feature set.
I don't understand :)

b

the_g_bomb’s picture

Are these related?
http://drupal.org/node/996870
http://drupal.org/node/938480

I'm having the same issue and during my search for for this error, I noticed actual websites that are using this module showing up in the google search, meaning Google is crawling sites and seeing this error.

An interim work around might be to at least hide the error message from non admin roles, I could live with the message if Mailchimp is down, however I don't want the site users seeing the message.

bardill’s picture

Yes, i know this. I think the problem is Mailchimp server.
Anyway the problem is that this error make very slow drupal.
How do fix this? See: http://drupal.org/node/938480

An interim work around might be to at least hide the error message from non admin roles

How to do this? I only disable error on screen (only in log).
Thanks.

b

chien_fu’s picture

it seems that regardless of whether the message is shown or not it makes the page the form is on take forever to load. Anyone else experience this?

bardill’s picture

Yes. As entendu: the module should queue up its requests and not monopolize sockets

skolesnyk’s picture

So what should we do? Upgrade to 7.2-x?

christophedg’s picture

I have the same issue in 7.4-x ...

bardill’s picture

Hi levelos, what is your opinion about this: http://drupal.org/node/938480?

Many thanks for your work.
b

bardill’s picture

StatusFileSize
new49.9 KB

About this: http://drupal.org/node/996870#comment-4396466
What is the best solution to reduce the our common error --- unable to connect to us2.api.mailchimp.com:80 --- ?
1) The sync with cron is always recommended?
2) Having a small newsletter form on -home page- is a bad idea, right? It's better to have less exposed newsletter form?

(I have not found documentation and so I ask here)
Many thanks
b

chien_fu’s picture

Component: Code » General

I've resorted to creating the form in Mailchimp, and creating an HTML block in drupal to embed the subscription form.

the_g_bomb’s picture

How about adding a variable to the user array which contains the user subscription status, this could be updated at form submission and on cron runs.

The variable can then be tested against rather than having to connect to the MC API on form render. My issue is that my client wants the sign up form the appear on most pages to promote sign up, thus for signed in users the form is rendered often, meaning many connections are attempted, increasing the likelihood that a connect may be dropped.

levelos’s picture

Sorry for the radio silence, we've been focusing on the new 7x-2.x branch, which solves this issue by caching all MailChimp list and member info locally, and now has a 2.0 release. The new version is a complete rewrite with an entirely different architecture, so a backport is not really in the cards. More info on the new version can be found here, http://thinkshout.com/blog/2011/06/lev/mailchimp-20-anatomy-drupal-modul....

The 6.x-2.x code base would have to be rewritten to allow for async communication with the MC API outside of required lists / cron, which is already in place. I'm not saying it won't happen, but it's certainly not imminent. Drupal 7 users should definitely upgrade to 7.x-2.x. For 6.x users, there are some possible interim ideas.
* The timeout on the API object is currently set to 60 seconds. That can be massaged up or down to optimize results.
* The error message is coming from PHP / Apache, not the module. It's only setting a watchdog message when there's a timeout or other API issue.
* We could wrap the API connection in a try/catch.
* If using required lists, make sure to sync them asynchronously during cron.

I'll leave this open and we'll make it a priority when rolling a 6.x maintenance release.

bardill’s picture

StatusFileSize
new34.07 KB

Hi levelos and thanks to stop radio silence! Please, leave this post open to understand better how this module work.
Yes, we use 6.25 and we have some questions:

1- how set the best timeout on the API to optimize result on a drupal with (on average) 2 anonymous subscribers in a week? 5/10 sec is better? The mailchimp form block is always visible in home page - is this a problem for loop connection for the api? NB: we use this module only for anonymous user role!

// set the timeout to something reasonsable to avoid taking down the Drupal site
  $q->setTimeout(60);

2- why Opt-in (not Double Opt-in) not send mail confirmation to subscriber (and also to admin in mailchimp)? How to solve this?
3- >we could wrap the API connection in a try/catch -- please can you elaborate better?
4- >If using required lists, make sure to sync them asynchronously during cron. -- in 6.25 there is not required lists!

many thanks
b

rickmanelius’s picture

It's basically an issue when you're offline or unable to connect to their servers.

I've experienced the same. It might be better to have it fail gracefully and show an 'unable to connect to email servers' message.

technikh’s picture

+1 subscribing..

nivelula’s picture

I am having the same issue on 7.x-2.1, so I really don't think this is solved in the new versions. I agree with rickmanelius on this one. The form should fail gracefully and show an unable to connect message.

bleedev’s picture

Status: Active » Closed (fixed)

Committed a change (8680546) to handle the error better. In the event that this error occurs, the PHP error will be suppressed, a Drupal warning will be shown to the user and a watchdog error message will be written. More substantial architectural changes to make the module less dependent on the API are happening in 7.x-2.x.