Hi Shivang,

Try creating journals/data on PVCs. It should work.

Regards,
Prateek Jain



--------------------------------------------------------------
EXPECTATION : Causes all troubles......
--------------------------------------------------------------


On Wed, Sep 13, 2023 at 5:58 PM Shivang Modi <sm...@provenir.com.invalid>
wrote:

> Hi Justin,
>
> We are using Artemis docker image and start kubernetes pods with it. We
> have
> one sender which will write messages on queue and one receiver which will
> read messages queue.
> Now due to any reason, kubernetes queue pod gets restarted so before
> restarts whatever transactions gets enqueued by sender but not read by
> receiver, will that persisted with file storage and If yes, in any scenario
> file storage, chances of losing transactions?
>
> Thanks,
> Shivang.
>
> -----Original Message-----
> From: Justin Bertram <jbert...@apache.org>
> Sent: Wednesday, September 13, 2023 10:23 PM
> To: users@activemq.apache.org
> Subject: Re: Artemis File Storage Persistence vs JDBC Persistence
>
> I'm not really sure what you're asking. Are you asking whether you should
> use the file-based journal or a database if you have 100k transactions?
>
> To be clear, what is "best" in one situation is often not "best" in
> another.
> Everything depends on the specifics of your particular use-case.
>
>
> Justin
>
> On Wed, Sep 13, 2023 at 11:47 AM Shivang Modi <sm...@provenir.com.invalid>
> wrote:
>
> > If scenario is no loss transactions 100% if queue goes down whatever
> > transactions gets enqueued, should get dequeued once queue comes up,
> > we have 100k transactions or more need to flow up via queue. What
> > would be best in such scenarios?
> >
> > Thanks,
> > Shivang
> >
> > -----Original Message-----
> > From: Justin Bertram <jbert...@apache.org>
> > Sent: Wednesday, September 13, 2023 8:38 PM
> > To: users@activemq.apache.org
> > Subject: Re: Artemis File Storage Persistence vs JDBC Persistence
> >
> > When deciding between the file-based journal on local storage versus a
> > remote database I think the three main considerations are:
> >
> >  - Performance
> >  - Infrastructure
> >  - Reliability
> >
> > The file-based journal on local storage will be faster than a database
> > for a few reasons:
> >  - The storage is local so there's no network latency to deal with.
> >  - The file-based journal was specifically written and heavily
> > optimized for the message broker use-case.
> >
> > The file-based journal on local storage requires less infrastructure
> > than a database since most servers already come with local storage.
> > Using a database requires provisioning additional hardware as well as
> > installing and maintaining a distinct piece of software. This can be
> > costly both in terms of money and man-power.
> >
> > Generally speaking, local storage is always going to be more reliable
> > than a remote database simply because it's much simpler (i.e. no
> > network, no database with its own maintenance requirements, etc.).
> > This simplicity tends to reduce downtime.
> >
> > In my experience the only folks who choose to use a database are those
> > in an environment where there's already been a substantial investment
> > in an enterprise database and stuff like automated backups, redundant
> > networking, data replications, etc. are available.
> >
> > No matter which option you choose, the broker is written so that you
> > should
> > *never* lose messages.
> >
> >
> > Justin
> >
> >
> >
> > On Wed, Sep 13, 2023 at 7:14 AM Shivang Modi
> > <sm...@provenir.com.invalid>
> > wrote:
> >
> > > Hi Team,
> > >
> > >
> > >
> > > Can anyone share pros and cons in depth between both. I see only
> > > file storage is faster than JDBC storage. Is there any disadvantage
> > > of File Storage like losing the enqueued data or anything?
> > >
> > >
> > >
> > > Thanks,
> > >
> > > Shivang.
> > >
> > > --
> > > *This e-mail contains PRIVILEGED AND CONFIDENTIAL INFORMATION
> > > intended solely for the use of the addressee(s). If you are not the
> > > intended recipient, please notify the sender by e-mail and delete
> > > the original message. Further, you are not to copy, disclose, or
> > > distribute this e-mail or its contents to any other person and any
> > > such actions maybe unlawful*.
> > > This e-mail may contain viruses. Provenir has taken every reasonable
> > > precaution to minimize this risk, but is not liable for any damage
> > > you may sustain as a result of any virus in this e-mail. You should
> > > carry out your own virus checks before opening the e-mail or
> attachment.
> > > Provenir reserves the right to monitor and review the content of all
> > > messages sent to or from this e-mail address. Messages sent to or
> > > from this e-mail address may be stored on the Provenir e-mail system.
> > >
> >
> > --
> > *This e-mail contains PRIVILEGED AND CONFIDENTIAL INFORMATION intended
> > solely for the use of the addressee(s). If you are not the intended
> > recipient, please notify the sender by e-mail and delete the original
> > message. Further, you are not to copy, disclose, or distribute this
> > e-mail or its contents to any other person and any such actions maybe
> > unlawful*.
> > This e-mail may contain viruses. Provenir has taken every reasonable
> > precaution to minimize this risk, but is not liable for any damage you
> > may sustain as a result of any virus in this e-mail. You should carry
> > out your own virus checks before opening the e-mail or attachment.
> > Provenir reserves the right to monitor and review the content of all
> > messages sent to or from this e-mail address. Messages sent to or from
> > this e-mail address may be stored on the Provenir e-mail system.
> >
> >
>
> --
> *This e-mail contains PRIVILEGED AND CONFIDENTIAL INFORMATION intended
> solely for the use of the addressee(s). If you are not the intended
> recipient, please notify the sender by e-mail and delete the original
> message. Further, you are not to copy, disclose, or distribute this e-mail
> or its contents to any other person and any such actions maybe unlawful*.
> This e-mail may contain viruses. Provenir has taken every reasonable
> precaution to minimize this risk, but is not liable for any damage you may
> sustain as a result of any virus in this e-mail. You should carry out your
> own virus checks before opening the e-mail or attachment. Provenir
> reserves
> the right to monitor and review the content of all messages sent to or
> from
> this e-mail address. Messages sent to or from this e-mail address may be
> stored on the Provenir e-mail system.
>

Reply via email to