[SPARK-13652][Core]Copy ByteBuffer in sendRpcSync as it will be recycled

[zsxwing]

What changes were proposed in this pull request?

sendRpcSync should copy the response content because the underlying buffer will be recycled and reused.

How was this patch tested?

Jenkins unit tests.

[zsxwing]

cc @vanzin
Also cc @yaooqinn as Sasl uses this method and I guess this may be the cause you reported in #9987 (comment)

[srowen]

Does this situation arise when there aren't multiple threads accessing one stream? I had thought the docs were prohibiting this so that the defensive copy wasn't needed

[zsxwing]

Does this situation arise when there aren't multiple threads accessing one stream? I had thought the docs were prohibiting this so that the defensive copy wasn't needed

This is not related to multiple threads accessing one stream. The caller of sendRpcSync is usually in some user thread and onSuccess is called in netty's thread pool. They are not in the same thread.

However, the doc is pretty confusing. I think it wants to say that if using different clients to send messages, the responses may be out-of-order.

[vanzin]

LGTM.

[SparkQA]

Test build #52411 has finished for PR 11499 at commit 7199237.

• This patch fails Spark unit tests.
• This patch merges cleanly.
• This patch adds no public classes.

[zsxwing]

It's a known flaky test. Retest this please

[SparkQA]

Test build #52426 has finished for PR 11499 at commit 7199237.

• This patch fails Spark unit tests.
• This patch merges cleanly.
• This patch adds no public classes.

[zsxwing]

retest this please

[SparkQA]

Test build #52445 has finished for PR 11499 at commit 7199237.

• This patch passes all tests.
• This patch merges cleanly.
• This patch adds no public classes.

[zsxwing]

Merging to master and 1.6

[zsxwing]

@yaooqinn could you also test this patch using your application to see if this one resolves your problem? Thanks!

[viper-kun]

@zsxwing It is ok.

[yaooqinn]

LGTM，Thanks！