search

vhs / api

VHS API - the Hackspace Data Store
4 stars 1 forks source link

Datapoint update takes seconds to complete #9

Closed acropup closed 7 years ago

acropup commented 8 years ago

It's taking up to 5 seconds for a value update to change the value received upon a query. I don't know enough about this framework to know if this is expected.

To Reproduce: Prepare two web browser tabs.

  1. Update tab: http://api.hackspace.ca/s/vhs/data/test1/update?value=test1
  2. Query tab: http://api.hackspace.ca/s/vhs/data/test1.txt

Go to Query tab, and make sure the value is different from the value being submitted in the Update's querystring. Submit Update query, i.e. go to Update URL. Immediately switch to Query tab, press F5 repeatedly and watch for change.

Current Behaviour: The value seems to change within 5 seconds of submitting an update.

Expected Behaviour: The first query after an update, no matter how soon after, should return the updated value.

@interlock, do you have any idea why this is happening?

interlock commented 8 years ago

@acropup I believe this is a side effect of influxdb being used instead of redis now.

My first guess, based on the InfluxDB notes, is that the timestamp being sent for the data point is 5 seconds or so in the future for the InfluxDB instance. InfluxDB will not return a result from the future.. because that is time travel!

@garthomite Is InfluxDB running on the same machine at the api? If not, we probably just need to setup ntp on each to fight the clock drift.

garthomite commented 8 years ago

They are running on the same server, I think it takes a second to commit the result - I noticed this as well.

If it becomes a problem then I might have to cache the last update in memory which isn't ideal.

On Fri, Dec 4, 2015 at 7:17 PM James S notifications@github.com wrote:

@acropup https://github.com/acropup I believe this is a side effect of influxdb being used instead of redis now.

My first guess, based on the InfluxDB notes, is that the timestamp being sent for the data point is 5 seconds or so in the future for the InfluxDB instance. InfluxDB will not return a result from the future.. because that is time travel!

@garthomite https://github.com/garthomite Is InfluxDB running on the same machine at the api? If not, we probably just need to setup ntp on each to fight the clock drift.

— Reply to this email directly or view it on GitHub https://github.com/vhs/api/issues/9#issuecomment-162135330.

acropup commented 8 years ago

It's not a significant problem for me, it was just something my unit tests revealed as I was debugging my program. I don't necessarily need it to respond immediately, and Garth will be making a new API specifically for the door anyway.

On Fri, Dec 4, 2015 at 10:56 PM, Garth Cumming notifications@github.com wrote:

They are running on the same server, I think it takes a second to commit the result - I noticed this as well.

If it becomes a problem then I might have to cache the last update in memory which isn't ideal.

On Fri, Dec 4, 2015 at 7:17 PM James S notifications@github.com wrote:

@acropup https://github.com/acropup I believe this is a side effect of influxdb being used instead of redis now.

My first guess, based on the InfluxDB notes, is that the timestamp being sent for the data point is 5 seconds or so in the future for the InfluxDB instance. InfluxDB will not return a result from the future.. because that is time travel!

@garthomite https://github.com/garthomite Is InfluxDB running on the same machine at the api? If not, we probably just need to setup ntp on each to fight the clock drift.

— Reply to this email directly or view it on GitHub https://github.com/vhs/api/issues/9#issuecomment-162135330.

— Reply to this email directly or view it on GitHub https://github.com/vhs/api/issues/9#issuecomment-162156848.