java.net.BindException: Address already in use: connect on HTTP Proxies

Hi all, I’m encountering a bind error whenever I use a single rotating HTTP Proxies with a high amount of threads (800).

The error comes in at about 10-16k requests to the same proxy, which is interesting because as far as I can tell, HTTP Proxy sockets are constructed the same way as normal no proxy sockets.

I’m using SmartProxy as a proxy solution right now and it happens under them, but should happen with any provider or a Squid server.

The full Stacktrace is:

at java.base/java.net.PlainSocketImpl.waitForConnect(Native Method)
	at java.base/java.net.PlainSocketImpl.socketConnect(PlainSocketImpl.java:107)
	at java.base/java.net.AbstractPlainSocketImpl.doConnect(AbstractPlainSocketImpl.java:399)
	at java.base/java.net.AbstractPlainSocketImpl.connectToAddress(AbstractPlainSocketImpl.java:242)
	at java.base/java.net.AbstractPlainSocketImpl.connect(AbstractPlainSocketImpl.java:224)
	at java.base/java.net.SocksSocketImpl.connect(SocksSocketImpl.java:403)
	at java.base/java.net.Socket.connect(Socket.java:591)
	at okhttp3.internal.platform.Platform.connectSocket(Platform.kt:126)
	at okhttp3.internal.connection.RealConnection.connectSocket(RealConnection.kt:268)
	at okhttp3.internal.connection.RealConnection.connectTunnel(RealConnection.kt:234)
	at okhttp3.internal.connection.RealConnection.connect(RealConnection.kt:170)
	at okhttp3.internal.connection.ExchangeFinder.findConnection(ExchangeFinder.kt:236)
	at okhttp3.internal.connection.ExchangeFinder.findHealthyConnection(ExchangeFinder.kt:109)
	at okhttp3.internal.connection.ExchangeFinder.find(ExchangeFinder.kt:77)
	at okhttp3.internal.connection.Transmitter.newExchange$okhttp(Transmitter.kt:162)
	at okhttp3.internal.connection.ConnectInterceptor.intercept(ConnectInterceptor.kt:35)
	at okhttp3.internal.http.RealInterceptorChain.proceed(RealInterceptorChain.kt:112)
	at okhttp3.internal.http.RealInterceptorChain.proceed(RealInterceptorChain.kt:87)
	at okhttp3.internal.cache.CacheInterceptor.intercept(CacheInterceptor.kt:82)
	at okhttp3.internal.http.RealInterceptorChain.proceed(RealInterceptorChain.kt:112)
	at okhttp3.internal.http.RealInterceptorChain.proceed(RealInterceptorChain.kt:87)
	at okhttp3.internal.http.BridgeInterceptor.intercept(BridgeInterceptor.kt:84)
	at okhttp3.internal.http.RealInterceptorChain.proceed(RealInterceptorChain.kt:112)
	at okhttp3.internal.http.RetryAndFollowUpInterceptor.intercept(RetryAndFollowUpInterceptor.kt:71)
	at okhttp3.internal.http.RealInterceptorChain.proceed(RealInterceptorChain.kt:112)
	at okhttp3.internal.http.RealInterceptorChain.proceed(RealInterceptorChain.kt:87)
	at io.kekr.core.base.Kekr$launchCheck$1$invokeSuspend$$inlined$-addInterceptor$1.intercept(Interceptor.kt:82)
	at okhttp3.internal.http.RealInterceptorChain.proceed(RealInterceptorChain.kt:112)
	at okhttp3.internal.http.RealInterceptorChain.proceed(RealInterceptorChain.kt:87)
	at okhttp3.RealCall.getResponseWithInterceptorChain(RealCall.kt:184)
	at okhttp3.RealCall.execute(RealCall.kt:66)
	at io.kekr.core.connection.OkHttpHelperKt$await$2$1.invokeSuspend(OkHttpHelper.kt:56)
	at kotlin.coroutines.jvm.internal.BaseContinuationImpl.resumeWith(ContinuationImpl.kt:33)
	at kotlinx.coroutines.DispatchedTask.run(Dispatched.kt:238)
	at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
	at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)

Using OkHttp 4.0.1 but also happens on 3.14.0

Thanks!

[GramDev1]

I read the Connection Pool documentation, and then had to take a peek at the Address.kt class and the .equals() method to find it wouldn’t pool. Not really sure where the best place to put this info is. I think this is fixable by allowing connections to the same server but different authenticators to pool, not sure if this is totally possible but I’m assuming it is.

[swankjesse]

I don’t think this feature request fits our security goals. The downsides of sharing authenticators are many; the upsides are few!