Artemis JDBC Persistence

[Luis De Bello <lu...@hotmail.com>]

Hi guys,

I am analyzing different ways to avoid relying on the state store in disk in our brokers and  I found the option of externalizing state in a Database.

Currently we have a network of broker with 4 active brokers, is there any way to use the same Database and the same tables names or configuring the broker in a way it handle that for me?

Also I would like to know if someone has done something similar. Currently I am thinking on doing message tracking (infligh messages) in our producer side and having notifications when the brokers go up to re-populate messages and avoid relying on disk or external state.

Thanks & Best Regards,
Luis

Re: Artemis JDBC Persistence

[Clebert Suconic <cl...@gmail.com>]

On Thu, Sep 17, 2020 at 5:15 PM Luis De Bello <lu...@hotmail.com>
wrote:

> Hi guys,
>
>
>
> I am analyzing different ways to avoid relying on the state store in disk
> in our brokers and  I found the option of externalizing state in a Database.


The database will need a file storage as well right ?

>
>
>
>
> Currently we have a network of broker with 4 active brokers, is there any
> way to use the same Database and the same tables names or configuring the
> broker in a way it handle that for me?
>

Are you considering performance?

Database systems are designed to be reliable while message systems to be
fast.

In my many years working in messaging that has always been the case.

We offer the DB option for users who need and usually don’t need as much
perf as you have on journal.



>
>
> Also I would like to know if someone has done something similar. Currently
> I am thinking on doing message tracking (infligh messages) in our producer
> side and having notifications when the brokers go up to re-populate
> messages and avoid relying on disk or external state.
>
>
>
> Thanks & Best Regards,
>
> Luis
>
> --
Clebert Suconic

Re: Artemis JDBC Persistence

[Justin Bertram <jb...@apache.org>]

Every broker "owns" its own messages, even in a cluster. Therefore each
broker will need it's own tables to store its data.

I'm not really sure what you mean by "message tracking". If you send a
durable message to the broker and it fails to persist it then the send
operation will fail so you'll know if the message made it to the broker or
not.

In general, what's your aversion to relying on disk storage? Even if the
data is in a database it's still on disk somewhere.


Justin

On Thu, Sep 17, 2020 at 4:15 PM Luis De Bello <lu...@hotmail.com>
wrote:

> Hi guys,
>
> I am analyzing different ways to avoid relying on the state store in disk
> in our brokers and  I found the option of externalizing state in a Database.
>
> Currently we have a network of broker with 4 active brokers, is there any
> way to use the same Database and the same tables names or configuring the
> broker in a way it handle that for me?
>
> Also I would like to know if someone has done something similar. Currently
> I am thinking on doing message tracking (infligh messages) in our producer
> side and having notifications when the brokers go up to re-populate
> messages and avoid relying on disk or external state.
>
> Thanks & Best Regards,
> Luis
>