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. >