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
On Fri, Feb 23, 2018 at 3:32 PM, Pamod Sylvester <pa...@wso2.com> 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)
> On Fri, Feb 23, 2018 at 2:14 PM, Asanka Abeyweera <asank...@wso2.com>
>> 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.
>> Asanka Abeyweera
>> Associate Technical Lead
>> WSO2 Inc.
>> Phone: +94 712228648 <071%20222%208648>
>> Blog: a5anka.github.io
> *Pamod Sylvester *
> *WSO2 Inc.; http://wso2.com <http://wso2.com>*
> cell: +94 77 7779495
Associate Technical Lead; WSO2, Inc.; http://wso2.com
*cell:* *+94 719363063*
*blog: **abeykoon.blogspot.com* <http://abeykoon.blogspot.com>
Architecture mailing list