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

The author, a senior architect, describes a past Dubbo service that encapsulated Tencent Cloud Object Storage SDK to unify third‑party SDK usage, but points out that using Dubbo for file transfer is fundamentally flawed.

Dubbo cannot directly transmit File objects because it only serializes objects; therefore the file must be sent as a byte array:

void sendPhoto(File photo);

void sendPhoto(byte[] photo);

This approach forces the consumer to load the entire file into memory, and the provider must also read the whole byte[] into memory, leading to excessive memory consumption.

Additionally, Dubbo’s default protocol uses a single TCP connection per provider. All requests share this connection, and Netty queues write events to ensure thread safety. When a large file message occupies the channel, other requests are blocked, causing severe latency and potential time‑outs.

The single‑connection design is chosen to conserve resources, as most services have few providers and many consumers. Dubbo documentation cites this as a way to avoid overwhelming providers and to mitigate the C10K problem.

Dubbo can be configured for multiple connections, e.g.:

<dubbo:service connections="1"/>
<dubbo:reference connections="1"/>

but even with multiple connections, requests are distributed via a round‑robin mechanism, not a one‑to‑one mapping.

In contrast, HTTP can stream files by reading and sending small buffers (e.g., 4 KB) without loading the entire file into memory, both on the client and server side.

Feign, as an HTTP client, can upload files using various method signatures:

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

  // other overloads with byte[] or FormData, MultipartFile, etc.
}

Feign relies on the feign-form module, which encodes the request into a ByteArrayOutputStream. This means the entire payload is still held in memory before being sent, re‑introducing the high‑memory‑usage problem on the client side, although the server can stream the data.

Therefore, Dubbo is best suited for small payloads (default limit 8 MB) and not for large file uploads. For file‑transfer scenarios, direct client‑to‑server streaming or dedicated HTTP endpoints are recommended.