Skip to content
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

Thread.sleep() -> IllegalArgumentException #7

Open
l33th4x0rr opened this issue Nov 23, 2020 · 2 comments
Open

Thread.sleep() -> IllegalArgumentException #7

l33th4x0rr opened this issue Nov 23, 2020 · 2 comments

Comments

@l33th4x0rr
Copy link

l33th4x0rr commented Nov 23, 2020

Getting the following error shortly after starting a WebSocket:

Exception in thread "Thread-14" java.lang.IllegalArgumentException: timeout value is negative
	at java.base/java.lang.Thread.sleep(Native Method)
	at com.bitvavo.api.Bitvavo$2.run(Bitvavo.java:228)
	at java.base/java.lang.Thread.run(Thread.java:834)

The websocket itself is functioning properly, its just that this error gets thrown frequently. This is also happening randomly when the websocket has been running for some time.

@l33th4x0rr
Copy link
Author

@joeri-vv ?

@joeri-vv
Copy link
Collaborator

joeri-vv commented Dec 3, 2020

Excuse me, this one slipped by.
I am not able to reproduce this error. The difference between the rate limit reset and the current time should in theory never be negative. Could you please check your System.currentTimeMillis() against our time endpoint (which returns our server time)? On windows systems i've had the problem before where the clock would drift, and would require manual synchronisation with the windows servers.
For now you can replace Thread.sleep(timeToWait); in line 198 of Bitvavo.java to:

if (timeToWait > 0) {
    Thread.sleep(timeToWait);
}

and rebuild through mvn clean install.
If the ratelimitreset would be negative, the timeout is not required either, so it is fine to skip the sleep.
Before pushing this update, i would like to know how you could get negative values. Please could you print the rateLimitReset and current time through System.currentTimeMillis(), while also noting the timestamp externally through a service like epoch converter. If this is simply because the roundtrip + execution time is larger than the timeout itself, this fix would be fine to push.

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

No branches or pull requests

2 participants