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 ?

[lihuagang03]

调用场景：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.