Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Command service API is stuck at first run #2399

Closed
jinlinGuan opened this issue Feb 24, 2020 · 7 comments · Fixed by #2418
Closed

Command service API is stuck at first run #2399

jinlinGuan opened this issue Feb 24, 2020 · 7 comments · Fixed by #2418
Assignees
Labels
3-high priority denoting release-blocking issues bug Something isn't working core-services geneva help wanted Extra attention is needed

Comments

@jinlinGuan
Copy link
Contributor

jinlinGuan commented Feb 24, 2020

🐞 Bug Report

Affected Services

The issue is located in: core-command

Is this a regression?

yes, only happen in master branch

Description and Minimal Reproduction

When the command service starts, the first time of executing http://localhost:48082/api/v1/device will be stuck.

  1. download the nightly-build docker-compose file
    https://github.com/edgexfoundry/developer-scripts/blob/master/releases/nightly-build/compose-files/docker-compose-nexus-redis-no-secty.yml
  2. use docker-compose up
    docker-compose -f docker-compose-nexus-redis-no-secty.yml up -d
  3. use curl to send request to http://localhost:48082/api/v1/device
    curl http://localhost:48082/api/v1/device
  4. the request is stuck

🔥 Exception or Error

There is no error log in edgex-core-command container.

🌍 Your Environment

Deployment Environment:

EdgeX Version:
Master

Anything else relevant?
Cancel the curl request, and send it again, the request works properly.
Also, this issue could be reproduced by simply restarting command service.

  1. docker-compose -f docker-compose-nexus-redis-no-secty.yml restart command
  2. send curl request again
@jinlinGuan jinlinGuan added the bug Something isn't working label Feb 24, 2020
@michaelestrin michaelestrin added 3-high priority denoting release-blocking issues geneva core-services labels Feb 24, 2020
@michaelestrin michaelestrin added the help wanted Extra attention is needed label Feb 24, 2020
@jinlinGuan
Copy link
Contributor Author

This issue currently causes failure in blackbox-testing.

@brandonforster
Copy link
Contributor

This might be a regression introduced by #2370 somewhere in the URLClient code. I don't have any insight or theories beyond that.

@michaelestrin
Copy link
Member

This looks to me like a variation of the original issue that led us down the refactoring path.

Possibly newly introduced retry is not working as expected?

Assigned to @brandonforster for investigation/solution.

@brandonforster
Copy link
Contributor

It looks like logging is throwing an error retrieving its configuration from Consul. I'd say there's two issues here:

  1. Why is logging not able to retrieve its configuration?
  2. Why is logging not starting making command stop, shutdown, and then restart over and over and over?

@brandonforster
Copy link
Contributor

I believe I have identified the issue in contracts. Submitting a PR now, I'll use this issue number to update the core-contracts version.

@michaelestrin
Copy link
Member

Closed by edgexfoundry/go-mod-core-contracts#220

@brandonforster
Copy link
Contributor

Reopening, adding a PR to incorporate those changes into the codebase and fix the BB tests.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
3-high priority denoting release-blocking issues bug Something isn't working core-services geneva help wanted Extra attention is needed
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants