okay. just issue my problem to https://github.com/apache/incubator-dubbo/issues/1967
------------------ ???????? ------------------ ??????: "Ian Luo"<[email protected]>; ????????: 2018??6??20??(??????) ????10:41 ??????: "dev"<[email protected]>; ????: Re: ?????????????????????????????? header ?????? serialID Would you mind to fire one issue to track whether to ignore serialization ID for heartbeat message? I think it's worth it. On Tue, Jun 19, 2018 at 3:55 PM ???????????? <[email protected]> wrote: > To Lan: > > > Thank you. I agree with what you said. > > > Whether ignoring the serialization ID or not, it is up to your committer's > choice. Wait for your further decision. > > > > > > > > ------------------ ???????? ------------------ > ??????: "Ian Luo"<[email protected]>; > ????????: 2018??6??19??(??????) ????3:28 > ??????: "dev"<[email protected]>; > > ????: Re: ?????????????????????????????? header ?????? serialID > > > > Let's use dubbo protocol [1] to discuss. > > When you refer 'serial ID' here, do you mean serialization ID in protocol > from 16 bit to 20 bit? If this is the case, I am afraid I cannot agree with > you, since serialization ID between 16-bit and 20-bit is used to indicate > how the data should be deserialized, which has the possible values like > hessian2 (2), java (3), kryo (8) and so on. In fact, Dubbo reserves 5 bits > for the different serialization options. > > But for heartbeat, it's kinda event (which is decided by bit 21) instead of > serialization type (bit 16 - bit 20). > > I agree that it is reasonable to ignore serialization ID when dubbo finds > the message is a heartbeat, but it's based on the fact that heartbeat is > the only one event type implemented so far. Heartbeat is an event with no > body attached, but in the future it is possible to have other event type > which may have body, then it starts to make sense to have the serialization > ID defined in an event message. > > Regards, > -Ian. > > 1. http://dubbo.apache.org/books/dubbo-dev-book/implementation.html > > On Tue, Jun 19, 2018 at 12:09 PM ???????????? <[email protected]> wrote: > > > Thank you for your reply. At least, the heartbeat packet serial ID does > > not conflict with the logic packet serial ID. What my suggestion is the > > logic packet should filter the serial ID including [1, 3, 4, 5, 6, 7] > while > > the heartbeat packet should not filter the serial ID array [1, 3, 4, 5, > 6, > > 7]. Because the serial ID array [1, 3, 4, 5, 6, 7] is logic instance > > serialization ID while it can not be the the heartbeat instance > > serialization ID at the same time. > > > > > > For example, if the heartbeat packet serialization ID is 8, the dubbo > > heartbeat handle function just need to filter 8. It need not care about > > [1, 3, 4, 5, 6, 7]. > > > > > > > > > > ------------------ ???????? ------------------ > > ??????: "Ian Luo"<[email protected]>; > > ????????: 2018??6??15??(??????) ????2:05 > > ??????: "dev"<[email protected]>; > > > > ????: Re: ?????????????????????????????? header ?????? serialID > > > > > > > > The original design allows heartbeat packet to have data included, though > > the current implementation is in fact an empty packet. You can take a > look > > at com.alibaba.dubbo.remoting.exchange.Response#HEARTBEAT_EVENT, which is > > set to null right now. > > > > If in the future a valid data is required in heartbeat packet, then the > > current logic for serialID will be necessary. I'd like to listen to > others' > > comments before we decide either to ignore the check or keep the current > > design. > > > > -Ian. > > > > On Thu, Jun 14, 2018 at 9:44 PM ???????????? <[email protected]> wrote: > > > > > Dr All: > > > ?????????? dubbo ??????????hessian2????go?????????????????????????? > > > > > https://github.com/alexstocks/go-practice/blob/master/hessian/main.go > > > > > > > > > ?????????????????????????????????????????? > > > > > > > > > ????????????????????serialID??0????????????????31?????? serialID > > > ???? [1, 3, 4, 5, 6, 7] > > > ?????????????????????????? > > > > > > > > > 2018-06-14 14:50:04,598 [New I/O server worker #1-1] WARN > > > alibaba.dubbo.rpc.protocol.dubbo.DubboCodec (DubboCodec.java:140) - > > > [DUBBO] Decode request failed: Flag error, expect > > > OBJECT_NULL|OBJECT_DUMMY|OBJECT_DESC|OBJECT_DESC_ID, get 78, dubbo > > version: > > > 2.5.4, current host: 127.0.0.1 > > > java.io.IOException: Flag error, expect > > > OBJECT_NULL|OBJECT_DUMMY|OBJECT_DESC|OBJECT_DESC_ID, get 78 > > > at > > > > > > com.alibaba.dubbo.common.serialize.support.dubbo.GenericObjectInput.readObject(GenericObjectInput.java:79) > > > at > > > > > > com.alibaba.dubbo.remoting.exchange.codec.ExchangeCodec.decodeHeartbeatData(ExchangeCodec.java:381) > > > at > > > > > > com.alibaba.dubbo.rpc.protocol.dubbo.DubboCodec.decodeBody(DubboCodec.java:121) > > > at > > > > > > com.alibaba.dubbo.remoting.exchange.codec.ExchangeCodec.decode(ExchangeCodec.java:118) > > > at > > > > > > com.alibaba.dubbo.remoting.exchange.codec.ExchangeCodec.decode(ExchangeCodec.java:79) > > > at > > > > > > com.alibaba.dubbo.rpc.protocol.dubbo.DubboCountCodec.decode(DubboCountCodec.java:46) > > > at > > > > > > com.alibaba.dubbo.remoting.transport.netty.NettyCodecAdapter$InternalDecoder.messageReceived(NettyCodecAdapter.java:134) > > > at > > > > > > org.jboss.netty.channel.SimpleChannelUpstreamHandler.handleUpstream(SimpleChannelUpstreamHandler.java:80) > > > 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:274) > > > at > > > org.jboss.netty.channel.Channels.fireMessageReceived(Channels.java:261) > > > at > > org.jboss.netty.channel.socket.nio.NioWorker.read(NioWorker.java:349) > > > at > > > > > > org.jboss.netty.channel.socket.nio.NioWorker.processSelectedKeys(NioWorker.java:280) > > > at > org.jboss.netty.channel.socket.nio.NioWorker.run(NioWorker.java:200) > > > at > > > > > > org.jboss.netty.util.ThreadRenamingRunnable.run(ThreadRenamingRunnable.java:108) > > > at > > > > > > org.jboss.netty.util.internal.DeadLockProofWorker$1.run(DeadLockProofWorker.java:44) > > > at > > > > > > java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) > > > at > > > > > > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) > > > at java.lang.Thread.run(Thread.java:748) > > > 2018-06-14 14:50:05,599 [New I/O server worker #1-1] WARN > > > com.alibaba.dubbo.remoting.transport.AbstractServer > > > (AbstractServer.java:199) - [DUBBO] All clients has discontected from > / > > > 127.0.0.1:20000. You can graceful shutdown now., dubbo version: 2.5.4, > > > current host: 127.0.0.1 > > > > > > > > > > > > ?????? dubbo commiter ?????????????????? ID ????????????????ID???? > > > > > > https://github.com/apache/incubator-dubbo/blob/2.5.x/dubbo-common/src/main/java/com/alibaba/dubbo/common/serialize/support/json/FastJsonSerialization.java > > > ?? > > > > > > > > > ???????????????????????? okay > > > ?????????????????????????????????????????????????????????????????? header > > > ?????? > > > serialID?????????????????? > > > > > > > > > > > > > > > ????????????????????????????????????serialID??????????????????????????????????????????????????????????????????????????????????????????????????
