Skip to content

Fix the issue netty#3806 in 4.1#4858

Closed
jiafu1115 wants to merge 59 commits into
netty:4.1from
jiafu1115:patch-11
Closed

Fix the issue netty#3806 in 4.1#4858
jiafu1115 wants to merge 59 commits into
netty:4.1from
jiafu1115:patch-11

Conversation

@jiafu1115
Copy link
Copy Markdown
Contributor

Motivation:

fix the issue #3806

Modifications:

  1. deprecated ChannelOption.WRITE_BUFFER_HIGH_WATER_MARK and ChannelOption.WRITE_BUFFER_LOW_WATER_MARK.
  2. add one new option called ChannelOption.WRITE_BUFFER_WATER_MARK.
  3. 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 recomment 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.

fix sonar reported issue "Add the missing @deprecated annotation"
@jiafu1115
Copy link
Copy Markdown
Contributor Author

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
@trustin
Copy link
Copy Markdown
Member

trustin commented Feb 10, 2016

@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() {
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

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

Could we please hide this from users? e.g. make it package-private.

@jiafu1115
Copy link
Copy Markdown
Contributor Author

@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);
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

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

You will need to also "override" this in SocketChannelConfig and others to return the correct type so method chaining works.

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

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

done except SocketChannelConfig and ServerSocketChannelConfig.

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

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

You should also do this for these both.

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

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

never mind we can not do this as it will break the API.

@jiafu1115
Copy link
Copy Markdown
Contributor Author

@normanmaurer
I had override new method into all subclass if existed old methods such as setWriteBufferHighWaterMark(int) in them. Thanks for checking them.
What's more, I see the SocketChannelConfig is the interface extends ChannelConfig and hadn't override the old methods such as setWriteBufferHighWaterMark(int). maybe it is late discovery bug for forget to override setWriteBufferWaterMark in SocketChannelConfig to support chaining.
WDYT?

in short, no override new methods: ServerSocketChannelConfig and SocketChannelConfig
due to they hadn't never override setWriteBufferHighWaterMark(int) and setWriteBufferLowWaterMark(int). I think it is issue, can you make sure of it or is there any special reason for it?

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);
Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

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

@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 =
Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

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

@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?

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

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

I think you should remove the local members and just have package private set methods.

@normanmaurer
Copy link
Copy Markdown
Member

@jiafu1115 let me pick this up and finish as we are on the sprint for 4.1.0.Final :)

@normanmaurer normanmaurer self-assigned this Mar 24, 2016
@normanmaurer
Copy link
Copy Markdown
Member

@jiafu1115 once you addressed my last comment please also squash the commits. After that I will cherry-pick.

Sorry for the delay!

@normanmaurer normanmaurer added this to the 4.1.0.Final milestone Mar 24, 2016
@normanmaurer
Copy link
Copy Markdown
Member

@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.
@jiafu1115
Copy link
Copy Markdown
Contributor Author

@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
can you help to review it?
3ks.

@normanmaurer
Copy link
Copy Markdown
Member

@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:
#5060

@jiafu1115
Copy link
Copy Markdown
Contributor Author

@normanmaurer Thank you very much!

@trustin trustin modified the milestones: 4.1.0.CR6, 4.1.0.Final Apr 2, 2016
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants