Hi, ++1 for the new implementation.
So new implementation utilizes "Client Ack" rather than "message browse> deliver>if success consume" ? What about connection caching, session caching and consumer caching? And how JMS transactions come into play? One of major problem previous implementation had was "creating a two new connection for every message". I suppose we have got rid of all of such limitations with the new implementation. Thanks. On Wed, Aug 7, 2013 at 6:12 AM, Samisa Abeysinghe <[email protected]> wrote: > Documentation? > > > On Mon, Aug 5, 2013 at 10:08 AM, Kasun Indrasiri <[email protected]> wrote: > >> It seems we are done with most of the core features and we should try to >> finish this off by this week. >> >> >> On Fri, Aug 2, 2013 at 9:36 AM, Isuru Udana <[email protected]> wrote: >> >>> Hi, >>> >>> As planned earlier, we have completed most of the implementation (about >>> 90%) by today. To be more specific following are the things we have >>> completed so far. >>> >>> -MS/MP core functionality >>> -New blocking sender which supports most of the endpoint functionality >>> -Fixing the UIs accordingly >>> -Fixing the deployers accordingly >>> -Testing basic functionality of the new implementation (both UI and non >>> UI stuff) >>> >>> We have to test the multiple consumer scenarios as well (one >> store/multiple processors) >> >>> Following are the left items to be completed. >>> >>> -Finish the implementation of In memory Message-Store >>> -Integrate Message processor with the new blocking sender >>> -Fix few functions of JMX MBeans of Message-Processors >>> -Fix the existing failing test cases >>> >>> Since the new blocking sender is implemented in a generic way (does not >>> contain message-processor specific functionality), As a part of this >>> effort, I am planning to integrate it with the Callout mediator as well. So >>> that it will be a significant improvement for the Callout Mediator. >>> >>> +1. >> >>> Next week we are planing to continue with testing the functionality >>> including the MB integration, REST support, security,etc. >>> >>> Thanks. >>> >>> On Mon, Jul 29, 2013 at 10:41 AM, Shafreen Anfar <[email protected]>wrote: >>> >>>> Hi, >>>> >>>> Since the existing implementation of MS/MP is quite un-maintainable, we >>>> thought of revamping the existing implementation. >>>> >>>> Link[1] contains the rough component diagram of the existing MS/MP >>>> implementation. According to this design most of the work is done by the >>>> MessageStore class. It was implemented with basic queue operations and act >>>> as a proxy to the actual message stores such as in-memory-maps and >>>> JMS-Queues. However, this design didn't cope well with scenarios such as >>>> reliable messaging. For example, we came across a lot of integration issues >>>> while we were testing ESB-4.7.0 with WSO2-MB. >>>> >>>> Moreover, though message processors are implemented using Quartz, the >>>> existing implementation hasn't utilized it's APIs to the full extent. >>>> >>>> In addition to that current implementation is implemented basically >>>> focusing on SOAP messages. And In the current implementation none of the >>>> endpoint functionality is supported (security, RM, etc.). Only the Address >>>> endpoint type is supported. Endpoint types like Http Endpoint is not >>>> supported. >>>> >>>> link[2] contains the rough component diagram of the new implementation >>>> of MS/MP. New implementation is designed with a view of message producers >>>> and message consumers. As this makes easier to implement the requirements >>>> associated with store-and-forward concepts. According the new design >>>> MessageStore class act as a Manager and provides consumers and producers as >>>> required to message processors and mediators in contrast to providing >>>> methods to do queue operations. Along with this design following are the >>>> tasks we are planning to complete. >>>> >>>> - Re-implement JMS message-store and JMS message-processor >>>> interfaces >>>> - Proper connection handling >>>> - moving classes to synapse >>>> - Utilize Quartz in a proper way >>>> - Fixing UI issues >>>> - Unit/Integration tests >>>> - Supporting all types of messages (Anyway, >>>> existing implementation already supports most of the message types) >>>> - Improve RESTful integration >>>> - Support endpoint functionality (Security, RM etc.) >>>> - Support Address, Default, WSDL, Http endpoints >>>> >>>> We have broken-down the implementation into three parts. >>>> >>>> Implement Message Stores (Ishan) >>>> Implement Message Processors (Shafreen) >>>> Implement stuff related to sending messages out from the ESB (Isuru) >>>> >>>> We are planning to complete the core-implementation within this week. >>>> In the following week, we are going to do a comprehensive test against the >>>> new implementation. >>>> >>>> [1] >>>> https://docs.google.com/a/wso2.com/drawings/d/1U8z_rWaI8tRw6i6iDHtX6S_g0_BxgLLC3HfIS6Iyd5E/edit?usp=sharing >>>> >>>> [2] >>>> https://docs.google.com/a/wso2.com/drawings/d/1AYKL9T3bDqQxH8Ik4pbb0GDoznyQAiAPrIwVVZFzZHQ/edit?usp=sharing >>>> >>>> -- >>>> Regards, >>>> *Shafreen* >>>> Software Engineer >>>> WSO2 Inc >>>> Mobile : 077-556-395-1 >>>> >>> >>> >>> >>> -- >>> *Isuru Udana* >>> * >>> * >>> Senior * >>> Software Engineer >>> * >>> WSO2 Inc.; http://wso2.com >>> email: [email protected] cell: +94 77 3791887 >>> blog: http://mytecheye.blogspot.com/ >>> twitter: http://twitter.com/isudana >>> >> >> >> >> -- >> Kasun Indrasiri >> Software Architect >> WSO2, Inc.; http://wso2.com >> lean.enterprise.middleware >> >> cell: +94 71 536 4128 >> Blog : http://kasunpanorama.blogspot.com/ >> >> _______________________________________________ >> Architecture mailing list >> [email protected] >> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >> >> > > > -- > > Thanks, > Samisa... > > Samisa Abeysinghe > VP Engineering > WSO2 Inc. > http://wso2.com > http://wso2.org > > _______________________________________________ > Architecture mailing list > [email protected] > https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture > > -- *Hasitha Abeykoon* Software Engineer; WSO2, Inc.; http://wso2.com *cell:* *+94 719363063* *blog: **abeykoon.blogspot.com* <http://abeykoon.blogspot.com>* * * *
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
