Hi Tien My suggestion is that we should not slack on it when we use tradition REQEUST-RESPONSE model.
1. Stream Object couldn't be transferred DUBBO use an embedded version of hessian which is the project "dubbo-hessian-lite". If you use a unserializable parameter in your interface then you will get a null value. 2. Several Serializations integrated into Dubbo When we use model of REQUEST-RESPONSE we must consider how to generate the complete request for a correct response. So how to give stream-like (not stream-style) requests the ability of keeping working when response is generating is a big task to solve. 3. Make Everything in the AIR is difficult I know your purpose is to let things in the air to simplify the job or improve the performance. But even load balancer or container like tomcat will create temporarily file on disk (There is a threshold of file size) to hold it before proxying the request. So if you can make things in the air it depends on your scenario and consideration of that. My suggestion is: It may has no general solution. You should design it according your actual cases. For files small enough considering byte[]; If they are large consider to find a sharing place (Distributed storage / NFS), or split them into pieces to consume them. best regards, Jason > On Jul 23, 2019, at 14:56, [email protected] wrote: > > Hi Jason, > > I just learnt that Hessian protocol with Hessian2 support InputStream > serialization. > Have you ever played with this protocol for large file transfer? > > Best > Tien Dat > > On 2019/07/19 17:58:56, Jason Joo <[email protected]> wrote: >> Hi, Tien >> >> Questions on the road map it's better to turn to @lan luo. He will get you >> know that I think. And I should say that stream type is quite different to >> streaming style api. >> >> best regards, >> >> Jason >> >>> On Jul 19, 2019, at 15:25, [email protected] wrote: >>> >>> Hi Jason, >>> >>> Thanks for your advice. >>> These solutions appear to be the most relevant for our usecase, for now. >>> >>> We just wonder also if it will be addressed in upcoming version of Dubbo, >>> to support InputStream in the public APIs? Since we believe that >>> InputStream itself is a complete and efficient interface for transferring >>> large series of data, and we don't think that one can make it equivalent, >>> let alone makeing it better by re-implementing the functionality of the >>> InputStream (splitting the large files and transfer piece by piece) >>> >>> As far as we know, Dubbo version 3.x will come with reactive stream >>> supported. >>> So whether the InputStream can be also supported in this version? >>> >>> Best >>> Tien Dat >>> >>> On 2019/07/19 01:07:51, Jason Joo <[email protected]> wrote: >>>> Hi, Tien >>>> >>>> You can only use serializable types as parameters in API definition and >>>> maybe you cannot do that. >>>> >>>> You can choose an alternative design like: >>>> 1. use byte[] (When the size of file is small) (If it's large or >>>> undetermined splitting it into pieces will also work) >>>> 2. use a place to store temporarily and then use the address (like url) to >>>> identify it. >>>> >>>> best regards, >>>> >>>> Jason >>>> >>>>> On Jul 18, 2019, at 19:18, [email protected] wrote: >>>>> >>>>> Dear experts >>>>> >>>>> We are newbie with Dubbo. >>>>> What we are trying to do is providing a public API that supports >>>>> uploading the content of a file. >>>>> As a result, the API method has a parameter as FileInputStream. >>>>> >>>>> However, the dubbo protocol does not support Streaming. >>>>> >>>>> Do you know how we can implement our API with Dubbo? >>>>> >>>>> Best >>>>> Tien Dat >>>> >>>> >> >>
