camel-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Cleocleo <>
Subject Re: Camel Load Balancer EIP with TCP Endpoints
Date Wed, 30 Sep 2015 03:10:54 GMT
Are we talking about long or short lived TCP connections? E.g does the client
open a connection and continue to send/receive messages over a long period
of time (how long?) or does the client open a connection, send the message,
and then close the connection soon after getting a response/acknowledgment
back from a server?

Can't really speak on the topic of long lived TCP connections, but here are
some questions and patterns that might help if you're dealing with short
lived connections:

First, is the client-server communication synchronous or asynchronous in
nature? (e.g does the client wait for the server to do some processing of
the message before getting a response back / closing the connection, or does
the client not need to wait?)

If it's asynchronous, a common pattern would be to use a queue in between
the producer(s) and the consumer(s) handling the message. Could be
implemented as threads using an in-memory queue all the way to separate
physical servers depending on a queue (e.g. ActiveMQ, RabbitMQ, SQS, etc).
Really depends on your needs.

If it's synchronous, you wouldn't use the queuing pattern - load balancer
would be more appropriate. Again, there are many ways to implement this.

Since your sample code is using seda, you're heading down the asynchronous
path. Overall, your sample looks a little strange. Here's what's happening:

Your TCP message gets put onto a queue (and the TCP connection is closed).
You then have 10 consumers consuming those messages sending messages to 1 of
4 different queues using a load balancer, and then 10 consumers per
load-balanced queue consuming messages and sending the message to a TCP
endpoint... I can't imagine that's what you want to do :)

Can you provide some more details on the sync/async nature of this
communication? We can start there, and then we can talk about how distribute
(or not distribute) the message consumers based on your needs, and how camel
might fit into your solution.


View this message in context:
Sent from the Camel - Users mailing list archive at

View raw message