Skip to content
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

fix the bug: the channel will not closed in time when timeout by using telnet in QOS #7282

Merged
merged 5 commits into from Feb 28, 2021
Merged

Conversation

wathenjiang
Copy link

What is the purpose of the change

Fix the bug: don't close the channel when timeout by using telnet in QOS.

see #7281

Brief changelog

When using IdleStateHandler with TelnetProcessHandler in the QosProcessHandler, the timeout is set to 5*60 seconds, but NO handler deals with the IdleStateEvent. Maybe the TelnetProcessHandler should override the userEventTriggered method to handle this Event, and close the idle connect.

@wathenjiang wathenjiang changed the title fix the bug: don't close the channel when timeout by using telnet in QOS fix the bug: the channel will not closed in time when timeout by using telnet in QOS Feb 27, 2021
Copy link
Member

@horizonzy horizonzy left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Create a new handler to process this case will be better.

@wathenjiang
Copy link
Author

@horizonzy
Thnx.

In my opinion, for the reason of uniform code style, I prefer to add the userEventTriggered method in TelnetProcessHandler. Refer to class NettyClientHandler & NettyServerHandler.

Could you tell me the reason why you think adding a Handler would be better in this case.

@horizonzy
Copy link
Member

Single responsibility, TelnetProcessHandler just handle the command from client.
In this pr, it's supply a mechanism to close the channel which didn't exchange data for a long time.
In the future, if need add some logic to handle the timeout channel, the logic shouldn't append in TelnetProcessHandler.
And if anyone didn't need this mechanism, just didn't add the new handler

@wathenjiang
Copy link
Author

Single responsibility, TelnetProcessHandler just handle the command from client.
In this pr, it's supply a mechanism to close the channel which didn't exchange data for a long time.
In the future, if need add some logic to handle the timeout channel, the logic shouldn't append in TelnetProcessHandler.
And if anyone didn't need this mechanism, just didn't add the new handler

Yeah, I agree with you, but the fact is that NettyClientHandler & NettyServerHandler don't look like meeting the rule of Single responsibility. I thought it as a code style.. QAQ

@horizonzy
Copy link
Member

Single responsibility, TelnetProcessHandler just handle the command from client.
In this pr, it's supply a mechanism to close the channel which didn't exchange data for a long time.
In the future, if need add some logic to handle the timeout channel, the logic shouldn't append in TelnetProcessHandler.
And if anyone didn't need this mechanism, just didn't add the new handler

Yeah, I agree with you, but the fact is that NettyClientHandler & NettyServerHandler don't look like meeting the rule of Single responsibility. I thought it as a code style.. QAQ

Hi, I'm not agree with you. NettyClientHandler and NettyServerHandler all didn't coupling with business. But TelnetProcessHandler is for business.

@wathenjiang
Copy link
Author

Hi, I'm not agree with you. NettyClientHandler and NettyServerHandler all didn't coupling with business. But TelnetProcessHandler is for business.

You are right and enlighten me a lot, now I can see the difference. It is better to use a New Handler.

Thnks a lot, have a good night !

@horizonzy
Copy link
Member

Hi, apache license should append at the top of the new class.

@wathenjiang
Copy link
Author

Hi, apache license should append at the top of the new class.

I forgot the commit specifications, plz forgive me. QAQ...

import org.apache.dubbo.common.logger.Logger;
import org.apache.dubbo.common.logger.LoggerFactory;

@ChannelHandler.Sharable
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It's not necessary.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

if you means the IdleEventHandler is not necessary, then the p.addLast(new IdleStateHandler(0, 0, 5 * 60)); in QosProcessHandler may be also not necessary.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

it is kind of chinglish? QAQ hh

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I mean the annotation @Sharable.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

but why?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It's alway create new TelnetIdleEventHandler for channel.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ok, you are right.

import org.apache.dubbo.common.logger.LoggerFactory;

@ChannelHandler.Sharable
public class IdleEventHandler extends ChannelDuplexHandler {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The class name use TelnetIdleEventHandler will be better, what do you think about it.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It is ok. Because when we use HTTP, All HTTP request is HTTP short connection, IdleEventHandler only used for telnet.

@codecov-io
Copy link

Codecov Report

Merging #7282 (6c38249) into master (4ad2634) will decrease coverage by 0.23%.
The diff coverage is 30.00%.

Impacted file tree graph

@@             Coverage Diff              @@
##             master    #7282      +/-   ##
============================================
- Coverage     59.03%   58.80%   -0.24%     
  Complexity      461      461              
============================================
  Files          1043     1044       +1     
  Lines         42445    42411      -34     
  Branches       6222     6191      -31     
============================================
- Hits          25057    24938     -119     
- Misses        14587    14661      +74     
- Partials       2801     2812      +11     
Impacted Files Coverage Δ Complexity Δ
...che/dubbo/qos/server/handler/IdleEventHandler.java 22.22% <22.22%> (ø) 0.00 <0.00> (?)
...he/dubbo/qos/server/handler/QosProcessHandler.java 57.14% <100.00%> (+1.26%) 0.00 <0.00> (ø)
...va/org/apache/dubbo/remoting/TimeoutException.java 0.00% <0.00%> (-33.34%) 0.00% <0.00%> (ø%)
...ng/transport/dispatcher/all/AllChannelHandler.java 62.06% <0.00%> (-27.59%) 0.00% <0.00%> (ø%)
...bo/config/event/listener/LoggingEventListener.java 37.50% <0.00%> (-25.00%) 0.00% <0.00%> (ø%)
...bbo/common/bytecode/CustomizedLoaderClassPath.java 28.00% <0.00%> (-16.00%) 0.00% <0.00%> (ø%)
...va/org/apache/dubbo/remoting/exchange/Request.java 72.54% <0.00%> (-15.69%) 0.00% <0.00%> (ø%)
...rg/apache/dubbo/remoting/utils/PayloadDropper.java 76.92% <0.00%> (-15.39%) 0.00% <0.00%> (ø%)
...ng/transport/dispatcher/WrappedChannelHandler.java 47.82% <0.00%> (-15.22%) 0.00% <0.00%> (ø%)
.../remoting/transport/netty4/NettyServerHandler.java 56.81% <0.00%> (-13.64%) 0.00% <0.00%> (ø%)
... and 45 more

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 4ad2634...07c4830. Read the comment docs.

Copy link
Member

@horizonzy horizonzy left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

Copy link
Member

@AlbumenJ AlbumenJ left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM.

@AlbumenJ AlbumenJ merged commit 51d5a88 into apache:master Feb 28, 2021
AlbumenJ added a commit to AlbumenJ/dubbo that referenced this pull request May 27, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

4 participants