Hi,

I've realized that since a particular day, my customized synchronisation scheduled Cron job has stopped to work properly. My cURL calling Subscribers.Get from the API gave me an error while getting the list.

As I tried manually directly through my browser, I had a "remote server not responding" error but the oempro was still running the requests within MySQL.
I've been trying the same API call on an external browser and it seems to load indefinitely...
(I've waited around an hour and a half to get the result but nothing was sent back. The MySQL process from my Oempro user took around 40 minutes).

BTW, here's my connection process:
  1. ../api.php?Command=Admin.Login&ResponseFormat=XML&Use rname=xxxxxxxxxx&Password=xxxxxxxxxx&DisableCaptch a=TRUE;
  2. ../api.php?Command=User.Switch&ResponseFormat=XML&Ses sionID=xxxxxxxxxxxxxxxxxxxx&UserID=1&PrivilegeType =Full;
  3. ../api.php?Command=Subscribers.Get&ResponseFormat=JSO N&OrderField=EmailAddress&OrderType=ASC&RecordsFro m=0&RecordsPerRequest=0&SubscriberListID=1&Subscri berSegment=Active&SessionID=xxxxxxxxxxxxxxxxxxxx.

Now the reason why it has increased? My thought would be because I've created additional users with their own custom fields (Because we cannot share Global Fields through different users).
Note that my oempro is not currently active in official production, so there should be no reasons to be because of any users or production activities. Also note that this problem has started progressively the days after I've been creating additional users.

So the Interesting facts:


[#1]

I've created a log in the script and here's a list of the delays for calling and getting the Subscribers.Get array with a specific number of users
(Date(yyyy-mm-dd) | TotalUsers | DelayTime(mm:ss)):

-1st List = 14,200 Membres (+ ~10/day)-
2011-12-27 | 3 | 09:21
...
2012-01-03 | 3 | 09:28
2012-01-04 | 4 | 12:28
2012-01-05 | 5 | 15:27
2012-01-06 | 5 | 15:30
2012-01-07 | 8 | HTTP/JSON -> Couldn't resolve JSON info (HTTP request could have failed)
2012-01-08 | 8 | HTTP/JSON -> Couldn't resolve JSON info (HTTP request could have failed)
...

-2nd List = 4,880 Members (+ ~2/day)-
2011-12-27 | 3 | 03:15
...
2012-01-03 | 3 | 03:16
2012-01-04 | 4 | 04:19
2012-01-05 | 5 | 05:14
2012-01-06 | 5 | 05:15
2012-01-07 | 8 | 08:39 (Still working)
2012-01-08 | 8 | 08:31 (Still working)
...


[#2]

By investigating at the MySQL process, I see several calls to different UserID than the one asked in my request (in this case, my UserID should be only 1). I also see RelFieldID in a different range than what this user/list should be in (in this case, my range should be between 1 and 16)
Here are some examples from what I see:
  • SELECT * FROM oempro_custom_field_values WHERE ( RelOwnerUserID = "8" AND RelListID = "0" AND EmailAddress = "xxxxxx@xxxxxx.xxxx" AND RelFieldID = "160" )
  • SELECT * FROM oempro_custom_field_values WHERE ( RelOwnerUserID = "7" AND RelListID = "0" AND EmailAddress = "yyyyyy@yyyyyyy.yyyy" AND RelFieldID = "156" )
  • SELECT * FROM oempro_custom_field_values WHERE ( RelOwnerUserID = "6" AND RelListID = "0" AND EmailAddress = "zzzzzz@zzzzzz.zzzz" AND RelFieldID = "132" )
I'm not sure to understand the logic in this situation to make those kind of calls if I'm actually logged as UserID=1 for the SubscriberListID=1 and the Global FieldID for this UserID/SubscriberListID is inclusively between 1 and 16...

Also, as an additional performance issue, if it's only the "ValueText" that is needed in Subscribers.Get, you may only ask for a SELECT ValueText FROM oempro_custom_field_values ... instead of SELECT * FROM oempro_custom_field_values ... to improve the speed of the request.


Let me know if you have any information about this or if this could be fixed in a near future release.

Thank you!