sebm253/BotListHandler

Javacord support

Closed this issue · 15 comments

Hey uhm I wanted to ask you if this is getting Javacord support.

in theory i could add support for javacord, but you will have to wait a bit until i figure out how javacord works and how to publish support for jda and javacord independently

ok so this feature will release in the future?

ok so this feature will release in the future?

yes, the development is already in progress. the support is already finished, but it needs some testing and polishing. see #4

ok nice....I will watch at that.

Oh do you also support shards? I am using shards...And Javacord gives back a Collection of APIs.....Is that a problem then?

no, BLH doesn't support sharding yet - however if your bot isn't big enough to even make use of sharding, then it's pointless and might introduce degraded performance. though i suppose the support can be added pretty easily

My Bot is big enough for 3 Shards....Thats not a problem.

just to confirm, are you planning to use BLH with automatic stats posting?

Yes. Thats a nice thing you made :D

support for sharding - in your case a Collection of DiscordApi objects has been released. you'll have to wait a bit for maven central to process the release. the modules' version will be 2.0.0_4

So it now also supports Javacord with Sharding?

yes, i literally said that one comment above yours

2021-04-15 10:16:06,158 <OkHttp https://top.gg/... > <[]> <{}> < dev.mlnr.blh.core.api.BotListHandler> Failed to update the stats for bot list TOP_GG with code 403 AND

java.net.SocketTimeoutException: timeout
	at okhttp3.internal.http2.Http2Stream$StreamTimeout.newTimeoutException(Http2Stream.kt:677) ~[okhttp-4.9.1.jar:?]
	at okhttp3.internal.http2.Http2Stream$StreamTimeout.exitAndThrowIfTimedOut(Http2Stream.kt:686) ~[okhttp-4.9.1.jar:?]
	at okhttp3.internal.http2.Http2Stream.takeHeaders(Http2Stream.kt:143) ~[okhttp-4.9.1.jar:?]
	at okhttp3.internal.http2.Http2ExchangeCodec.readResponseHeaders(Http2ExchangeCodec.kt:96) ~[okhttp-4.9.1.jar:?]
	at okhttp3.internal.connection.Exchange.readResponseHeaders(Exchange.kt:106) ~[okhttp-4.9.1.jar:?]
	at okhttp3.internal.http.CallServerInterceptor.intercept(CallServerInterceptor.kt:79) ~[okhttp-4.9.1.jar:?]
	at okhttp3.internal.http.RealInterceptorChain.proceed(RealInterceptorChain.kt:109) ~[okhttp-4.9.1.jar:?]
	at okhttp3.internal.connection.ConnectInterceptor.intercept(ConnectInterceptor.kt:34) ~[okhttp-4.9.1.jar:?]
	at okhttp3.internal.http.RealInterceptorChain.proceed(RealInterceptorChain.kt:109) ~[okhttp-4.9.1.jar:?]
	at okhttp3.internal.cache.CacheInterceptor.intercept(CacheInterceptor.kt:95) ~[okhttp-4.9.1.jar:?]
	at okhttp3.internal.http.RealInterceptorChain.proceed(RealInterceptorChain.kt:109) ~[okhttp-4.9.1.jar:?]
	at okhttp3.internal.http.BridgeInterceptor.intercept(BridgeInterceptor.kt:83) ~[okhttp-4.9.1.jar:?]
	at okhttp3.internal.http.RealInterceptorChain.proceed(RealInterceptorChain.kt:109) ~[okhttp-4.9.1.jar:?]
	at okhttp3.internal.http.RetryAndFollowUpInterceptor.intercept(RetryAndFollowUpInterceptor.kt:76) ~[okhttp-4.9.1.jar:?]
	at okhttp3.internal.http.RealInterceptorChain.proceed(RealInterceptorChain.kt:109) ~[okhttp-4.9.1.jar:?]
	at okhttp3.internal.connection.RealCall.getResponseWithInterceptorChain$okhttp(RealCall.kt:201) ~[okhttp-4.9.1.jar:?]
	at okhttp3.internal.connection.RealCall$AsyncCall.run(RealCall.kt:517) [okhttp-4.9.1.jar:?]
	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1130) [?:?]
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:630) [?:?]
	at java.lang.Thread.run(Thread.java:832) [?:?]```

Tokens are correct...Whats happening?

the exception states a timeout, so maybe it's your internet or top.gg's api dying? though that doesn't really correspond to the 403 - however it'd be better if we wouldn't spam this issue and rather escalate your problem to a new issue

ok. I`ll open a new one.