When you guys said 90% done, it apparently meant code complete that much. Please make sure to be done-done!
On Wed, Aug 7, 2013 at 4:56 PM, Ishan Jayawardena <[email protected]> wrote: > We can use the existing samples with the new implementation. Although we > have added several parameters and configuration changes to the new > implementation, it is still fully backward compatible with the old > configuration. > For the new features/changes that we have implemented, we will add > samples+documentation. > We will also add integration tests. > Thanks, > Ishan. > > > On Wed, Aug 7, 2013 at 4:40 PM, Samisa Abeysinghe <[email protected]> wrote: > >> Samples? >> >> >> On Wed, Aug 7, 2013 at 9:23 AM, Ishan Jayawardena <[email protected]> wrote: >> >>> Hi Samisa, >>> We will start working on the new documentation by the end of this week >>> as we have completed most of the implementation. >>> >>> Hasitha, We use client ack in the new implementation, and there is only >>> a single connection to produce messages and each consumer has its own >>> connection. >>> We are just using the raw JMS API and therefore we have not implemented >>> any JMS Object caching within the message store or message processor apart >>> from reusing the producer/consumer connections. >>> >>> Thanks, >>> Ishan. >>> >>> On Wed, Aug 7, 2013 at 6:31 AM, Hasitha Hiranya <[email protected]>wrote: >>> >>>> 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 >>>> >>>> >>> >>> >>> -- >>> >>> _______________________________________________ >>> 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 >> >> > > > -- > > _______________________________________________ > 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
