Hi Lakshman,
On Thu, Jan 26, 2017 at 10:57 PM, Lakshman Udayakantha <[email protected]>
wrote:
> Hi,
>
> *Usecases*
>
> Sending messages To TCP backend via a persistent connection in ESB. ESB
> will use TCPTransportSender class to send TCP messages when send mediator
> used with TCP protocol.
> This messages will send after adding message length to the front of the
> message. Back end also should send messages by adding message length to the
> front of the messages for the purpose of reading easily.
> Messages can be concatenated in TCP layer even though application layer
> send messages separately. There can be delay in message reading from TCP
> axi2 end and that delay will lead to concatenation of messages. Even though
> messages concatenated message should be retrieved separately and send
> separately to the original caller.
> ESB should recognized disconnection of TCP links immediately and retry in
> configured time interval for configured number of times and if failed even
> after, should report to the client about the error.
>
> *Solution for persistent connection.*
>
> TCPTransportSender {
>
> private Map<String, Socket> persistentConnectionsMap = new HashMap<>();
>
> }
>
> This map holds a unique client id and a socket instance. Whenever a
> message comes to TCPTransportSender it retrieves the relevant socket
> instance to the relevant client id and will send messages via that socket.
>
> *How to prevent message concatenation in TCP layer.*
>
> Existing methods flow is as follows for messages
>
> sendMessage() --> writeMessageOut() --> waitForReply() --> getMessage()
>
> According to the current implementation getMessage() will receive messages
> from TCP backend and after receiving messages it will read bytes for
> message length which is in front of the message ,via a buffer. After that
> it will read the actual message by message length via the same buffer.
> Since getMessage will return after reading the first message, it will lost
> the second message or snippet from it which is remaining in the buffer.
> Then what kind of mechanism should we implement to process the subsequent
> messages also and send them separately to the original caller (websocket
> inbound, tcp client, etc )?
>
I'm not sure if you have found a solution and implemented this already. Can
we use a specific delimiting character to indicate that the message
sequence is complete? It should read the byte buffer each time, with the
length specified, and if it encounters this delimiter, should assume that
there is no more to read for that particular message sequence. WDYT? If you
have a better solution implemented already, please do share.
>
> *Solution to retry mechanism.*
>
> To provide two separate configurations,
> retryInterval - in seconds - default 3 seconds
> noOfRetries - default 3
>
> and finally send an exception report to the client.
>
> Your suggestions are highly appreciated.
>
> Thanks.
> --
> Lakshman Udayakantha
> WSO2 Inc. www.wso2.com
> lean.enterprise.middleware
> Mobile: *0717429601 <071%20742%209601>*
>
>
> _______________________________________________
> Architecture mailing list
> [email protected]
> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>
>
--
Thanks and Regards,
Isuru H.
+94 716 358 048* <http://wso2.com/>*
_______________________________________________
Architecture mailing list
[email protected]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
