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
