Hi IsuruH, Sorry for the delayed response. Find inline comments.
On Wed, Feb 15, 2017 at 7:43 AM, Isuru Haththotuwa <[email protected]> wrote: > 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. > According to the requirement, we need to prefixed message length to message itself. So no point of adding any other delimiting character to indicate the end of the message. End of the message will identify by the message length bytes that can be found in front of the message. For the purpose of detecting TCP connection immediately, It was created another thread which is indefinitly wait for incoming messages. TCP layer will send -1 if any diconnection happen. So we can use that to throw an error to the original caller. Possible message concatenation happen in TCP layer is avoided by adding a Map that holds response message contexts with client IDs. So even though concatenated message arrived, relevant response message context will be retrieved from Map and will process separately. According to the current implementation done, For the persistent connection, three threads will be created for message processing. 1. TCPTransportSender - Responsible for message sending to the backend. 2. TCPBackendListener - Responsilbe for waiting for messages from backend indefinitely. This thread will share a blocking queue which holds exceptions, with TCPTransportSender thread. If the connection broken, an exception will add to the the exception blocking queue. Then TCPTransportSender thread will use retry mechanism mentioned in first mail if specified, Or will issue the exception to the original caller. 3. TCPResponseSender - Responsible for message sending to the original caller. This thread will share a blocking queue which holds incoming messages, with TCPBackendListener thread and another blocking queue which holds response message contexts, with TCPTransportSender thread. When a message arrived, relevant message and response message contexts will be retrieved from relavant blocking queues and will reply to the original caller. Please share your concerns and suggestions on this. Thanks, Lakshman. >> *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 <+94%2071%20635%208048>* <http://wso2.com/>* > > > -- Lakshman Udayakantha WSO2 Inc. www.wso2.com lean.enterprise.middleware Mobile: *0717429601*
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
