Hi Lakshman, When handling multiple responses using a single persistent connection, we need to use some kind of unique key per request and send it to the back-end with the request. When the back-end responses, it should include the above key in the response as well. It will help to map the request and response. Also it will be useful when multiple responses are available for a single request.
According to the existing implementation, it creates a new socket per request, and closes it once the response is received. With this new implementation, it should not close the connection and should keep reading other responses as well. IMO here we can keep connections per host:port (destination) instead of per client. It will reduce the number of persistent connections established with back-end. With this requirement,communication with the back-end needs to be handled in a separate thread because it is required to continuously wait for data from the same connection. Thanks. On Fri, Jan 27, 2017 at 10:53 AM, Lakshman Udayakantha <[email protected]> wrote: > Hi Chanaka, > > Thanks for your suggestions. As you said this was supposed to be developed > on top of TCP transport protocol. Actually, This implementation will be > done by assuming both ends should agree upon the way of messages send. > Anyhow messages concatenation haven't done by the TCP backend. It can > happen in the TCP layer even though application layer sent those message > separately because if some delay in ESB to read messages will lead to > flooded the messages in TCP layer and this will cause two messages come in > one lump to the ESB. Shouldn't we handle that case in ESB Axis2 transport > side? > > Thanks, > Lakshman > > On Fri, Jan 27, 2017 at 7:31 AM, Chanaka Fernando <[email protected]> > wrote: > >> Hi Lakshman, >> >> I think you are trying to implement a feature on top of the TCP transport >> protocol. At the TCP level, it handles the reliable message communication >> through its protocol specific features (e.g. sequence number, resend). If >> you want to implement something on top of that, both your client and the >> server (back end) should come to an agreement on how the messages are sent >> and received. For example, If the back end sends several messages >> concatenated as a single message, it must include that information on the >> message somehow, so that the receiving side can properly read that message. >> Otherwise, there is no other way to read that message correctly from the >> client side. For this solution, you need to design both client and back end >> side of the communication. >> >> >> 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 )? >>> >>> *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>* >>> >>> >> >> >> -- >> Thank you and Best Regards, >> Chanaka Fernando >> Senior Technical Lead >> m: +94 773337238 <+94%2077%20333%207238> >> https://wso2.com <https://wso2.com/signature> >> >> >> >> >> >> >> > > > -- > Lakshman Udayakantha > WSO2 Inc. www.wso2.com > lean.enterprise.middleware > Mobile: *0717429601* > > -- Jagath Ariyarathne Technical Lead WSO2 Inc. http://wso2.com/ Email: [email protected] Mob : +94 77 386 7048 <http://wso2.com/signature>
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
