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

Chad Beaulac commented on CAMEL-2624:
-------------------------------------

{quote}...too fine grained. We should only invoke the processor when the 
message is received...{quote}
This solution exposes the TCP/UDP Session create/destroy events to the Route. 
This is necessary to meet the requirement.

{quote}Doing true request/reply over mina2 with async is harder as you would 
need to do something like camel-jms doing. Where we use a correlation id to 
match up incoming messages with its corresponding request message. And when we 
have a match we continue routing.{quote}
We don't need to do withat camel-jms is doing and correlate sessions. The Mina2 
IoSession is exposed to the Route. Producers and Consumers on a given 
camel-mina2 Route can implement their own session management. Session 
management is intentionally left as an exercise to the developer using 
camel-mina2.
{code}
 
from(String.format("mina2:tcp://localhost:8070?&sync=false").beanRef("myTCPSessionManager");
{code}

{quote}...need to deal with timeouts...{quote}
The InOut and InOnly patterns are supported just how they are in camel-mina and 
currently in camel-mina2, except that this patch further exposes the IoSession 
in order to handle the other use cases. Handling timeouts in a fully 
asynchronous connection is left to the develop (of the myTCPSessionManager 
above).
Developers writing APIs for simple interfaces that send a few messages back and 
forth don't have to get too serious with throughput. Developers writing 
endpoints that handle streams dealing with rates greater than 900Mbits/sec 
might implement their session handling differently. I'm dealing with the latter.

We need to expose the session created/closed events in order to support full 
asynchronous comms. The Processors, Beans or IoHandlers in the Camel Route 
chain and/or attached to the camel-mina2 Producer/Consumer are definitely 
interested in session create/closed events flowing through the Route. 
The Processor that comes after the Consumer in the Mina2TCPAsyncOutOnlyTest 
gets the IoSession from the exchange and sends messages back to the Producer 
asynchronously. Code below.   
{code}
// The IoSession has been created. Send 300 messages back to the Producer.
IoSession session = (IoSession) 
e.getIn().getHeader(Mina2Constants.MINA2_IOSESSION);
for (int i = 0; i < 300; i++) {
    String msg = "message " + i;
    session.write(msg);
}
{code}

Please take another look and/or provide alternatives. This patch handles the 
existing InOut and InOnly pattern requirements as well as allowing fully 
asynchronous Producers and Consumers.

                
> 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: 2.11.0
>
>         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

Reply via email to