Fix the issue netty#3806 in 4.1#4858
Conversation
fix sonar reported issue "Add the missing @deprecated annotation"
|
The issues reported by sonar are reported for old code. so if I fix these issues in this pull request, it will involved much more code changes and scopes. So can I omit them (only fix some issues involved small change scope such as deprecated) and only focus on the new code changes? |
fix sonar issue
|
@jiafu1115 It's safe to ignore the info-level comments. They are just there to 'inform' you. I disabled the check about the deprecated members to reduce the amount of the noise. SonarQube Github plugin seems add the comments even for the unchanged lines as long as they are shown in the 'Files changed' view tab. e.g. this cone It's perfectly fine to ignore such a comment, although you may want to address it as well if it's trivial to fix. What I don't like about the plugin is that it adds a summary comment which isn't very useful, and there seem to be no way to disable it for now. |
| private final int writeBufferLowWaterMark; | ||
| private final int writeBufferHighWaterMark; | ||
|
|
||
| public WriteBufferWaterMark() { |
There was a problem hiding this comment.
Could we please hide this from users? e.g. make it package-private.
|
@trustin Thanks for your suggestions and I had updated the source code, can you help to check again? |
| * Set the {@link WriteBufferWaterMark} which is used for setting the high and low | ||
| * water mark of the write buffer. | ||
| */ | ||
| ChannelConfig setWriteBufferWaterMark(WriteBufferWaterMark writeBufferWaterMark); |
There was a problem hiding this comment.
You will need to also "override" this in SocketChannelConfig and others to return the correct type so method chaining works.
There was a problem hiding this comment.
done except SocketChannelConfig and ServerSocketChannelConfig.
There was a problem hiding this comment.
You should also do this for these both.
There was a problem hiding this comment.
never mind we can not do this as it will break the API.
remove duplicated blank line
|
@normanmaurer in short, no override new methods: ServerSocketChannelConfig and SocketChannelConfig |
remove WRITE_BUFFER_WATER_MARK from getOptions
| private volatile boolean autoClose = true; | ||
| private volatile int writeBufferHighWaterMark = 64 * 1024; | ||
| private volatile int writeBufferLowWaterMark = 32 * 1024; | ||
| private volatile WriteBufferWaterMark writeBufferWaterMark = new WriteBufferWaterMark(writeBufferLowWaterMark,writeBufferHighWaterMark); |
There was a problem hiding this comment.
@trustin seems duplicated?
but I can't remove member: writeBufferHighWaterMark and writeBufferLowWaterMark due to old methods such as setWriteBufferHighWaterMark(int) can't modify WriteBufferWaterMark except I add package visible setMethod into WriteBufferWaterMark.
And if I remove member: writeBufferWaterMark, I can't keep same style to support getOption() except I return new WriteBufferWaterMark (writeBufferLowWaterMark ,writeBufferHighWaterMark ) for every getOption() call;
so here confused me. I am not sure my current implement look good. so WDYT?
| private volatile boolean autoClose = true; | ||
| private volatile int writeBufferHighWaterMark = 64 * 1024; | ||
| private volatile int writeBufferLowWaterMark = 32 * 1024; | ||
| private volatile WriteBufferWaterMark writeBufferWaterMark = |
There was a problem hiding this comment.
@trustin seems duplicated?
but I can't remove members: writeBufferHighWaterMark and writeBufferLowWaterMark due to old methods such as setWriteBufferHighWaterMark(int) can't modify WriteBufferWaterMark except I add package visible setMethod into WriteBufferWaterMark.
And if I remove member: writeBufferWaterMark, I can't keep same style to support getOption() except I return new WriteBufferWaterMark (writeBufferLowWaterMark ,writeBufferHighWaterMark ) for every getOption() call;
but someday, we can remove members: writeBufferHighWaterMark and writeBufferLowWaterMark
after deprecated set methods such as setWriteBufferHighWaterMark be removed.
so here confused me. I am not sure if my current implement look good. so WDYT?
There was a problem hiding this comment.
I think you should remove the local members and just have package private set methods.
|
@jiafu1115 let me pick this up and finish as we are on the sprint for 4.1.0.Final :) |
|
@jiafu1115 once you addressed my last comment please also squash the commits. After that I will cherry-pick. Sorry for the delay! |
|
@jiafu1115 also please squash into one commit once ready. |
fix the issue netty#3806 Modifications: deprecated ChannelOption.WRITE_BUFFER_HIGH_WATER_MARK and ChannelOption.WRITE_BUFFER_LOW_WATER_MARK. add one new option called ChannelOption.WRITE_BUFFER_WATER_MARK. add one new class type: WriteBufferWaterMark with constructor WriteBufferWaterMark(int, int) It can support setting both low and high water mark at same time so that it can break values limited caused by default values. so the followed usage is recommended after this fix: serverBootstrap.childOption(ChannelOption.WRITE_BUFFER_WATER_MARK, new WriteBufferWaterMark(32768, 65536)); Result: after the fix, the high/low water mark values limits caused by default values are removed.
Motivation: fix the issue netty#3806 Modifications: deprecated ChannelOption.WRITE_BUFFER_HIGH_WATER_MARK and ChannelOption.WRITE_BUFFER_LOW_WATER_MARK. add one new option called ChannelOption.WRITE_BUFFER_WATER_MARK. add one new class type: WriteBufferWaterMark with constructor WriteBufferWaterMark(int, int) It can support setting both low and high water mark at same time so that it can break values limited caused by default values. so the followed usage is recommended after this fix: serverBootstrap.childOption(ChannelOption.WRITE_BUFFER_WATER_MARK, new WriteBufferWaterMark(32768, 65536)); Result: after the fix, the high/low water mark values limits caused by default values are removed.
Motivation: fix the issue netty#3806 Modifications: deprecated ChannelOption.WRITE_BUFFER_HIGH_WATER_MARK and ChannelOption.WRITE_BUFFER_LOW_WATER_MARK. add one new option called ChannelOption.WRITE_BUFFER_WATER_MARK. add one new class type: WriteBufferWaterMark with constructor WriteBufferWaterMark(int, int) It can support setting both low and high water mark at same time so that it can break values limited caused by default values. so the followed usage is recommended after this fix: serverBootstrap.childOption(ChannelOption.WRITE_BUFFER_WATER_MARK, new WriteBufferWaterMark(32768, 65536)); Result: after the fix, the high/low water mark values limits caused by default values are removed.
Motivation: Fix the issue netty#3806 Modifications: deprecated ChannelOption.WRITE_BUFFER_HIGH_WATER_MARK and ChannelOption.WRITE_BUFFER_LOW_WATER_MARK. add one new option called ChannelOption.WRITE_BUFFER_WATER_MARK. add one new class type: WriteBufferWaterMark with constructor WriteBufferWaterMark(int, int) It can support setting both low and high water mark at same time so that it can break values limited caused by default values. so the followed usage is recommended after this fix: serverBootstrap.childOption(ChannelOption.WRITE_BUFFER_WATER_MARK, new WriteBufferWaterMark(32768, 65536)); Result: after the fix, the high/low water mark values limits caused by default values are removed.
|
@normanmaurer I had completed all the code change. It is first time for me to use squash method and I an't sure whether my operation is right. The squash commit is 551ad90 |
|
@jiafu1115 I did take care of squashing for you and did some more small-adjustments for proper CAS semantics and to ensure we only need to read one volatile field. Here is the new PR which still lists you as author: |
|
@normanmaurer Thank you very much! |
Motivation:
fix the issue #3806
Modifications:
It can support setting both low and high water mark at same time so that it can break values limited caused by default values.
so the followed usage is recomment after this fix:
Result:
after the fix, the high/low water mark values limits caused by default values are removed.