Subscription deactivations

[David Novakovic]

Hello again,

We are having a subscription cancelled even without noticeable
erroring from our end.

All the responses I can see form our end are empty 204's.. but still
the subscription is being deactivated.

What else can i do to ensure that it doesn't get deactivated? And what
are the exact thresholds for getting deactivated?

Cheers,

David

[ken ellis]

I've seen the same behavior, on a machine with relatively low load and
no noticeable issues on my end. Did you ever solve this one?

Ken

[Joel]

Ken,

If you have questions you want to ask me, can you send them to my corporate email address to which you've sent inquiries before? It will be easier for me to answer there.

FYI we're working to improve our system so it doesn't deactivate subscriptions so readily. This has been a recurring issue.


thanks,

Joel

--

Joel

[David P. Novakovic]

For everyone's info, and a bit of background... we found that our apache server was returning responses that seemed fairly reasonable, but the subscriptions was still being deactivated. The problem was that nginx was actually returning 499 responses to myspace. As it turns out this is probably because the endpoint handing the requests is taking too long.

So if anyone else is having this problem be sure to check your reverse proxy logs, not just your server handling the requests. :)

D

[ken ellis]

Thanks, great tip. It looks like something similar was happening
here. It was hitting Apache directly, which was probably unable to
keep up but not showing unhandled requests or errors in the logs. So
I replaced it with nginx and FastCGI, and it seems to be working.

On Feb 16, 4:30 pm, "David P. Novakovic" <davidnovako...@gmail.com>
wrote:

> For everyone's info, and a bit of background... we found that our apache
> server was returning responses that seemed fairly reasonable, but the
> subscriptions was still being deactivated. The problem was that nginx was
> actually returning 499 responses to myspace. As it turns out this is
> probably because the endpoint handing the requests is taking too long.
>
> So if anyone else is having this problem be sure to check your reverse proxy
> logs, not just your server handling the requests. :)
>
> D
>
>
>
> On Wed, Feb 17, 2010 at 4:25 AM, Joel <frokenst...@gmail.com> wrote:
> > Ken,
>
> > If you have questions you want to ask me, can you send them to my corporate
> > email address to which you've sent inquiries before? It will be easier for
> > me to answer there.
>
> > FYI we're working to improve our system so it doesn't deactivate
> > subscriptions so readily. This has been a recurring issue.
>
> > thanks,
>
> > Joel
>

[Lu Liu]

Ken and David,

Thanks for the tips. I am curious what are the batchSize and rate in
your subscription settings.
I have tried 10, 1000, and 10000 in batchSize. But all I got is 1
event per http request.
This generates a very large number of http requests, and probably
contributes to the deactivation.

[David P. Novakovic]

As far as I know Batched responses aren't implemented yet.

D