Bugfix core-data "get event by deviceId" api return no data #376
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
…o data As mongoEvent not match mongodb's structure(models.Event)
|
@unanao, the events are stored as mongoEvent. Why this patch should solve the issue? |
|
Commit isn't signed. No issue created for this PR. Testing this PR against master for the following URL literally produces no difference in behavior. http://localhost:48080/api/v1/event/device/KMC.BAC-121036CE01/5 Testing methodology included |
|
recheck |
Use 'govendor init' instead of 'govendor sync'. Signed-off-by: Tony Espy <espy@canonical.com>
[snap] Fix consul build failure
I observed 200% CPU utilization by core-command and core-data processes.
Profiler showed that culprit is time.Now().After() buzy-loop in
Endpoint.Monitor.
It truly spins for 15 seconds after each "ch" consumption.
Depending on consumption rate it might spin "infinitely"
$ go tool pprof core-command core-command.prof
File: core-command
Type: cpu
Time: Jul 10, 2018 at 3:24pm (PDT)
Duration: 14.52s, Total samples = 28.48s (196.11%)
Entering interactive mode (type "help" for commands, "o" for options)
(pprof) top10 -cum
Showing nodes accounting for 28430ms, 99.82% of 28480ms total
Dropped 51 nodes (cum <= 142.40ms)
flat flat% sum% cum cum%
0 0% 0% 21840ms 76.69% runtime._System /usr/lib/golang/src/runtime/proc.go
20430ms 71.73% 71.73% 20430ms 71.73% runtime._ExternalCode /usr/lib/golang/src/runtime/proc.go
0 0% 71.73% 6600ms 23.17% github.com/edgexfoundry/edgex-go/core/clients/types.(*Endpoint).Monitor <autogenerated>
1230ms 4.32% 76.05% 6600ms 23.17% github.com/edgexfoundry/edgex-go/core/clients/types.Endpoint.Monitor /usr/share/gocode/src/github.com/edgexfoundry/edgex-go/core/clients/types/endpoint.go
1440ms 5.06% 81.11% 4850ms 17.03% time.Now /usr/lib/golang/src/time/time.go
2030ms 7.13% 88.24% 3410ms 11.97% time.now /usr/lib/golang/src/runtime/timestub.go
1890ms 6.64% 94.87% 1890ms 6.64% runtime.walltime /usr/lib/golang/src/runtime/sys_linux_amd64.s
900ms 3.16% 98.03% 900ms 3.16% runtime.nanotime /usr/lib/golang/src/runtime/sys_linux_amd64.s
510ms 1.79% 99.82% 510ms 1.79% time.Time.After /usr/lib/golang/src/time/time.go
Using time.Sleep() fixed the problem and CPU utilization back to normal.
Signed-off-by: Alexey Makhalov <amakhalov@vmware.com>
Use sleep instead of busy-wait
|
recheck |
…return no data" This reverts commit bb77763.
|
I pulled the latest code, the bug not exist |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
API: http://localhost:48080/api/v1/event/device/:deviceId/:limit
Error: no data returned:
Reason: As mongoEvent not match mongodb's structure(models.Event)