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

Expose stack trace to JavaScript #318

Open
tresf opened this issue May 3, 2018 · 4 comments
Open

Expose stack trace to JavaScript #318

tresf opened this issue May 3, 2018 · 4 comments
Assignees
Milestone

Comments

@tresf
Copy link
Contributor

tresf commented May 3, 2018

For cloud providers, it is requested that we can provide a full java.lang.Exception backtrace from Java to JavaScript when an exception occurs to reduce the number of times the provider has to remote into the client workstation.

This is a placeholder to track the feasibility of this request.

@tresf tresf added this to the 2.0.8 milestone May 3, 2018
@tresf tresf modified the milestones: 2.0.8, 2.0.9 Oct 26, 2018
@akberenz
Copy link
Member

What about taking advantage of our stream system for this?

Something along the lines of

qz.api.setExceptionCallbacks(function(event) {
  console.log(event.exception);
  console.log(event.message);
  console.log(event.stacktrace);
  // other things ?
}));

We'd have to go through and add a sendStream java-side to all the exceptions we want visibility on, and make sure all sessions get a copy, but it should be possible.

@tresf
Copy link
Contributor Author

tresf commented Dec 20, 2018

What if we made it promise-driven fetch of the details only when one occurs? The exceptions are already being raised we just need more details.

Perhaps another option is to provide an API for fetching the logs?

I guess any solution may suffer the possibility of the exception being a breaking one and ending the WebSocket communication.

@akberenz
Copy link
Member

The problem with a fetch is we either have to have a queue to fetch from or you run the risk of having the exception you actually want to see being overridden by another and being unable to retrieve it without constant polling.
Just having an api for fetching the logs instead might be the best compromise though.

If its a crash causing exception though, won't they have to remote in anyway to restart it? Probably not a situation we can respond to anyways, so not one we should worry about for now.

@tresf
Copy link
Contributor Author

tresf commented Dec 20, 2018

Yeah, that sounds like a good compromise.

@tresf tresf modified the milestones: 2.0.9, 2.0.11 Apr 18, 2019
@tresf tresf modified the milestones: 2.0.11, 2.1.2 Jan 10, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants