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
