websocket messages are being dropped

[mstemm]

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 [email protected]

[mstemm]

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]

@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]

Reopening to track a better fix in the client.

[dmehra]

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]

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

[go-oleg]

@davidbcook, i just pushed a fix in [email protected].

[davidbcook]

That worked!

[go-oleg]

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.