camel-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Claus Ibsen <>
Subject Re: Asynchronous socket read-write via camel
Date Wed, 22 Feb 2012 10:39:13 GMT
There is a person working on camel-mina2 component to enhance it to
support async req/reply with correlation.
eg what seems like what you are looking for. There is some JIRA
tickets about this.

The current behavior for req/reply over netty/mina/mina2 is a 1:1
message solution.

On Wed, Feb 22, 2012 at 12:15 AM, <> wrote:
> Hi,
> I hope that someone can give me some advice. We've looked through the
> documentation and samples but cannot find an exact match for our use case.
> What we need to do is to listen on a socket and send data to the same
> socket. This could be us satisfying the Request-Response Message Exchange
> Pattern or could consist of (sending or receiving) asynchronous status
> message updates, where no response is required.
> There could be any number of requests coming in and an unrelated number of
> messages going out. The system on the other end of the socket will use data
> in the socket streams to correlate requests with responses - so we do not
> have to send reponses in the same order as requests.
> We know how this could be done in low level socket programming. However
> we're tying to use Camel for all our integration, so if we can use Camel
> components we will.
> We have tried a couple of things. The first was to have a route where we
> consume from a socket via a netty consumer, using inOut configuration.
> Downstream we have a JMS queue where we put data and another where we read
> responses to return as the response to the socket.
> This works as long as there is an exact Request-Response pattern. However,
> because there may be un correlated status messages, this does not meet all
> our needs.
> We have thought about two asynchronous routes - one consuming from a socket
> and writing to a queue, and another reading from the queue and writing to
> the socket. This has the benefit of not tying us to just request-response.
> However, the first socket endpoint to startup binds to the socket, and the
> second gets the connection refused. The requirement is that the same socket
> is used for reading and writing.
> I'm sure someone else must have had to do this sort of thing in Camel
> before, so we are just missing something. What can we do to meet our
> requirements with Camel socket components (we use Netty but if another
> component works we're happy with that.)? Do we try to share the endpoint
> between the routes? Can we do this, and if so would it solve the problem of
> connection refused?
> --
> View this message in context:
> Sent from the Camel - Users mailing list archive at

Claus Ibsen
Twitter: davsclaus, fusenews
Author of Camel in Action:

View raw message