You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@camel.apache.org by "winks@misys.com" <wi...@misys.com> on 2012/02/22 00:15:18 UTC
Asynchronous socket read-write via camel
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.
Re: Asynchronous socket read-write via camel
Posted by Claus Ibsen <cl...@gmail.com>.
Hi Chad
Thanks for sharing this with us, and if / when you get the time to
help out with the camel-mina2 component.
I have said it many times, we love contributions at ASF.
On Wed, Oct 10, 2012 at 2:32 PM, Chad Beaulac <ca...@gmail.com> wrote:
> Somebody asked me about this so I'm sharing my response with the list. The question was, how do I do this now if the functionality doesn't exist in camel-mina2 yet.
>
> Response:
> I've been working, off and on, to get this functionality into camel-mina2. Unfortunately, my schedule with customers keeps putting this on the back burner.
>
> My projects have asynchronous and synchronous TCP/UDP I/O between Java and C++ components. I wrote a Google Protocol Buffers for mina2. I ported that codec to C++ also.
>
> Synchronous Comms Approach
> 1) Messages are defined in Google Protocol Buffers (GBP) using extensions
> 2) camel-mina2 endpoints are used for Java subsystems.
> 3) If we don't expect a reply for a given message, we set route to asynch. If reply can vary, we always send a reply and just send an empty GPB message for handshaking sometimes
>
> Asynchronous Comms Approach
> 1) Messages are defined in Google Protocol Buffers (GBP) using extensions
> 2) mina2 socket servers and clients are implemented directly using Mina version 2.
> 3) C++ side is same in both approaches
>
> Chad Beaulac
> Objective Solutions, Inc.
> www.objectivesolutions.com
> chad@objectivesolutions.com
>
>
> On Aug 18, 2012, at 9:21 AM, Chad Beaulac wrote:
>
>> I'm working on this now. I have some unit tests written and working. I hope
>> to post a patch for review soon.
>> The current approach allows you to attach a Mina IoHandler to a Mina2
>> endpoint. The IoHandler receives "n" messages from the consumer and can send
>> "m" responses.
>>
>> -Chad
>>
>>
>>
>>
>> --
>> View this message in context: http://camel.465427.n5.nabble.com/Asynchronous-socket-read-write-via-camel-tp5503650p5717650.html
>> Sent from the Camel - Users mailing list archive at Nabble.com.
>
>
>
>
>
>
>
--
Claus Ibsen
-----------------
Red Hat, Inc.
FuseSource is now part of Red Hat
Email: cibsen@redhat.com
Web: http://fusesource.com
Twitter: davsclaus
Blog: http://davsclaus.com
Author of Camel in Action: http://www.manning.com/ibsen
Re: Asynchronous socket read-write via camel
Posted by Chad Beaulac <ca...@gmail.com>.
Somebody asked me about this so I'm sharing my response with the list. The question was, how do I do this now if the functionality doesn't exist in camel-mina2 yet.
Response:
I've been working, off and on, to get this functionality into camel-mina2. Unfortunately, my schedule with customers keeps putting this on the back burner.
My projects have asynchronous and synchronous TCP/UDP I/O between Java and C++ components. I wrote a Google Protocol Buffers for mina2. I ported that codec to C++ also.
Synchronous Comms Approach
1) Messages are defined in Google Protocol Buffers (GBP) using extensions
2) camel-mina2 endpoints are used for Java subsystems.
3) If we don't expect a reply for a given message, we set route to asynch. If reply can vary, we always send a reply and just send an empty GPB message for handshaking sometimes
Asynchronous Comms Approach
1) Messages are defined in Google Protocol Buffers (GBP) using extensions
2) mina2 socket servers and clients are implemented directly using Mina version 2.
3) C++ side is same in both approaches
Chad Beaulac
Objective Solutions, Inc.
www.objectivesolutions.com
chad@objectivesolutions.com
On Aug 18, 2012, at 9:21 AM, Chad Beaulac wrote:
> I'm working on this now. I have some unit tests written and working. I hope
> to post a patch for review soon.
> The current approach allows you to attach a Mina IoHandler to a Mina2
> endpoint. The IoHandler receives "n" messages from the consumer and can send
> "m" responses.
>
> -Chad
>
>
>
>
> --
> View this message in context: http://camel.465427.n5.nabble.com/Asynchronous-socket-read-write-via-camel-tp5503650p5717650.html
> Sent from the Camel - Users mailing list archive at Nabble.com.
Re: Asynchronous socket read-write via camel
Posted by Chad Beaulac <ca...@gmail.com>.
I'm working on this now. I have some unit tests written and working. I hope
to post a patch for review soon.
The current approach allows you to attach a Mina IoHandler to a Mina2
endpoint. The IoHandler receives "n" messages from the consumer and can send
"m" responses.
-Chad
--
View this message in context: http://camel.465427.n5.nabble.com/Asynchronous-socket-read-write-via-camel-tp5503650p5717650.html
Sent from the Camel - Users mailing list archive at Nabble.com.
Re: Asynchronous socket read-write via camel
Posted by winks <wi...@misys.com>.
OK, thank you both.
--
View this message in context: http://camel.465427.n5.nabble.com/Asynchronous-socket-read-write-via-camel-tp5503650p5504809.html
Sent from the Camel - Users mailing list archive at Nabble.com.
Re: Asynchronous socket read-write via camel
Posted by Claus Ibsen <cl...@gmail.com>.
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, winks@misys.com <wi...@misys.com> 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: cibsen@fusesource.com
Web: http://fusesource.com
Twitter: davsclaus, fusenews
Blog: http://davsclaus.blogspot.com/
Author of Camel in Action: http://www.manning.com/ibsen/
Re: Asynchronous socket read-write via camel
Posted by Willem Jiang <wi...@gmail.com>.
Hi，
I don't think current camel netty component supports the way that you
want.
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, winks@misys.com 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.
>
--
Willem
----------------------------------
FuseSource
Web: http://www.fusesource.com
Blog: http://willemjiang.blogspot.com (English)
http://jnn.javaeye.com (Chinese)
Twitter: willemjiang
Weibo: willemjiang