[Enhancement] Socket Channel may be null if error or crash during client-side connecting

[Bannirui]

Search before asking

• I had searched in the issues and found no similar issues.

Enhancement Request

Locating at: org/apache/eventmesh/client/tcp/common/TcpClient.java
Line: 118

the implementation of close()

try{
    channel.disconnect().sync();
    // ...
} catch {
    // ...
}

close() would be called

• call func explicitly
• call func in finally block for resource safety
• deffer implicitly caz try()

socket will fail if the error or crash is on bind(), channel reference will be Null

Describe the solution you'd like

Removing channel.disconnect().sync(); , resources will be closed with the determination of EventLoopGroup

Are you willing to submit PR?

• Yes I am willing to submit a PR!

[github-actions]

Welcome to the Apache EventMesh (incubating) community!!
We are glad that you are contributing by opening this issue. :D

Please make sure to include all the relevant context.
We will be here shortly.

If you are interested in contributing to our project, please let us know!
You can check out our contributing guide on contributing to EventMesh.

Want to get closer to the community?

WeChat Group：

Mailing Lists:

Name	Description	Subscribe	Unsubscribe	Archive
Users	User support and questions mailing list	Subscribe	Unsubscribe	Mail Archives
Development	Development related discussions	Subscribe	Unsubscribe	Mail Archives
Commits	All commits to repositories	Subscribe	Unsubscribe	Mail Archives

[github-actions]

It has been 90 days since the last activity on this issue. Apache EventMesh values the voices of the community. Please don't hesitate to share your latest insights on this matter at any time, as the community is more than willing to engage in discussions regarding the development and optimization directions of this feature.

If you feel that your issue has been resolved, please feel free to close it. Should you have any additional information to share, you are welcome to reopen this issue.

[Pil0tXia]

@Bannirui Did the change in #4855 help resolve this issue?