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

websocket messages are being dropped #9

Open
mstemm opened this issue Feb 3, 2016 · 8 comments · Fixed by #8
Open

websocket messages are being dropped #9

mstemm opened this issue Feb 3, 2016 · 8 comments · Fixed by #8
Labels

Comments

@mstemm
Copy link

mstemm commented Feb 3, 2016

This bug is still reproducing even with this fix in place.

There have been some reports of outrigger not showing all the points coming out of a juttle program, see original bug report in juttle/outrigger#131 with debugging notes.

A program to reproduce this (originally was reproing with 1 chart, now needs 4):

read file -file 'dense.json' -to :2014-01-01T00:59:59:
| keep value1, time
|(
  view timechart -title 'Chart One' -valueField 'value1' -display.dataDensity 0;
  view timechart -title 'Chart Two' -valueField 'value1' -display.dataDensity 0;
  view timechart -title 'Chart Three' -valueField 'value1' -display.dataDensity 0;
  view timechart -title 'Chart Four' -valueField 'value1' -display.dataDensity 0;
)

The json file (needs to be renamed to .json): dense.txt

If you run this program, you will get 3 timecharts fully loaded, but without context charts underneath, and Chart Four will be "Waiting for data" with nothing rendered.

Reproduces on build juttle-engine@0.2.1

@mstemm
Copy link
Author

mstemm commented Feb 3, 2016

We decided that the best + easiest workaround is to actually close the websocket connection from the server side after a short delay. That should give the browser enough time to actually read + process all datapoints before the connection close causes it to lose the final points.

@mstemm
Copy link
Author

mstemm commented Feb 3, 2016

@mccanne rightly pointed out that we should keep this github issue open until we fix the problem within the client, or decide that it's really impossible to fix within the client.

@mstemm mstemm closed this as completed in #8 Feb 4, 2016
@mstemm
Copy link
Author

mstemm commented Feb 4, 2016

Reopening to track a better fix in the client.

@mstemm mstemm reopened this Feb 4, 2016
mstemm referenced this issue in juttle/outrigger Feb 4, 2016
This is a fix for #131, taking parts of the fix from juttle-engine for
juttle/juttle-engine#9. I didn't bother with a fully configurable timeout.

I did copy over a unit test to ensure that there is a delay between
the job_end message and the websocket being closed.
@dmehra dmehra added the bug label Feb 11, 2016
@dmehra
Copy link

dmehra commented Feb 11, 2016

I updated bug description as it is still reproducing; the fix in this commit moved the failure point out, but it can still be reached. We are still getting user reports from the field running into this. The repro program is in the description.

@davidbcook
Copy link

This bug is my nemesis! Let me know if there's anything I can do to help fix it.

@go-oleg
Copy link
Contributor

go-oleg commented Feb 11, 2016

@davidbcook, i just pushed a fix in juttle-service@0.2.1.

@davidbcook
Copy link

That worked!

@go-oleg
Copy link
Contributor

go-oleg commented Feb 11, 2016

Was able to reproduce the issue outside of juttle-service so either our expectations of the websocket api are incorrect or theres a bug in the ws code. Filed websockets/ws#678.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants