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, [email protected] <[email protected]> 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: > http://camel.465427.n5.nabble.com/Asynchronous-socket-read-write-via-camel-tp5503650p5503650.html > Sent from the Camel - Users mailing list archive at Nabble.com. -- Claus Ibsen ----------------- FuseSource Email: [email protected] Web: http://fusesource.com Twitter: davsclaus, fusenews Blog: http://davsclaus.blogspot.com/ Author of Camel in Action: http://www.manning.com/ibsen/
