Why Dubbo Is Unsuitable for File Transfer and How HTTP/Feign Offer Better Alternatives

In a previous project a Dubbo service wrapped the Tencent Cloud Object Storage SDK to provide a unified file‑storage API, aiming to avoid breaking changes when the third‑party SDK upgraded. Although the idea was sound, Dubbo is not appropriate for file transmission.

Dubbo cannot transmit File objects directly because it serializes Java objects; a File reference contains no file data. The only viable way is to send the raw byte array:

void sendPhoto(File photo);

void sendPhoto(byte[] photo);

Sending the whole byte[] forces the consumer to load the entire file into memory, which quickly exhausts heap space for large files. The provider suffers the same problem when decoding the request.

Single‑connection model of the Dubbo protocol aggravates the issue. All requests to a provider share one TCP connection (Netty channel). When a large payload is sent, the channel is occupied, causing other requests to queue and block, leading to timeouts and degraded throughput.

The protocol adopts this model to conserve resources: most services have few providers and many consumers, so a single long‑lived connection reduces handshake overhead and mitigates the C10K problem.

Dubbo does allow multiple connections via configuration:

<dubbo:service connections="1"/>

<dubbo:reference connections="1"/>

When multiple connections are configured, Dubbo uses a round‑robin strategy to distribute requests across them, but the underlying problem of loading whole files into memory remains.

Why HTTP is more suitable for files

HTTP can stream data: a client reads a small buffer (e.g., 4 KB) from the file and writes it to the socket repeatedly, keeping memory usage constant. The server can similarly read the incoming stream incrementally, avoiding full‑payload buffering.

Feign’s file‑upload capabilities

Feign is an HTTP client, not a full RPC framework. In a Spring Cloud environment the server is usually Tomcat, which stores multipart data on disk before processing, so the server side does not suffer from high memory usage. However, Feign’s FormEncoder builds the entire multipart body in a ByteArrayOutputStream before sending, which again loads the whole payload into memory on the client side.

class Output implements Closeable {
    ByteArrayOutputStream outputStream = new ByteArrayOutputStream();
    public Output write(byte[] bytes) { outputStream.write(bytes); return this; }
    public Output write(byte[] bytes, int offset, int length) { outputStream.write(bytes, offset, length); return this; }
    public byte[] toByteArray() { return outputStream.toByteArray(); }
}

Therefore, while Feign avoids server‑side memory pressure, the client still buffers the entire request, which can be problematic for very large files.

Practical Feign examples

interface SomeApi {
    @RequestLine("POST /send_photo")
    @Headers("Content-Type: multipart/form-data")
    void sendPhoto(@Param("is_public") Boolean isPublic, @Param("photo") File photo);

    // byte[] version
    void sendPhoto(@Param("is_public") Boolean isPublic, @Param("photo") byte[] photo);

    // FormData version
    void sendPhoto(@Param("is_public") Boolean isPublic, @Param("photo") FormData photo);

    // MultipartFile version (Spring)
    void sendPhoto(@RequestPart(value = "photo") MultipartFile photo);

    // POJO aggregation
    void sendPhoto(MyPojo pojo);
}

class MyPojo {
    @FormProperty("is_public") Boolean isPublic;
    File photo;
}

In summary, Dubbo is designed for small‑size RPC payloads (default limit 8 MB) and is not a good fit for file uploads. For large files, prefer direct client‑to‑server streaming over HTTP, or use specialized file‑transfer solutions that avoid loading the entire content into memory.