Hi Asanka, Could you please list down the advantages of this in-memory mode over database backed (default) mode? We used to have in-memory JMS store in the WSO2 ESB/EI world but it was never used in a real production system (in fact we recommended not to use that in production). More or less, it was used for demonstration purposes. I'm a bit unclear on why we need an in-memory mode without any database backup.
In this mode, if the node goes down, is there a way to write the status periodically to a database and revert to the last active state once the server restarted? Thanks, Chanaka On Wed, Feb 28, 2018 at 11:05 AM, Shazni Nazeer <[email protected]> wrote: > yeah that makes sense. No memory system is reliable ☺. But certainly good > to have for some scenarios like the throttling events mentioned above. > > On Tue, Feb 27, 2018 at 11:24 PM, Asanka Abeyweera <[email protected]> > wrote: > >> HA is not supported in in-memory mode. This is a non-reliable broker mode >> (unless your memory/system is reliable ;)). If you need to have HA for your >> use case you should not use in-memory mode. >> >> On Wed, Feb 28, 2018 at 10:19 AM, Shazni Nazeer <[email protected]> wrote: >> >>> Hi Asanka, >>> >>> How would the in-memory storage be handled between high availability >>> scenario where we have two MB nodes used? Do we have any distributed >>> caching of some sort? >>> >>> On Tue, Feb 27, 2018 at 12:30 AM, Asanka Abeyweera <[email protected]> >>> wrote: >>> >>>> We are planning to complete the feature in this week's milestone. >>>> Configuration wise, you will have to set the in-memory mode to "true" in >>>> the config. We will explain this in the doc. >>>> >>>> On a separate note, When you use non durable queues (for example with >>>> non durable topic subscribers) with BMB it will operate in memory (without >>>> persisting to database) irrespective of the configured mode. >>>> >>>> >>>> On Tue, Feb 27, 2018 at 11:40 AM, Sanjeewa Malalgoda <[email protected] >>>> > wrote: >>>> >>>>> +1 This will be perfect implementation for throttling events like >>>>> messages( due to high efficiency, small message size, no durable >>>>> requirements etc). >>>>> Do you have any time line estimation for this feature? I believe from >>>>> user point of view there will be no any changes other than remove database >>>>> configuration. >>>>> >>>>> Thanks, >>>>> sanjeewa. >>>>> >>>>> On Fri, Feb 23, 2018 at 4:31 PM, Hasitha Hiranya <[email protected]> >>>>> wrote: >>>>> >>>>>> Hi Asanka, >>>>>> >>>>>> I think we should not restrict. >>>>>> What we are doing is, configuring MB to work with an "in-memory >>>>>> store". >>>>>> It should be a configuration at broker side (applied to all >>>>>> queues/topics). >>>>>> When coding, better keep all logics same attached to an in-memory >>>>>> impl of the store. >>>>>> >>>>>> Thoughts? >>>>>> >>>>>> Thanks >>>>>> >>>>>> On Fri, Feb 23, 2018 at 3:32 PM, Pamod Sylvester <[email protected]> >>>>>> wrote: >>>>>> >>>>>>> Hi Asanka, >>>>>>> >>>>>>> If we're considering to handle durable subscriptions in-memory it >>>>>>> would be good if we can inform the client on it. >>>>>>> >>>>>>> IMHO Semantically it also could mislead the applications. Otherwise >>>>>>> isn't it an option for us to restrict connection creation as durable ? >>>>>>> (if >>>>>>> the broker is started in, "in-memory" mode) >>>>>>> >>>>>>> Thanks, >>>>>>> Pamod >>>>>>> >>>>>>> On Fri, Feb 23, 2018 at 2:14 PM, Asanka Abeyweera <[email protected] >>>>>>> > wrote: >>>>>>> >>>>>>>> Hi all, >>>>>>>> >>>>>>>> I am working on the $subject. In the previous versions of message >>>>>>>> broker, we configured H2 database in the in-memory mode to run the >>>>>>>> broker >>>>>>>> in in-memory mode. But we are thinking of having a mode where we would >>>>>>>> skip >>>>>>>> the database layer completely when in-memory mode is enabled in the >>>>>>>> broker. >>>>>>>> This means we will be doing all of the following tasks in memory. >>>>>>>> >>>>>>>> - Persistent message storing >>>>>>>> - Durable queue information storing >>>>>>>> - Durable exchange information storing >>>>>>>> - Durable binding information storing >>>>>>>> >>>>>>>> Alternatively, we could reject all durable calls when we put the >>>>>>>> broker in in-memory mode. But If we do that we will be limiting some >>>>>>>> of the >>>>>>>> existing applications from using the message broker in in-memory mode. >>>>>>>> Therefore I think It is better not to that. >>>>>>>> >>>>>>>> WDYT? >>>>>>>> -- >>>>>>>> Asanka Abeyweera >>>>>>>> Associate Technical Lead >>>>>>>> WSO2 Inc. >>>>>>>> >>>>>>>> Phone: +94 712228648 <071%20222%208648> >>>>>>>> Blog: a5anka.github.io >>>>>>>> >>>>>>>> <https://wso2.com/signature> >>>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> *Pamod Sylvester * >>>>>>> >>>>>>> *WSO2 Inc.; http://wso2.com <http://wso2.com>* >>>>>>> cell: +94 77 7779495 <077%20777%209495> >>>>>>> >>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> *Hasitha Abeykoon* >>>>>> Associate Technical Lead; 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 >>>>>> >>>>>> >>>>> >>>>> >>>>> -- >>>>> >>>>> *Sanjeewa Malalgoda* >>>>> WSO2 Inc. >>>>> Mobile : +94713068779 <+94%2071%20306%208779> >>>>> >>>>> <http://sanjeewamalalgoda.blogspot.com/>blog >>>>> :http://sanjeewamalalgoda.blogspot.com/ >>>>> <http://sanjeewamalalgoda.blogspot.com/> >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> Architecture mailing list >>>>> [email protected] >>>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>>>> >>>>> >>>> >>>> >>>> -- >>>> Asanka Abeyweera >>>> Associate Technical Lead >>>> WSO2 Inc. >>>> >>>> Phone: +94 712228648 <+94%2071%20222%208648> >>>> Blog: a5anka.github.io >>>> >>>> <https://wso2.com/signature> >>>> >>>> _______________________________________________ >>>> Architecture mailing list >>>> [email protected] >>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>>> >>>> >>> >>> >>> -- >>> Shazni Nazeer >>> >>> Mob : +94 777737331 >>> LinkedIn : http://lk.linkedin.com/in/shazninazeer >>> >>> Blogs : >>> >>> https://medium.com/@mshazninazeer >>> http://shazninazeer.blogspot.com >>> >>> <http://wso2.com/signature> >>> >>> _______________________________________________ >>> Architecture mailing list >>> [email protected] >>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>> >>> >> >> >> -- >> Asanka Abeyweera >> Associate Technical Lead >> WSO2 Inc. >> >> Phone: +94 712228648 <+94%2071%20222%208648> >> Blog: a5anka.github.io >> >> <https://wso2.com/signature> >> >> _______________________________________________ >> Architecture mailing list >> [email protected] >> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >> >> > > > -- > Shazni Nazeer > > Mob : +94 777737331 > LinkedIn : http://lk.linkedin.com/in/shazninazeer > > Blogs : > > https://medium.com/@mshazninazeer > http://shazninazeer.blogspot.com > > <http://wso2.com/signature> > > _______________________________________________ > Architecture mailing list > [email protected] > https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture > > -- Thank you and Best Regards, Chanaka Fernando Senior Technical Lead m: +94 773337238 https://wso2.com <https://wso2.com/signature>
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
