Discuss AMQ7015

[Johan Edstrom <se...@gmail.com>]

Hey, 

We  have a situation where we have KahaDB performing recovery, digging deeper into it one issue is that the db.log contains prepared transactions.
The MessageDatabase will discard those entries in memory, however it does not remove transaction info from those messages.

So on each restart, the broker will find those entries and again discard them in memory.

If I access the broker via JMX, I can go to the prepared XAs and execute a clear on them one by one.
That’s pretty tedious, especially if you say have 300k transactions (Don’t ask why :))
When i restart my broker, those I manually cleared of course are gone.

In the Jira is a different approach, basically add a parameter that allows us to just discard during recovery - 

This helps resolve this as we have 300k XA Transactions that we already know are "broken", recovering the "Correct" way, we spend hours, 
being able to not rebuild (Which we know is bad), we are talking minutes. 
This methodology technically break the XA contract because the content is more important than the actual transaction,
 we are intending to drain and replay them in new sessions.

- Just to throw some background to the slip and see what others have to say. 

Re: Discuss AMQ7015

[heathkesler <hk...@apache.org>]

+1 as the Mbean does not work well will large amounts of prepared XA records

The main reason that I created this was we had a batch of 100K XA in a
batch.  There was a failure.  The MBean created an OOM because there were
too many in recovery (1 MBean per record).  I needed a way to get around
this.



--
Sent from: http://activemq.2283324.n4.nabble.com/ActiveMQ-Dev-f2368404.html

Re: Discuss AMQ7015

["Jamie G." <ja...@gmail.com>]

+1 on the parameter

I strongly agree with the not all users can use the MBean - if an
optional parameter can be used here to clear the user scenario, and
its properly documented as to what it does, than I'd have no issue
with it existing.
On Thu, Jul 26, 2018 at 3:23 PM jgenender <jg...@apache.org> wrote:
>
> Hi Johan,
>
> That was exactly what that attribute was added for.  I had a discussion with
> Gary this morning (Gary please correct me if I am wrong on any points) was
> that he felt that having an MBean that can do a full sweep instead of a
> parameter would be better.  Unfortunately for some, an MBean may not be
> plausible.  An attribute seems like a simple way to do this and acts almost
> no differently than the
> ignoreMissingJournalfiles/checkForCorruptJournalFiles parameters.  The
> attribute does the exact same thing as the MBean without the need to use the
> MBean.  The difference is that yes, its an attribute in the config file and
> at second boot it executes again.  But what if that is what you want?  If
> you don't want it, then you can remove it.
>
> I am in agreement with you that this seems like a decent enhancement and I
> would be interested in what the technical reason is that this attribute
> should not be included.  I don't think that we should be only shoe-horning
> the end user into a single way/method to clear out the preparedXA records
> that are stuck.  Offering multiple ways to do this only is advantageous to
> the end user.  Not everyone wants nor can use the MBean.  So this allows
> users to do the same en-masse with a parameter.
>
> Anyone have a solid technical reason not to implement AMQ-7015?
>
>
>
> --
> Sent from: http://activemq.2283324.n4.nabble.com/ActiveMQ-Dev-f2368404.html

Re: Discuss AMQ7015

[jgenender <jg...@apache.org>]

Hi Johan,

That was exactly what that attribute was added for.  I had a discussion with
Gary this morning (Gary please correct me if I am wrong on any points) was
that he felt that having an MBean that can do a full sweep instead of a
parameter would be better.  Unfortunately for some, an MBean may not be
plausible.  An attribute seems like a simple way to do this and acts almost
no differently than the
ignoreMissingJournalfiles/checkForCorruptJournalFiles parameters.  The
attribute does the exact same thing as the MBean without the need to use the
MBean.  The difference is that yes, its an attribute in the config file and
at second boot it executes again.  But what if that is what you want?  If
you don't want it, then you can remove it.

I am in agreement with you that this seems like a decent enhancement and I
would be interested in what the technical reason is that this attribute
should not be included.  I don't think that we should be only shoe-horning
the end user into a single way/method to clear out the preparedXA records
that are stuck.  Offering multiple ways to do this only is advantageous to
the end user.  Not everyone wants nor can use the MBean.  So this allows
users to do the same en-masse with a parameter.

Anyone have a solid technical reason not to implement AMQ-7015?



--
Sent from: http://activemq.2283324.n4.nabble.com/ActiveMQ-Dev-f2368404.html