camel-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Willem Jiang <>
Subject Re: Asynchronous socket read-write via camel
Date Wed, 22 Feb 2012 06:54:06 GMT

I don't think current camel netty component supports the way that you 

If you are happy with other camel component, you may need to think 
about use netty directly.

And using the camel context inside the netty, so you can managed the 
socket yourself with the help the two In-only routes.

On Wed Feb 22 07:15:18 2012, 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

Blog: (English) (Chinese)
Twitter: willemjiang 
Weibo: willemjiang 

View raw message