-
Notifications
You must be signed in to change notification settings - Fork 539
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
[WARNING] data websocket error, restarting connection: no close frame received or sent #588
Comments
I am also experiencing this while comparing with CoinbasePro websocket. I've just run some 10 minutes and 2 of these where data stalled for some seconds or maybe 10+, while Coinbase Pro connection keeps runnnig without problem |
I can't understand Alpaca focusing in adding more features/markets while the core of thier business (data) is getting worse everyday. i'm thinking of switching, for the same problem, i'm sure they're dropping random connections to reduce load. they don't care anymore |
This is a challenge inherent to streaming data with websocket, if the client is not consuming data at the rate that the server is producing, client is bound to get disconnected. This is a pretty good article of why this happens. Some suggestions:
|
for me i'm subscribing to 10 to 20 symbols trades max on a 64Gb RAM 8Cores VPS nothing else, and yet connection drop every 5 to 20 seconds (1006,1011), if it's a websocket client issue we would experience the same for other websockets, for example our binance subscribtion run with all available coins +500 live, for 7 months with no disconnections (python also). |
100% agree that this needs to be addressed. As I reported, I'm also comparing with coinbase pro websocket connection and it doesn't disconnect. With my internal hat on, Alpaca's backend team is working on it and we are hoping to get this sorted. @ovresko you mentioned it got worse. Do you know around when it got worse, and was it not like this before? |
@umitanuki @ovresko @kimboox44 To help better address the issue, can you see if you can reproduce the undesirable interimittent disconnects by using https://github.com/hashrocket/ws with the same subscription message you are using with alpaca python sdk. This will help us better understand if this is specific to the websocket client implementation in our python sdk (which I believe it may be) vs our streaming endpoint. |
@raja i did try ws, for bars it just stops same behaviour, after a minute without any messages tried in two seperate networks (DSL, 4G) same, and i don't see anything useful except response data meaning low level logs |
there are some data providers that offers dynamic price update interval on ws, live/100ms/500ms/1s to be set at subscription to address the situation where clients can't keep up, that would solve all performance related issues (just opt for lower rate) |
Hey just to give an update here since its been over a week. While we are still investigating this issue, we have recently merged a PR that we hope will help lessen the frequency and severity of this issue in the mean time for most users. We also have a second PR merged allowing users to configure the options we pass to the websocket library we use under the hood themselves if these defaults wont work for them.
|
Still facing this problem in the new |
Is there an existing issue for this?
Current Behavior
websocket connection on sip is unusable for me, a connection lost every 10 seconds, one of tow errors
simple subscribtion to bars for all symbols
attempts:
log websocket shows ping timeout sometimes
some suggested that api already reconnect automatically, that's not a solution because you're missing 5sec of timeout before the connection actually drop plus reconnection+subscription time, that leaves gaps in 1minute bars by the time you start receiving again.
for 24h run i got a total of 290 candles on AAPL (because of this error) out of possible 960 candles that 70% lost data.
my guess:
Expected Behavior
Expected to work
Steps To Reproduce
Anything else?
No response
The text was updated successfully, but these errors were encountered: