dubbo 2.6.3 is not compatible with dubbo >= 2.5.9

[jasonjoo2010]

• I have searched the issues of this repository and believe that this is not a duplicate.
• I have checked the FAQ of this repository and believe that this is not a duplicate.

Environment

• Dubbo version: 2.5.9~2.5.10
• Operating System version: any
• Java version: any

Step to reproduce this issue

response with attachments is a new feature in release 2.6.3.

but its compatible versions are set to ![2.0.10 ~ 2.6.2] while the "ProtocolVersion" had bean changed to 2.0.1 (implementation version) and 2.0.0 (specification version).

the priority of "implementation version" is greater than other in Version.getVersion.

this will cause dubbo rpc request failing from >2.5.9 to 2.6.3.

So is that a good idea to upgrade the lowest protocol version of attachment-feature to 2.0.2?

it's a big problem

Expected Result

compatible

Actual Result

fail

[diecui1202]

hi, could you please provider a demo for us to reproduce this problem?

[jasonjoo2010]

You can switch the consumer's dubbo to 2.5.9 or 2.5.10 and make rpc calling to provider which dubbo version is 2.6.3, it will fail.

Caused by: com.alibaba.dubbo.remoting.RemotingException: java.io.IOException: Unknown result flag, expect '0' '1' '2', get 4
java.io.IOException: Unknown result flag, expect '0' '1' '2', get 4
	at com.alibaba.dubbo.rpc.protocol.dubbo.DecodeableRpcResult.decode(DecodeableRpcResult.java:98)
	at com.alibaba.dubbo.rpc.protocol.dubbo.DecodeableRpcResult.decode(DecodeableRpcResult.java:106)
	at com.alibaba.dubbo.rpc.protocol.dubbo.DubboCodec.decodeBody(DubboCodec.java:88)
	at com.alibaba.dubbo.remoting.exchange.codec.ExchangeCodec.decode(ExchangeCodec.java:120)
	at com.alibaba.dubbo.remoting.exchange.codec.ExchangeCodec.decode(ExchangeCodec.java:81)
	at com.alibaba.dubbo.rpc.protocol.dubbo.DubboCountCodec.decode(DubboCountCodec.java:44)
	at com.alibaba.dubbo.remoting.transport.netty.NettyCodecAdapter$InternalDecoder.messageReceived(NettyCodecAdapter.java:133)
	at org.jboss.netty.channel.SimpleChannelUpstreamHandler.handleUpstream(SimpleChannelUpstreamHandler.java:70)
	at org.jboss.netty.channel.DefaultChannelPipeline.sendUpstream(DefaultChannelPipeline.java:564)
	at org.jboss.netty.channel.DefaultChannelPipeline.sendUpstream(DefaultChannelPipeline.java:559)
	at org.jboss.netty.channel.Channels.fireMessageReceived(Channels.java:268)
	at org.jboss.netty.channel.Channels.fireMessageReceived(Channels.java:255)
	at org.jboss.netty.channel.socket.nio.NioWorker.read(NioWorker.java:88)
	at org.jboss.netty.channel.socket.nio.AbstractNioWorker.process(AbstractNioWorker.java:109)
	at org.jboss.netty.channel.socket.nio.AbstractNioSelector.run(AbstractNioSelector.java:312)
	at org.jboss.netty.channel.socket.nio.AbstractNioWorker.run(AbstractNioWorker.java:90)
	at org.jboss.netty.channel.socket.nio.NioWorker.run(NioWorker.java:178)
	at org.jboss.netty.util.ThreadRenamingRunnable.run(ThreadRenamingRunnable.java:108)
	at org.jboss.netty.util.internal.DeadLockProofWorker$1.run(DeadLockProofWorker.java:42)
	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
	at java.lang.Thread.run(Thread.java:745)

	at com.alibaba.dubbo.remoting.exchange.support.DefaultFuture.returnFromResponse(DefaultFuture.java:218)
	at com.alibaba.dubbo.remoting.exchange.support.DefaultFuture.get(DefaultFuture.java:137)
	at com.alibaba.dubbo.remoting.exchange.support.DefaultFuture.get(DefaultFuture.java:111)
	at com.alibaba.dubbo.rpc.protocol.dubbo.DubboInvoker.doInvoke(DubboInvoker.java:95)
	at com.alibaba.dubbo.rpc.protocol.AbstractInvoker.invoke(AbstractInvoker.java:142)
	at com.alibaba.dubbo.monitor.support.MonitorFilter.invoke(MonitorFilter.java:74)
	at com.alibaba.dubbo.rpc.protocol.ProtocolFilterWrapper$1.invoke(ProtocolFilterWrapper.java:68)
	at com.alibaba.dubbo.rpc.protocol.dubbo.filter.FutureFilter.invoke(FutureFilter.java:53)
	at com.alibaba.dubbo.rpc.protocol.ProtocolFilterWrapper$1.invoke(ProtocolFilterWrapper.java:68)
	at com.alibaba.dubbo.rpc.filter.ConsumerContextFilter.invoke(ConsumerContextFilter.java:47)
	at com.alibaba.dubbo.rpc.protocol.ProtocolFilterWrapper$1.invoke(ProtocolFilterWrapper.java:68)
	at com.alibaba.dubbo.rpc.listener.ListenerInvokerWrapper.invoke(ListenerInvokerWrapper.java:73)
	at com.alibaba.dubbo.rpc.protocol.InvokerWrapper.invoke(InvokerWrapper.java:52)
	at com.alibaba.dubbo.rpc.cluster.support.FailfastClusterInvoker.doInvoke(FailfastClusterInvoker.java:47)
	... 54 more

