Skip to content
This repository has been archived by the owner on Jun 8, 2020. It is now read-only.

Resubscribing after client reconnects? #15

Closed
jvii opened this issue Sep 13, 2017 · 10 comments
Closed

Resubscribing after client reconnects? #15

jvii opened this issue Sep 13, 2017 · 10 comments

Comments

@jvii
Copy link

jvii commented Sep 13, 2017

I have been streaming tickers from Poloniex succesfully by following the example here. Works nicely, but everytime the wampclient disconnects (and automatically reconnects) I lose all my subscribtions. So I guess I should always resubscribe to getTicker when the client state changes to connected, but what is the best way to detect this? I can only see the "State changed:" log message when this happens.

Very new to RxJava, so the answer might be obvious, but I just can't seem to figure it out. Thanks!

@dozd
Copy link
Member

dozd commented Oct 26, 2017

Hmm that's quite tricky and probably can't be accomplished right now.

Connect() probably need to be changed to Observable and cannot be Completed upon connection like now. Then it should be possible to listen for connection events in subscribe of connect() and resolve them.

It's pretty big change, I forgot this scenario when designing the library.

@dozd
Copy link
Member

dozd commented Oct 26, 2017

Maybe, it could be possible to make automatic resubscriptions for wamp only.

@dozd
Copy link
Member

dozd commented Oct 26, 2017

It's also a little connected to the WAMP library I'm using. I've increased the version of jawampa-netty in latest release (2.3.0). Just try it again to be sure, issue is still here.

@roeiba
Copy link
Contributor

roeiba commented Dec 2, 2017

With regards to poloniex, There are two exchanges:

  1. xchange-poloniex2 (using Netty)
  2. xchange-poloniex (using WAMP)

Which project is the recommended?

@dozd
Copy link
Member

dozd commented Dec 2, 2017

I suppose newer which is poloniex2

@firegnome
Copy link
Contributor

firegnome commented Dec 3, 2017

@roeiba poloniex2 is using the websocket from the poloniex webpage and was implemented because the WAMP socket is lagging several hours behind, i highly suggest poloniex2 if you need live data.

This is a problem I recognized too and we really need a solution for this. For a first workaround i would suggest to provide a callback if the websocket is closing. With such a solution we would have the ability to reconnect manually.

@dozd Do you have a strategy for the closing problem on other exchanges or does this problem exist on every project?

From what I've seen the reconnect on the poloniex2 is not implemented yet, is it? Its pretty ugly to debug this -.-

@dozd
Copy link
Member

dozd commented Dec 5, 2017

@firegnome I'm not aware of this problem on other exchanges but I think it could happen there as well. I think solution is either change method connect from Completable to Observable and have connection events to be observed or implement some kind of internal auto re-subscribing feature in all implementation services.

@dozd dozd added the bug label Dec 5, 2017
@firegnome
Copy link
Contributor

firegnome commented Dec 5, 2017

I implemented a re-subscribe feature in NettyStreamingService. Additionally I did override the WebSocketClientHandler in poloniex2 to get the disconnect event and automatically reconnect and resubscribe the channels. I'm currently testing if this is actually working... it's a bit tedious because i have to wait for the websocket to close -.-

I'm looking forward to your feedback firegnome@efff9dd

@firegnome
Copy link
Contributor

I tested it and the reconnect is working.
image

@jvii
Copy link
Author

jvii commented Dec 8, 2017

Looks good, thanks for this! As the old wamp api had become almost unusable and xchange-poloniex2 didn't exist yet back in september, I ended up implementing a simple streamer for api2 using Tyrus (which supports reconnects). It works pretty nicely, but I might give this a try later too.

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

No branches or pull requests

4 participants