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

Problem with shinyloadtest::load_runs on remote server #124

Closed
watson-microexcel opened this issue Dec 10, 2019 · 6 comments
Closed

Problem with shinyloadtest::load_runs on remote server #124

watson-microexcel opened this issue Dec 10, 2019 · 6 comments
Assignees
Labels
Difficulty: Advanced Best for maintainers to address Effort: Low < 1 day of work Priority: Critical Must be fixed and a release must follow the fix Type: Bug Maintainers have validated that it is a real bug in the project code

Comments

@watson-microexcel
Copy link

We are trying to setup a load test for a remote server and having issues loading the report.

We are able to record the sessions and run the the recording with several workers on a remote machine, but we are running into problems when we trying to load the runs using:
df <- shinyloadtest::load_runs("mytest" = "./run1")

We are receiving the following error:

Error: $ operator is invalid for atomic vectors

We are able to run this on our local dev environment with 1 worker without an issue. The only difference we see in the recording.log file is the w${WORKER} and the target types ("Shiny Server or Shiny Server Pro" vs "R/Shiny")

What is the best way to debug this? Are we missing something?

@alandipert alandipert self-assigned this Dec 10, 2019
@alandipert
Copy link
Contributor

alandipert commented Dec 10, 2019

Hi, thanks for the report. I haven't seen that one before. Would you please reproduce the error, then call traceback() and report back with the full stack trace? That would help us narrow it down.

@alandipert alandipert added the Type: Bug Maintainers have validated that it is a real bug in the project code label Dec 10, 2019
@alandipert
Copy link
Contributor

Oh, another thing that would be helpful for you to try would be to transfer the run1 from the remote machine to your local machine, and see if load_runs() fails with that data locally.

Also, if you're an RStudio customer, don't hesitate to send an e-mail to support@rstudio.com referencing this thread and my name. If you go that route, you could send us your run1 data confidentially and I could try to reproduce the problem.

@watson-microexcel
Copy link
Author

Hi, thanks for the report. I haven't seen that one before. Would you please reproduce the error, then call traceback() and report back with the full stack trace? That would help us narrow it down.

Thanks for the quick reply.

Here is the traceback() results.

load_runs_traceback.txt

In response to your second message: We are recording and running (shinycannon) on our local machines. We have the recordings locally. Should we be running them on the remote machine?

@alandipert
Copy link
Contributor

Thanks for the that traceback(). I'm studying it.

Re: recordings, sorry, I was confused. I was under the impression that you were running load_runs() on the remote machine, but it sounds like you have run1 locally and are running load_runs() locally. Is my understanding correct?

It would be most helpful if you were able to somehow send the contents of run1 to me so that I could reproduce myself. A copy of the recording could be helpful too. Let me know by email to alan@rstudio.com if that would be feasible.

Otherwise, I'll try to figure it out just based on the trace and let you know what I find.

@alandipert
Copy link
Contributor

@schloerke studied the traceback and suggested the problem might be around JSON deserialization. It seems likely there's a JSON object in the run log with an unexpected structure, and assumptions in load_runs() that a named list exists are invalid. It's definitely odd that we haven't encountered this before in our own testing, so we're very interested in helping you get to the bottom of this.

Unfortunately there are a few places the error could be happening, and it's hard to know which one without your run1 data. So, if you could somehow provide that data to us, we'd be grateful.

@watson-microexcel
Copy link
Author

watson-microexcel commented Dec 11, 2019 via email

@alandipert alandipert added Difficulty: Advanced Best for maintainers to address Effort: Low < 1 day of work Priority: Critical Must be fixed and a release must follow the fix labels Dec 11, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Difficulty: Advanced Best for maintainers to address Effort: Low < 1 day of work Priority: Critical Must be fixed and a release must follow the fix Type: Bug Maintainers have validated that it is a real bug in the project code
Projects
None yet
Development

No branches or pull requests

2 participants