Add ClientConnectionListener listener

[arsenalzp]

Here is the draft of changes proposed to solve #9529
Let's discuss it in the issue thread as the implementation was not hardened yet.

[gregw]

@arsenalzp Would it be OK if we implemented this in jetty-12.1.0 rather than 12.0.x? We are trying to feature freeze 12.0

[arsenalzp]

@arsenalzp Would it be OK if we implemented this in jetty-12.1.0 rather than 12.0.x? We are trying to feature freeze 12.0

This approach is OK for me!

[sbordet]

@arsenalzp good start.

Please review my comments, but I really need you to add test cases.

[arsenalzp]

@arsenalzp good start.

Please review my comments, but I really need you to add test cases.

Of course it is good to have test cases, however as I said it is the draft, just to show the framework of solution.

[arsenalzp]

I'm thinking about the place of ConnectListenerTest test class.
Naturally it should be put inside org.eclipse.jetty.io package, in that case it is necessary to import Server and HttpClient classes and it leads to modifying of pom.xml, however it causes cyclic reference.

What do you think?

[sbordet]

@arsenalzp put the test class in the jetty-tests/jetty-test-client-transport module, and test it as parametrized test with transportsTCP (see examples in that module).

[sbordet]

@arsenalzp please also fix the formatting, see here why the build fails:
https://jenkins.webtide.net/blue/organizations/jenkins/jetty.project/detail/PR-12421/3/pipeline

[arsenalzp]

@arsenalzp please also fix the formatting, see here why the build fails: https://jenkins.webtide.net/blue/organizations/jenkins/jetty.project/detail/PR-12421/3/pipeline

Yeah, issue has been fixed already.

[sbordet]

@arsenalzp another thing.
Instead of calling getBeans(ClientConnector.ConnectListener.class) every time, which is an expensive operation, please override add/removeEventListener, and store the ConnectListener in a local CopyOnWriteArrayList field, so the notification is faster.

[arsenalzp]

@arsenalzp another thing. Instead of calling getBeans(ClientConnector.ConnectListener.class) every time, which is an expensive operation, please override add/removeEventListener, and store the ConnectListener in a local CopyOnWriteArrayList field, so the notification is faster.

Hello,
What is the idea here?
It is already implemented by superclass ContainerLifeCycle:

private final List<Bean> _beans = new CopyOnWriteArrayList<>();
private final List<Container.Listener> _listeners = new CopyOnWriteArrayList<>();

[sbordet]

@arsenalzp in the base class you have a field for List<Container.Listener> so that they can be accessed efficiently without having to look up the beans all the times.

I am proposing that you do similarly in ClientConnector, keeping a field of List<ConnectListener> so that those listeners can be accessed very efficiently, instead of calling getBeans(ClientConnector.ConnectListener.class).

[arsenalzp]

@arsenalzp in the base class you have a field for List<Container.Listener> so that they can be accessed efficiently without having to look up the beans all the times.

I am proposing that you do similarly in ClientConnector, keeping a field of List<ConnectListener> so that those listeners can be accessed very efficiently, instead of calling getBeans(ClientConnector.ConnectListener.class).

It is clear for me now, thank you!
This improvement has just been implemented.

[sbordet]

@arsenalzp another good step, please review my comments.

[sbordet]

@arsenalzp looks good, two things:

1. wrap the calls to ConnectListener methods into try/catch(Throwable).
2. Write tests.

Thanks!

[sbordet]

@arsenalzp FYI there is a Jetty release coming at the end of the month.
If you manage to finish in time, this contribution will be in the next release, otherwise it will go in the next-next release.
Thanks!

[arsenalzp]

@arsenalzp FYI there is a Jetty release coming at the end of the month. If you manage to finish in time, this contribution will be in the next release, otherwise it will go in the next-next release. Thanks!

Let's try to include this enhancement into the upcoming release!

[arsenalzp]

I took other tests of Listeners, however I have feelings they not look good, especially tests for failed connect.

[sbordet]

@arsenalzp thanks for this contribution!

I have integrated your work in #12570, so I am closing this PR.

[arsenalzp]

Does it mean my work within this PR was either unacceptable or done badly?

[sbordet]

Does it mean my work within this PR was either unacceptable or done badly?

No, your work was ok, but needed a little more polishing and more testing, but overall it was accepted for this upcoming release.

Have a look at the new PR for the differences.

Mainly:

• Missed notification for connect success in case of non-blocking.
• Added SocketAddress parameter to onConnectFailure().
• More tests.

Thanks again for this contribution!

Let me know if you want to tackle something else by looking at the Help Wanted issues.
Perhaps #4184 (just the MBean improvements)?

[arsenalzp]

Yes, I'm working on that issue as well, it is just a new topic for me - JMX and so on.
I would like to take something more complex or manage with minor pieces in complex tasks.
This is interesting project which is developed by kind and clever engineers.