Refresh of CellTable via data transmitted via WebSocket delayed

[Kay Pac]

I have a somewhat complex problem related to a CellTable that updates based on messages received over a WebSocket connection. The problem is as follows: The table does not update in real-time, even though "setRowData" and redraw* are called in real-time. There is a delay in the row appearing in the CellTable, or rather in the DOM as a table row. I realize that redraw does not actually redraw but sets a flag via HasDataPresenter.redraw, which checked elsewhere. It is often the case that mouse movement causes the row to appear - and I have been able to reproduce this behavior. When I put in a timer firing every 300 milliseconds, its execution also causes the row to appear.

It is flummoxing because the problem did not occur until I switched from a prototype implementation of basic websockets to a prototype implementation of STOMP-wrapped websockets (stomp being a MOM-supported protocol for supported messaging from "simple clients"). However, in both cases, there is no difference as to when the data is delivered via setData and redraw is called, so the change should not affect how or when the cellTable gets updated.

I am considering eliminating the use of CellTable and have a simpler DOM manipulation, but I'd prefer to determine what I am doing that is causing this problem, whether it is misuse of CellTable API or inappropriate expectations of CellTable behavior. I can't really post any code because it is all integrated, and I can kind of work around it.

Does anyone have any ideas how to approach this problem or where I might begin to look for a solution?

Sincerely,
Kay

[Thomas Broyer]

On Friday, September 23, 2016 at 2:04:19 AM UTC+2, Kay Pac wrote:

I have a somewhat complex problem related to a CellTable that updates based on messages received over a WebSocket connection. The problem is as follows: The table does not update in real-time, even though "setRowData" and redraw* are called in real-time. There is a delay in the row appearing in the CellTable, or rather in the DOM as a table row. I realize that redraw does not actually redraw but sets a flag via HasDataPresenter.redraw, which checked elsewhere. It is often the case that mouse movement causes the row to appear - and I have been able to reproduce this behavior. When I put in a timer firing every 300 milliseconds, its execution also causes the row to appear.

That hints at the callback that calls the setRowData and redraw not being wrapped in $entry().

CellTable defers its DOM update using Scheduler.scheduleFinally(), and "finally commands" (and "entry commands") are processed by $entry().

So, your callback schedules a finally task, but because it's not in $entry() it's not called "at the end of the event loop" as it's expected to; it's actually called at the end of the next event loop that uses $entry(), which is the case for almost anything that GWT does: event handlers, timers, etc.

So: make sure your WebSocket's callback is wrapped in $entry() (this also takes care of the GWT.UncaughtExceptionHandler btw)

[Kay Pac]

Thanks very much Thomas - that was it. I checked the gwt-websocket, and it is indeed using $entry, while gwt-stomp is not. I altered the code and the problem seems to be resolved. Whew! So happy to have found this solution.

Kay