FAQ
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.

Search Discussions

  • Willem Jiang at Feb 22, 2012 at 6:55 am
    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
  • Claus Ibsen at Feb 22, 2012 at 10:40 am
    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 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/
  • Winks at Feb 22, 2012 at 11:01 am
    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.
  • Chad Beaulac at Aug 18, 2012 at 1:21 pm
    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.
  • Chad Beaulac at Oct 10, 2012 at 12:33 pm
    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 at Oct 13, 2012 at 8:41 am
    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 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

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupusers @
categoriescamel
postedFeb 21, '12 at 11:15p
activeOct 13, '12 at 8:41a
posts7
users4
websitecamel.apache.org

People

Translate

site design / logo © 2022 Grokbase