Mailing-List: contact issues-help@camel.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@camel.apache.org
Date: Tue, 19 Feb 2013 14:05:14 +0000 (UTC)
From: "Chad Beaulac (JIRA)" <jira@apache.org>
To: issues@camel.apache.org
Message-ID: <JIRA.12486095.1270659857169.304911.1361282714621@arcas>
In-Reply-To: <JIRA.12486095.1270659857169@arcas>
References: <JIRA.12486095.1270659857169@arcas>
Subject: [jira] [Comment Edited] (CAMEL-2624) support for async responses on
 single tcp connection
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


    [ https://issues.apache.org/jira/browse/CAMEL-2624?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13581287#comment-13581287 ] 

Chad Beaulac edited comment on CAMEL-2624 at 2/19/13 2:05 PM:
--------------------------------------------------------------

I'm not ready to implement the Camel AsycProcessor for camel-mina2 at this time. Not sure it's a good fit for these use cases. How does camel-netty handle the use cases in the description of this ticket? I read the API docs and looked at the code for a few minutes but didn't see how to do it. Docs talk about handling the request-reply pattern asynchronously. Use cases in this ticket handle a conversation pattern when any number of messages can be exchanged by endpoints in either direction. Using a mina codec (or probably filter) could be a good approach. I'll have to think about that. For now I'm going to use the java.nio beans and mina2 code I've been using. I guess the crux of the issue is, the uses cases in this ticket don't fit the "normal use-case is 1 Exchange per complete message received" Claus mentions above. I'm still wondering if I'm trying to fit a square peg into a round hole here or if I'm not being creative enough.
                
      was (Author: cabeaulac):
    The Camel AsycProcessor for requirements I'm trying to meet. How does camel-netty handle the use cases in the description of this ticket? I read the API docs and looked at the code for a few minutes but didn't see how to do it. Docs talk about handling the request-reply pattern asynchronously. Use cases in this ticket handle a conversation pattern when any number of messages can be exchanged by endpoints in either direction. Using a mina codec (or probably filter) could be a good approach. I'll have to think about that. For now I'm going to use the java.nio beans and mina2 code I've been using. I guess the crux of the issue is, the uses cases in this ticket don't fit the "normal use-case is 1 Exchange per complete message received" Claus mentions above. I'm still wondering if I'm trying to fit a square peg into a round hole here or if I'm not being creative enough.
                  
> support for async responses on single tcp connection
> ----------------------------------------------------
>
>                 Key: CAMEL-2624
>                 URL: https://issues.apache.org/jira/browse/CAMEL-2624
>             Project: Camel
>          Issue Type: Improvement
>          Components: camel-mina2
>    Affects Versions: 2.2.0
>         Environment: any
>            Reporter: Anand
>            Assignee: Chad Beaulac
>             Fix For: Future
>
>         Attachments: Mina2ClientServerTest.java, Mina2TcpAsyncOutOnly.java
>
>
> Mina Component does not support async InOut connections.
> Many applications require two way or out only async tcp connections this is not supported.
> Single TCP connection to external server. Ability to send multiple requests one after the other without waiting for a response. responses need to be processed asynchronously.
> h5. Use Cases to Support
> # UC-1 - Consumer sends messages after connect
> ## TCP producer (P1) connects to TCP consumer/server (C1), session is created
> ## C1 sends many messages to P1
> ## P1 receives messages and processes them
> ## C1 or P1 close the connection
> # UC-2 - Full async session
> ## P1 connects to C1
> ## P1 and C1 send and receive messages ansynchronously. There is no blocking write-read loop.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira