No more than 10 simultaneous connections allowed. Code -50

[Saad]

Everything was working fine for more than a year. Nothing changed. All
of a sudden it has started to come up...

No new host, no mailchimp version upgrade etc.

Mailchimp API version is 1.2.


I call the API (integrated with my codeigniter site) as,

---
foo() {
require_once(BASEPATH.'libraries/mailchimp/MCAPI.class'.EXT);
require_once(BASEPATH.'libraries/mailchimp/config.inc'.EXT);

$api = new MCAPI($apikey);
$retval = $api->campaigns();

if ($api->errorCode){
echo "Unable to Pull list of Campaign!";
echo "<br>\tCode=".$api->errorCode;
echo "<br>\tMsg=".$api->errorMessage."<br>";
} else {
//OK
}
----

and it returns errorCode -50 with message "No more than 10
simultaneous connections allowed."


I am not so happy ATM.

[klinde]

I have the same situation (nothing changed) with same results (No more
than 10 simultaneous connections allowed.), seemed to start last
Friday morning (10/21/2011). If I wait for awhile, the connections
will time out and then I can resume (without making any changes to the
code). I have been looking into how to close the connections or use a
cached connection, but no luck. I would like to just use an existing
connection for all calls and then close it when I'm done, but the PHP
wrapper doesn't seem to show how to do this. Here is my API call log:

Last 24 hours of API calls
Date/Time  Result  Throttled?  Source IP  Method  Format  Exec Time
User Agent  Ver
10/26/2011 04:42pm nope 174.143.11.196 listSubscribe php 0.467s MCAPI/
1.2 1.2
10/26/2011 04:04pm nope 174.143.11.196 listSubscribe php 0.432s MCAPI/
1.2 1.2
10/26/2011 03:54pm nope 174.143.11.196 campaignSendNow php 0.043s
MCAPI/1.2 1.2
10/26/2011 03:54pm nope 174.143.11.196 campaignSendNow php 1.074s
MCAPI/1.2 1.2
10/26/2011 03:53pm nope 174.143.11.196 campaignCreate php 0.796s MCAPI/
1.2 1.2
10/26/2011 03:53pm nope 174.143.11.196 campaignCreate php 0.403s MCAPI/
1.2 1.2
10/26/2011 02:30pm nope 174.143.11.196 listSubscribe php 0.266s MCAPI/
1.2 1.2
10/26/2011 02:25pm nope 174.143.11.196 listSubscribe php 7.118s MCAPI/
1.2 1.2
10/26/2011 02:12pm nope 174.143.11.196 listSubscribe php 0.198s MCAPI/
1.2 1.2
10/26/2011 01:58pm nope 174.143.11.196 listSubscribe php 0.227s MCAPI/
1.2 1.2
10/26/2011 01:58pm nope 174.143.11.196 listUpdateMember php 0.066s
MCAPI/1.2 1.2
10/26/2011 01:55pm nope 174.143.11.196 listSubscribe php 0.512s MCAPI/
1.2 1.2

[klinde]

More information...
I can run this:
require_once './inc/MCAPI.class.php'; //need when in funcitons.php
require_once './inc/config.inc.php'; //contains apikey //need when
in funcitons.php
$api = new MCAPI($apikey);
$retval = $api->campaignStats('xxxxxxxxxx');

if ($api->errorCode){
echo "Unable to Load Campaign Stats!";
echo "\n\tCode=".$api->errorCode;
echo "\n\tMsg=".$api->errorMessage."\n";
} else {
echo "Stats for campaign<br>";
foreach($retval as $k=>$v){
echo "&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;".$k." => ".$v."<br>";
}
}
echo "<br><br>";

...without error, while at the same time I get the error runing this:

require_once 'inc/MCAPI.class.php';
require_once 'inc/config.inc.php'; //contains apikey

$api = new MCAPI($apikey);

$listId = 'xxxxxxxxxx'; //letter list on MailChimp
$my_email = 'xx...@xxx.xxx';

/**
Note that if you are not passing merge_vars, you will still need to
pass a "blank" array. That should be either:
$merge_vars = array('');
- or -
$merge_vars = '';

Specifically, this will fail:
$merge_vars = array();

Or pass the proper data as below...
*/
$merge_vars = array('FNAME'=>'xxx', 'LNAME'=>'xxx',
'INTERESTS'=>'');
// By default this sends a confirmation email - you will not see new
members
// until the link contained in it is clicked!
$retval = $api->listSubscribe( $listId, $my_email, $merge_vars );

if ($api->errorCode){
echo "Unable to load listSubscribe()!\n";
echo "\tCode=".$api->errorCode."\n";
echo "\tMsg=".$api->errorMessage."\n";
} else {
echo "Returned: ".$retval."\n";

[klinde]

Now they both return the error. :(

On Oct 26, 2:07 pm, klinde <ken.linde....@gmail.com> wrote:
> More information...
> I can run this:
>         require_once './inc/MCAPI.class.php'; //need when in funcitons.php
>         require_once './inc/config.inc.php'; //contains apikey  //need when
> in funcitons.php
>         $api = new MCAPI($apikey);
>         $retval = $api->campaignStats('xxxxxxxxxx');
>
> if ($api->errorCode){
>         echo "Unable to Load Campaign Stats!";
>         echo "\n\tCode=".$api->errorCode;
>         echo "\n\tMsg=".$api->errorMessage."\n";} else {
>
>     echo "Stats for campaign<br>";
>     foreach($retval as $k=>$v){
>         echo "&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;".$k." => ".$v."<br>";
>     }}
>
>                 echo "<br><br>";
>
> ...without error, while at the same time I get the error runing this:
>
> require_once 'inc/MCAPI.class.php';
> require_once 'inc/config.inc.php'; //contains apikey
>
> $api = new MCAPI($apikey);
>
> $listId = 'xxxxxxxxxx'; //letter list on MailChimp

> $my_email = 'x...@xxx.xxx';

[klinde]

It has now been 90 minutes and the connection are starting to clear,
so I can get back in again. It appears that I cannot make more than
10 connections (independent API calls... $api = new MCAPI($apikey); )
in a given 90 minute window. If I do them all in one connection (
$api = new MCAPI($apikey);), I can do as many as I want.

It appears that the connections are not being closed. How to I get
around this?

[jesse]

This restriction has been in place for quite a long time:

http://apidocs.mailchimp.com/api/faq/#faq6

You should look at all of the calls your code is making and figure out
which to elminate - we did recently update the docs to help you
determine what shouldn't be happening:

http://apidocs.mailchimp.com/api/faq/#faq5


jesse

[klinde]

Jesse,

I appreciate your response. Since your policy has been in place for a
long time and our code hasn't change for more than 18 months, I guess
we have just grown enough, that more than 10 users have wanted to make
changes to their mailchimp subscriptions in 90 minutes.

How would you recommend we best handle this situation with our API
code...

Over the course of an hour we have 20 user, who want to do one of the
following:
- subscribe to one of our four lists
- unssubscribe to one of our list
- update their email address
- Change for the Daily to the Weekly newsletter list

These users are all coming from different sessions at different times,
within that same hour.

Currently, instantiate a separate MCAPI object and call the
appropriate method for each user's request. So when we hit number 10,
we can no longer use MailChimp's API.

Best regards,
Ken

[jesse]

I don't think you read what I linked correctly. As the returned error
says, the limit is 10 simultaneous connections - what you've listed
won't touch that. There's also no time frame to consider unless you
have long running calls.

You may have grown or be on shared hosting with others who have bad
code running.

Like I said, you should evaluate the calls that are being made and
refer to the second link I provided. This is there, too, but in a lot
of cases people are making tons of unnecessary calls during each page
load either inadvertently or because they aren't bothering to cache
values that don't change. You may also want to check to your API
dashboard if you can't put proper logging in place to see what you are
actually doing:

http://apidocs.mailchimp.com/api/faq/#faq3


jesse

[klinde]

Ok, thanks. I understand and agree with you. Can you tell me how
many simultaneous connections we have made to the API from
174.143.11.196?

[jesse]

No, but I can see you are sharing that IP with roughly 120 other
users. Some have some spammy code running, but it appears the people
probably causing problems are hitting us a lot with invalid API keys.


jesse

[jesse]

Also, so you know, we're working out some ways to help out you guys on
massively shared hosts and at least keep the totally invalid keys from
impacting them.


jesse

[David Albrecht]

Going to throw my hat into the ring on this one...

I don't see why there's an IP-based connection limit at all. I get that it's simple to enforce at the firewall, but the entire point of the API is to allow third-party systems to act on behalf of users. The way I see it, it should't matter one iota whether 100 requests belonging to a single account come from 100 separate machines, or one -- the point is that a user of your (MailChimp's) services is using your compute resources, and should be charged/billed accordingly.

I'm being slightly greedy here. MailChimp customers use our product to manage their MailChimp lists, and I'm in the process of moving our stack to node.js, which could allow hundreds of concurrent connections to MC from a single IP address. I just don't see how its fair to penalize us for making 100 concurrent requests on behalf of 100 users, vs. one customer opening 10 requests from his own machine.

DA

--
You received this message because you are subscribed to the Google Groups "MailChimp API Discuss" group.
To post to this group, send email to mailchimp-...@googlegroups.com.
To unsubscribe from this group, send email to mailchimp-api-di...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/mailchimp-api-discuss?hl=en.

[klinde]

Can we have a limit of concurrent based on API Key?

[jesse]

Not API key based - these are now being counted/enforced per user per
IP rather than just per IP which appears to be working out much better
for shared host setups.


jesse

[klinde]

Please pass on our appreciation of the change. We have been operating
without issue.
Best regards!

> > > > > > > > > > > > 10/26/2011...
>
> read more »

[Alister Cameron]

Sorry, Jesse.

There's more going on here than you're seeing.

Please get some techs to look over it.

I have been using STS without a hitch for months.

Now, in the last few days, I'm suddenly hitting that limit.

This is the response packet:

    [aws_type] => 

    [aws_code] => 

    [http_code] => 500

    [message] => No more than 10 simultaneous connections allowed.

I can tell you PRECISELY that I'm sending out a paltry 13 emails per minute! Not a single email more.

Secondly, I can assure you that, the the best of my knowledge, this is the only client on that IP using Mailchimp (it's a private IP on my VPS which only few clients use).

There is just NO WAY I'm anywhere near 10 simultaneous connections, unless WordPress' WP_HTTP object is suddenly and mysteriously keeping connections open for many minutes at a time, each. As if.

PLEASE have a closer look at this, as it has rendered my use of STS... well, useless!

I have submitted a support ticket for this as well.

(The client account is "muehlenberg", if that helps.)

Alister

[Alister Cameron]

Jesse,

To add to my last comment...

It doesn't help that at this URL: https://us2.admin.mailchimp.com/account/api/

There is NO recording of API calls at all. Nothing.

So I have no way to know what you're seeing at your end.

Surely there's something wrong that STS API calls are not recorded by Mailchimp for me to see??

Alister

[jesse]

I just ran some tests and the connection limiting is working as
expected. From what I can see for today you've successfully run
SendEmail 250 times and have hit the connection limit 300 times, so
I'd suggest double checking what's actually going on on your end.



jesse

[jesse]

Actually, sorry, I misspoke - that number was off of one app server:
you've actually hit the connection limit a little over 2000 times so
far today.


jesse

[Alister Cameron]

Jesse,

I hit reply here and posted but I can't see it now so I'm trying again.

In short, there is no way your reporting is correct. Beats me how it possibly could be.

I have imposed a ceiling at my end of 13 emails per minute, tops. My reports assure me of that.

They're sent in batches of 13 every minute, but often less.

I'm doing this within WordPress, and as far as I know, the WP_HTTP object that wraps cURL is not using a "multi" connection, meaning that I think the connections are no simultaneous. Even if they were, it would be surprising if they were (literally) hitting you 10 at a time.

But again, you're not explaining or acknowledging that this has NEVER happened before now (the last few days). Others here have said the same thing!! We were cruising along fine and then suddenly you're blocking us for something we're all sure we're not doing.

If this doesn't get fixed I will have to drop STS and deal directly with Amazon SES and that would be really disappointing.

Given that I know what my system is doing, and have explained it as best I can, would you now please go back and see if it's possible that your reports are wrong?!

Alister

[B]

I second this that something must be going on - all of a sudden on
Friday we started seeing this when we have not changed code and are
for sure not doing 10 per second.

Experiencing something simular to them. Been unable to get support
on it as well - and rendered our transactional almost useless. Let
us know asap what we need to be doing differently - because we come no
where close to 10. thanks in advance.

[B]

We have ran 5-10 workers fine ---we sent 50-100k emails a day - if we
put anywhere 2,3,4 workers - which is way less than 10 sim connections
- it spits out that error always -

[B]

we use your standard
MCAPI.class.php

to send as well just fyi...

thanks.

[jesse]

Ok, I tracked down what's going on: we've always had the connection
limits posted and enforced for the standard API - the problem here is
that they were never enforced for the SES API, so when we swapped
around the tracking mechanisms we started enforcing them.

Because they were never being enforced - and only because of that -
we're going to remove them for SES for the time being.

The numbers I posted simply aren't wrong, so you should really get a
better handle on your code since I definitely anticipate some form of
them being enforced again in the future. It easily may not be actual
SendEmail calls that are being made.


jesse

[jesse]

Are you using SES *and* the standard API? I ask b/c what you're saying
doesn't really mesh with what's been happening and the MCAPI php class
has nothing to do with SES. You probably need to give me your IP(s),
username, or the u parameter from your hosted signup forms as that
sounds more like you have a bunch of rogue code running that you
aren't aware of.


jesse

[Reuben]

For those of you with this error who are using drupal:

The drupal mailchimp module provides subscribe blocks, which call 2
mailchimp api functions each time they are loaded.
Drupal has a block caching system (which is what the subscribe blocks
rely on so that they aren't calling mailchimp twice on every page
load) but there is an issue with drupal core where you can't use block
caching if you are using additional node access modules.
So in that case the blocks aren't cached and you run the risk of
running into the 10 simultaneous connections limitation.

I will see if I can work out a fix with the mailchimp module
maintainer.

On Nov 2, 1:20 am, jesse <je...@mailchimp.com> wrote:
> Are you using SES *and* the standard API? I ask b/c what you're saying
> doesn't really mesh with what's been happening and the MCAPI php class
> has nothing to do with SES. You probably need to give me your IP(s),
> username, or the u parameter from your hosted signup forms as that
> sounds more like you have a bunch of rogue code running that you
> aren't aware of.
>
> jesse
>
> On Oct 31, 8:41 pm, B <brandon...@gmail.com> wrote:
>
>
>
>
>
>
>
> > we use your standard
> > MCAPI.class.php
>
> > to send as well just fyi...
>
> > thanks.
>
> > On Oct 31, 5:30 pm, B <brandon...@gmail.com> wrote:
>

> > > We have ran 5-10workers fine ---we sent 50-100k emails a day - if we
> > > put anywhere 2,3,4 workers - which is way less than10sim connections

> > > - it spits out that error always -
>
> > > On Oct 31, 4:25 pm, B <brandon...@gmail.com> wrote:
>
> > > > I second this that something must be going on - all of a sudden on
> > > > Friday we started seeing this when we have not changed code and are

> > > > for sure not doing10per second.