Hi Isuru, According to the current model you have added a new Connection handling thread pool to create only the new connections. Are we still going to continue with the disrupter threads to handle mediation due to the performance we gain out of this. Could this be leads to a design issue later if we use heavy content based mediation. Another scenario is if have a slow reading backend in one mediation path this could lead to reduce the GW performance. WDYT ?
*Madhuranga Sampath Bandara* Software Engineer WSO2, Inc.;http://wso2.com/ <http://www.google.com/url?q=http%3A%2F%2Fwso2.com%2F&sa=D&sntz=1&usg=AFQjCNGJuLRux6KkJwXKVUCYOtEsNCmIAQ> lean.enterprise.middleware Mobile: +94722241065 On Thu, Jan 14, 2016 at 12:03 PM, Isuru Ranawaka <[email protected]> wrote: > Hi all, > > Since we are going to do a GW release soon I will post the current thread > model of GW transport and error handling implementation details here. > > > Gateway uses Netty framework as the underlying library for handle > connections and Disruptor as the main thread model for handle requests and > responses in application level. Following are the main points in Request > Flow, > > - Client send a request and Netty Boss Group thread accepts it and > handover control to worker thread. > - Worker thread executes the Netty Pipeline handlers and request is > intercepted in last custom written handler called SourceHandler. > - SourceHandler handovers request to Disruptor as soon as headers are > available and body of the request is written to container inside message > through netty thread. > - Disruptor handler handovers the request for mediation through camel. > - After completion of mediation request is handover to Sender and it > decides to spawn a new thread for connection creation and if a new > connection needed else reuse the existing connection from Connection Pool. > - Sender will handover the request to Netty worker threads for > sending it to actual endpoint. > > Response path also works similar to Request path and all the operations > are asynchronous . > > For the Error handling purposes we have introduce a fault handler due to > multiple threads are working. Fault Handler can be registered for a > message and when an exception occurred it can be executed from the thread > it occurs. Camel can decide what to do with the exception and user can > define custom error messages as well. > > Thanks > > IsuruR > > > Best Regards > Isuru Ranawaka > M: +94714629880 > Blog : http://isurur.blogspot.com/ >
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
