Open douggie opened 9 months ago
I wonder if it is to do with the enconder methods not being thread safe. According to java docs they are https://docs.oracle.com/javase/8/docs/api/java/util/Base64.Encoder.html
Binance
Mac mac = getMac();
mac.update(input.getBytes(StandardCharsets.UTF_8));
String printBase64Binary = bytesToHex(mac.doFinal());
okx
Mac mac = getMac();
mac.update(sb.toString().getBytes());
return Base64.getEncoder().encodeToString(mac.doFinal());
Think the issue might be with the mac object, looking over javax.crypto.Mac
I am not sure it is thread safe, so wonder if we need a new mac each time akin to this in org.knowm.xchange.service.BaseParamsDigest
public Mac getMac() {
return mac;
}
to
public Mac getMac() {
try {
return (Mac) mac.clone();
} catch (Error | Exception e) {
throw new IllegalStateException(e);
}
I noticed a lot of okx requests get rejected with invaild sign when submitting multiple requests at same time.
Such issues don't happen on binace xchange implementation, they both seem to use the same decorator pattern, so wondering if there is something else here is not thread safe. Pointers welcomed on where the threading issue might be! Making the
public String digestParams(RestInvocation restInvocation)
synchronised seems a bit overkillpublic synchronized String digestParams(RestInvocation restInvocation)
Binance