Parity-ethereum: Websockets queue gets full

Created on 21 Nov 2016  路  13Comments  路  Source: openethereum/parity-ethereum

Loads of these errors after running the UI for a while:

Error while sending response: WS Error <Queue(NotifyError::Full(..))>

F3-annoyance 馃挬 M6-rpcapi 馃摚 P5-sometimesoon 馃尣

Most helpful comment

Might be caused by #6387 (and related to #6406).

All 13 comments

In-progress (number of PRs and issues) - looking at all the places where we are getting information & ensuring

(a) Things are retrieved only when connected
(b) Things are retrieved at the longest possible interval

The overflow on the console seems to happen most frequently when disconnecting the node and starting it up again after a while, i.e. the UI polls when it shouldn't and then floods when the node is back up.

@ngotchac Anything else I missed in the optimisations?

One possible problem is that the WS connection is not detecting that the server is down, so all the requests are actually being queued in the browser (this could explain increasing Chrome memory usage reported in some other issue), then when node is back up the requests are actually being sent to the node.

Possible we should introduce some hearbeat mechanism in websockets so that the clients can detect disconnected state earlier.
Related: #1175

In which cases can the server be down without the WS connection being closed?
From the optimisations in several PRs, the UI should only make a few requests per minute (less than 20). This could and should be further optimized though (don't repeat the same requests).

If the server don't send a TCP FIN packet we may never detect that the server is actually down (it shouldn't be the case if Parity is closed cleanly), the general recommendation is to have some kind of ping/pong mechanism for both client and server to detect such connections.

Happens very reliably when the chain in syncing - while detail queries are only made on new blocks, they basically get made every time while in syncing mode, flooding the node with requests.

Will be addressed in https://github.com/ethcore/parity/issues/3582

This should be fixed thanks to several merged PRs.

I still get this with Parity//v1.6.10-stable-1a5b176-20170721/x86_64-linux-gnu/rustc1.18.0
while a transaction is pending - lots of identical
2017-08-17 04:15:27 Error while sending response: WS Error especially after it changes status from pending to mined.

It triggers everytime while using chrome extension + parity backend and I browse to etherdelta.github.io

mee too

Might be caused by #6387 (and related to #6406).

maybe, i add many accounts in parity recently.

Yes, its most probably #6387 . Let's wait and see if it reproduces after that gets fixed

Replaced by #7032.

Was this page helpful?
0 / 5 - 0 ratings