stream_position badly lagging?

新規投稿

コメント

3件のコメント

  • Murtza

     This is the expected behavior of the events endpoint. These are great observations, so I'll do my best to clarify the role of stream_position.

     

    You can think of stream_position as a cursor in our events database. It does not represent the number of events in your Box instance, but rather serves as a pointer to a specific event within a list of all your events ordered by date. 

     

    Another important thing to note is the value of stream_position returned in subsequent API calls will increase but not necessarily be consecutive. This is why you saw the the large increases in stream_position values between calls.

    0
    コメントアクション パーマリンク
  • nhill40

    Hey ,

     

    Thanks for the response, but I don't think you are quite following my question/concern.  We've heavily leveraged the "stream_position" concept in the code we've written against the Box API and it's worked great for us, so I understand the concept very well.

     

    To make my question more specifc:  if I were to do these two GETs at the exact same instant -

     

    https://api.box.com/2.0/events

    https://api.box.com/2.0/events?stream_position=now

     

    Given that those 2 GETs were made at the exact same instant in time, would you expect that the "next_stream_position" returned in the respective responses would be the same?

     

    Based on my understanding of the "next_stream_position" (as well as my experience working with the Box event API), I would expect these 2 numbers to be the same.  But instead what I'm seeing is the "next_stream_position" being returned by the "https://api.box.com/2.0/events" is falling further and further behind the "next_stream_position" being returned by the "https://api.box.com/2.0/events?stream_position=now" call (it was off by around ~3,100,000,000 when I first posted yesterday; this morning it's off by around 3,705,028,883)

     

    In fact, the "next_stream_position" being returned by the GET to "https://api.box.com/2.0/events" is not moving forward at all.  I can make that same GET repeatedly over a period of time and it never moves forward.

     

     

    0
    コメントアクション パーマリンク
  • nhill40

    Hmm, perhaps I don't understand this as well as I claim to!  🙂

     

    I was reading some of the fine print in the API docs and it seems to defy my (apparently faulty) understanding of how the next_stream_position works - specifically (bolding my own for emphasis):

     

    If you send stream_position=now then Box returns an empty list and the parameter stream_position with the latest stream position as its value. Using stream_position=now works only when the stream_type is not admin_logs.

     

    If you send no stream_position parameter then Box send all available events, beginning with the oldest stream position.

     

    Very interesting - I think I would amend my question to be "how does Box determine 'the oldest stream position'?"  Presumably by keeping track of the last stream position that I've checked?

    0
    コメントアクション パーマリンク

サインインしてコメントを残してください。