Skip to content

Exception during API request - java.net.ConnectException: connect(..) failed: Can't assign requested address #23255

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

Closed
prasannajoshi2121 opened this issue Sep 11, 2020 · 5 comments
Labels
for: stackoverflow A question that's better suited to stackoverflow.com

Comments

@prasannajoshi2121
Copy link

prasannajoshi2121 commented Sep 11, 2020

Getting following error while running Webclient requests in loop , as follows :

ClientHttpConnector httpConnector =
    new ReactorClientHttpConnector(
        HttpClient.newConnection().compress(true)));

Webclient client =  webClientBuilder
        .clientConnector(httpConnector)
        .baseUrl(baseURL)
        .build();

API calling in loop :

                    client
                    .post()
                    .uri(uri)
                    .bodyValue(rq)
                    .exchange()
                    .flatMap(
                        r -> {
                          if (!r.statusCode().is2xxSuccessful()) {
                   ...
io.netty.channel.AbstractChannel$AnnotatedConnectException: connect(..) failed: Can't assign requested address: localhost/127.0.0.1:8444
	Suppressed: reactor.core.publisher.FluxOnAssembly$OnAssemblyException: 
Error has been observed at the following site(s):
	|_ checkpoint ⇢ Request to POST http://localhost:8444/testaddress [DefaultWebClient]
Stack trace:
2020-09-11T19:46:41.688Z	[ERROR]	90-reactor-http-kqueue-8	reactor.core.publisher.MonoPeekTerminal$MonoTerminalPeekSubscriber:onError:243	na	message-processor interrupted due exception	
Caused by: java.net.ConnectException: connect(..) failed: Can't assign requested address
	at io.netty.channel.unix.Errors.throwConnectException(Errors.java:124)
	at io.netty.channel.unix.Socket.connect(Socket.java:231)
	at io.netty.channel.kqueue.AbstractKQueueChannel.doConnect0(AbstractKQueueChannel.java:717)
	at io.netty.channel.kqueue.AbstractKQueueChannel.doConnect(AbstractKQueueChannel.java:702)
	at io.netty.channel.kqueue.AbstractKQueueChannel$AbstractKQueueUnsafe.connect(AbstractKQueueChannel.java:548)
	at io.netty.channel.DefaultChannelPipeline$HeadContext.connect(DefaultChannelPipeline.java:1342)
	at io.netty.channel.AbstractChannelHandlerContext.invokeConnect(AbstractChannelHandlerContext.java:548)
	at io.netty.channel.AbstractChannelHandlerContext.connect(AbstractChannelHandlerContext.java:533)
	at io.netty.channel.CombinedChannelDuplexHandler$DelegatingChannelHandlerContext.connect(CombinedChannelDuplexHandler.java:495)
	at io.netty.channel.ChannelOutboundHandlerAdapter.connect(ChannelOutboundHandlerAdapter.java:51)
	at io.netty.channel.CombinedChannelDuplexHandler.connect(CombinedChannelDuplexHandler.java:296)
	at io.netty.channel.AbstractChannelHandlerContext.invokeConnect(AbstractChannelHandlerContext.java:548)
	at io.netty.channel.AbstractChannelHandlerContext.connect(AbstractChannelHandlerContext.java:533)
	at io.netty.channel.AbstractChannelHandlerContext.connect(AbstractChannelHandlerContext.java:517)
	at io.netty.channel.DefaultChannelPipeline.connect(DefaultChannelPipeline.java:978)
	at io.netty.channel.AbstractChannel.connect(AbstractChannel.java:253)
	at io.netty.bootstrap.Bootstrap$3.run(Bootstrap.java:250)
	at io.netty.util.concurrent.AbstractEventExecutor.safeExecute(AbstractEventExecutor.java:164)
	at io.netty.util.concurrent.SingleThreadEventExecutor.runAllTasks(SingleThreadEventExecutor.java:472)
	at io.netty.channel.kqueue.KQueueEventLoop.run(KQueueEventLoop.java:293)
	at io.netty.util.concurrent.SingleThreadEventExecutor$4.run(SingleThreadEventExecutor.java:989)
	at io.netty.util.internal.ThreadExecutorMap$2.run(ThreadExecutorMap.java:74)
	at io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
	at java.lang.Thread.run(Thread.java:748)

while hitting server from postman , getting expected response.

spring boot version : <spring.boot.version>2.3.3.RELEASE</spring.boot.version>
reactor core: 3.3.9-RELEASE
reactor-netty : 0.9.11.RELEASE

@spring-projects-issues spring-projects-issues added the status: waiting-for-triage An issue we've not yet triaged label Sep 11, 2020
@philwebb
Copy link
Member

I'm a little confused about the "Can't assign requested address" since this is a client-side call. I suspect something is misconfigured in your application. Could you please provide a minimal reproducible example either as a GitHub project or as an attached zip file. We'll need something that we can download and run ourselves.

@philwebb philwebb reopened this Sep 12, 2020
@philwebb philwebb added the status: waiting-for-feedback We need additional information before we can continue label Sep 12, 2020
@prasannajoshi2121
Copy link
Author

@philwebb please find minimal reproducible example repo

Client App - https://github.com/prasannajoshi2121/spring-test-client.git
Server App - https://github.com/prasannajoshi2121/test-vertx-server.git

Please update this file spring-test-client/first-project/src/main/java/com/first/firstproject/FirstProjectApplication.java like below :
//ClientHttpConnector httpConnector = new ReactorClientHttpConnector(HttpClient.create().compress(true)); ClientHttpConnector httpConnector = new ReactorClientHttpConnector(HttpClient.newConnection());

inside Client App repo , src/main/resource directory please find Httprequest.JMX script.

(Path - spring-test-client/first-project/src/main/resources/HTTP Request.jmx)

Please run JMX script to reproduce issue once Client and server started.

@spring-projects-issues spring-projects-issues added status: feedback-provided Feedback has been provided and removed status: waiting-for-feedback We need additional information before we can continue labels Sep 13, 2020
@philwebb
Copy link
Member

Calling subscribe() from your @Controller method is unusual and likely to lead to the problems you're seeing. It can be justified if you wanted to kick off some asynchronous processing that is detached from the completion of request handling. However if that asynchronous handling has higher delays, that means you can end up with more and more requests coming in, and more of those asynchronous tasks piling up. It seems like that's happening with your sample. It's more typical to return a Mono or Flux from the controller.

One other thing to point out is that you should not use exchange() unless it is for more advanced scenarios because you can easily omit to consume response content in cases errors (4xx or 5xx response) or a cancellation (e.g. the connection was closed by the remote end or the HTTP client) and if you don't handle those you can get a memory and/or connection leak. This is why Spring Framework now plans to deprecate exchange() (see spring-projects/spring-framework#25751).

All things considered, this doesn't look like a bug in Spring Boot or WebFlux, but it feels like a question that would be better suited to Stack Overflow. We prefer to use GitHub issues only for bugs and enhancements.

(Thanks to Rossen Stoyanchev from the WebFlux team who helped with this answer)

@philwebb philwebb added for: stackoverflow A question that's better suited to stackoverflow.com and removed status: feedback-provided Feedback has been provided status: waiting-for-triage An issue we've not yet triaged labels Sep 13, 2020
@rdp
Copy link

rdp commented Mar 29, 2021

Was this ever posted to stackoverflow? If so link possible? Thanks.

@hl821733481

This comment has been minimized.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
for: stackoverflow A question that's better suited to stackoverflow.com
Projects
None yet
Development

No branches or pull requests

5 participants