[diecui1202]

@jasonjoo2010 I do have reproduce it. Thanks.

Now I suggest cancel the release for 2.6.3, then fix it, and start a new release.

[jasonjoo2010]

@diecui1202

I have solved it in staging environment by upgrade the protocol to 2.0.2(20002).

I will do more test and upgrade some projects in production to verify wether there is any other problem.

I don't know the difference between protocol versions exactly(eg. attachments feature) and it's better to have a change log.

Thank you for response

[chickenlj]

Hi @jasonjoo2010 , would you mind to send a PR to solve this compatible problem?

[jasonjoo2010]

@chickenlj patch to which branch?

2.6.3-release/2.6.x/master ?

[bert82503]

调用场景：2.5.8-consumer -> 2.6.5-provider
Dubbo版本明明是2.6.5，结果URL里却是dubbo协议版本(dubbo=2.0.2)，和先前实现逻辑不一样。
请问这样调整后dubbo协议是否完全向前兼容？能否做到增量平滑升级？

[lastboy1228]

调用场景：2.5.8-consumer -> 2.6.5-provider
Dubbo版本明明是2.6.5，结果URL里却是dubbo协议版本(dubbo=2.0.2)，和先前实现逻辑不一样。
请问这样调整后是否向前兼容？能否做到增量平滑升级？

The client always registried itself as dubbo=2.0.2, from version 2.6.3 to version 2.6.7.

[jasonjoo2010]

调用场景：2.5.8-consumer -> 2.6.5-provider
Dubbo版本明明是2.6.5，结果URL里却是dubbo协议版本(dubbo=2.0.2)，和先前实现逻辑不一样。
请问这样调整后是否向前兼容？能否做到增量平滑升级？

And more, 2.0.2 is protocol version, while 2.6.5 is implementation version. They are not the same.

dubbo= in url is exactly the protocol version and it indeed is backward compatible.

[bert82503]

调用场景：2.5.8-consumer -> 2.6.5-provider
Dubbo版本明明是2.6.5，结果URL里却是dubbo协议版本(dubbo=2.0.2)，和先前实现逻辑不一样。
请问这样调整后是否向前兼容？能否做到增量平滑升级？

And more, 2.0.2 is protocol version, while 2.6.5 is implementation version. They are not the same.

dubbo= in url is exactly the protocol version and it indeed is backward compatible.

@jasonjoo2010 @lastboy1228
Thanks for you answer, but before 2.6.0 version, dubbo= in url is implementation version, not the protocol version. As in fact, from 2.5.10 to 2.6.2, dubbo protocol is not backward compatible, our colleagues have encountered this problem. I'm responsible for the dubbo in our compony. 😃

[jasonjoo2010]

@jasonjoo2010 @lastboy1228
Thanks for you answer, but before 2.6.0 version, dubbo= in url is implementation version, not the protocol version. As in fact, from 2.5.10 to 2.6.2, dubbo protocol is not backward compatible, our colleagues have encountered this problem. I'm responsible for the dubbo in our compony. 😃

Yes indeed.
The implementation version in previous dubbo will be treated as 2.0.1 automatically. So invocation should not be affected.

Do you suffer some kinds of failure or just use the value in dubbo= to do other things?

[jasonjoo2010]

@jasonjoo2010 @lastboy1228
Thanks for you answer, but before 2.6.0 version, dubbo= in url is implementation version, not the protocol version. As in fact, from 2.5.10 to 2.6.2, dubbo protocol is not backward compatible, our colleagues have encountered this problem. I'm responsible for the dubbo in our compony. 😃

Oh I am sorry I just notice the version you mentioned is 2.5.10. The two releases (2.5.9, 2.5.10) may be the issued version so they are not recommended to use in production. (It can be downgrade to 2.5.8)

And because there are also some issue in 2.6.x it's recommended to upgrade to 2.7.x ASAP.