The FEs keep a circular buffer of the last 150,000 tweets. The count
parameter controls how much of that buffer is examined to create the
historical dump before transitioning to live streaming. If the current tps
rate is, say, 600, then the buffer holds the last 250 seconds worth of
tweets. With a
First of all John, that may be the best Saturday night reply ever :-).
We are trying to use the count parameter with the follow predicate on
an account with shadow access role and have been getting some curious
responses when testing.
Here is a brief description of the testing scenarios:
* follow
Each developer will come to understand Fullness in a unique inner-directed
manner. One might decide that exhausting the predicate list constitutes
adequate Fullness. Another might decide that data loss becomes unacceptable
at another point, perhaps due to the rapid cycling. A third might develop
an
Okay, great.
When we say a default access account or elevated access is "TOO FULL". Does
that mean, we have started getting rate limit messages in stream? Or it is
something else?
Thanks,
Alam Sher
On Sat, Feb 27, 2010 at 2:31 AM, John Kalucki wrote:
> The elevated access account can reconnec
The elevated access account can reconnect much less frequently by adding new
predicates to a default access stream that cycles based on demand. When the
default access account cycles, very little data will be lost, as it receives
a small fraction of your total feed. Once the default access account
Sorry, but exactly this portion of the documentations goes above my head.
Can you please explain a bit more to me how a default access account can be
used along with the elevated access account to minimize the data loss?
Thanks,
Alam Sher
On Thu, Feb 25, 2010 at 7:15 PM, John Kalucki wrote:
>
Yes, this is indeed what you should be doing. If you have a low tolerance
for data loss, you will then use a total of four accounts: 2 elevated and 2
default access accounts. If you can tolerate a few missing tweets on each
reconnect, you can just use the two elevated accounts.
-John Kalucki
http:
So in case, if I have 20K users and I have to, say track 60K keywords
for them + also have to follow all of them. I should be applying for 2
higher access accounts one for track predicates and other for follow
predicate. Does this make sense?
Thanks,
On Feb 25, 8:44 am, John Kalucki wrote:
> Thi
So in case, if I have 20K users and I have to, say track 60K keywords for
them + also have to follow all of them. I should be applying for 2 higher
access accounts one for track predicates and other for follow predicate.
Does this make sense?
Thanks,
Alam Sher
On Thu, Feb 25, 2010 at 8:44 AM, Joh
This technique works for updating any filter predicate. The count parameter
should work on a shadow account. It won't work on a default access account.
We have a number of very large integrations using this technique with
Birddog access -- it should scale down to Shadow access just fine.
The docum
On Feb 24, 2:06 pm, John Kalucki wrote:
> The documentation should be pretty clear on this topic. One main connection,
> and perhaps an auxiliary connection to manage query velocity.
Hey John,
Do you recommend this kind of 2 connection setup for updating our user
list when using the follow predi
11 matches
Mail list logo