connection time out about btfxwss HOT 5 CLOSED

Hey @dzhlovegithub and thanks for submitting an Issue!
In order to help you out I'll need a few more details:

1. What does your code look like?
2. Provide the log calls after you ran your code.
   To provide the log calls, simply upload the log file. To enable logging to file, add the following code:

import logging
logging.basicConfig(filename="btfxwss.log", level=logging.DEBUG)

wss = BtfxWss(key, secret, log_level=logging.DEBUG)
...

Thanks!

from btfxwss.

Hello @nlsdfnbch,

I may have a related problem, when trying to establish a long-running websocket connection. I'm not sure if it is intentional or not, but at the moment it seems that the client does not resubscribe to the same channels it was connected to before a timeout or disconnect happened. No subscribed channel leads to endless reconnects due to timeouts. Is this behavior intended or do you consider an automatic renewal of subscriptions?

My problem is that I don't have/know a method to decide the moment I need to resubscribe to channels after a disconnect, without changing your code.

from btfxwss.

Hey @8ick and thanks for reaching out!
It is true that the client does not automatically re-subscribe to channels if the connection drops. This was implemented in early versions, but continuously led to unexpected behaviour and errors.
However, it is certainly on the to-do list. Unfortunately I cannot give you an exact ETA for it - at the very earliest I will be able to give it a shot in roughly two weeks. Sorry :/

from btfxwss.

@nlsdfnbch
Do you have a recommendation how to catch a reconnect at the moment? I used a timer and tried re-subscribing if no new data was received in the last 120s or so, but from what I have seen in the newest version, the client does not tell/return if the subscription was sucessful or not.

Anyway, thanks a lot for your work here.

from btfxwss.

It should tell you - in queue_processor.py at line 134, the _handle_subscribed() method should be doing this. However, this has been Human-readable only. So raising a TimeOutError upon the second or third reconnect may be a possibility.

As far as the temporary fix goes, you can try to handle this yourself, but it will require some programming:

in connection.py, line 316, the method _system_handler()takes care of re-issuing a connection. In this method you'll have to pass a message up to the QueueProcessor using pass_to_client() to tell it to re-send all subscription messages after the restart.
Since the QueueProcessor object doesn't store subscribe calls, you will have to add this as well, so that when a message from Connection with a re-subscribe message arrives it can re-send the messages without bothering the user about it.

from btfxwss.