Closed (fixed)
Project:
Mailchimp
Version:
6.x-2.5
Component:
General
Priority:
Normal
Category:
Bug report
Assigned:
Unassigned
Reporter:
Created:
16 Jul 2011 at 11:03 UTC
Updated:
22 Sep 2011 at 21:17 UTC
Jump to comment: Most recent file
Comments
Comment #1
ethnovode commentedDear 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 ;-)
Comment #2
mattcasey commentedsubscribing. Perhaps the module can try re-sending a submission until it is able to go through?
Comment #3
bardill commented> 6.x-2.x: Stable, large install base, mature feature set.
I don't understand :)
b
Comment #4
the_g_bomb commentedAre 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.
Comment #5
bardill commentedYes, 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
Comment #6
chien_fu commentedit 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?
Comment #7
bardill commentedYes. As entendu: the module should queue up its requests and not monopolize sockets
Comment #8
skolesnyk commentedSo what should we do? Upgrade to 7.2-x?
Comment #9
christophedg commentedI have the same issue in 7.4-x ...
Comment #10
bardill commentedHi levelos, what is your opinion about this: http://drupal.org/node/938480?
Many thanks for your work.
b
Comment #11
bardill commentedAbout 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
Comment #12
chien_fu commentedI've resorted to creating the form in Mailchimp, and creating an HTML block in drupal to embed the subscription form.
Comment #13
the_g_bomb commentedHow 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.
Comment #14
levelos commentedSorry 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.
Comment #15
bardill commentedHi 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!
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
Comment #16
rickmanelius commentedIt'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.
Comment #17
technikh commented+1 subscribing..
Comment #18
nivelula commentedI 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.
Comment #19
bleedev commentedCommitted 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.