Effective October 27, 2012, online and email support for FuseSource products will move to Red Hat support channels. For more information, please see the JIRA Migration to Red Hat FAQ.
As of October 27th, please open all new issues in the Red Hat Customer Portal .
Issue Details (XML | Word | Printable)

Key: MB-835
Type: Improvement Improvement
Status: Resolved Resolved
Resolution: Fixed
Priority: Major Major
Assignee: Gary Tully
Reporter: Adrian Trenaman
Votes: 0
Watchers: 0
Operations

If you were logged in you would be able to see more operations.
FUSE Message Broker

Reduce the number of KahaProducerAuditCommand entries in the KahaDB journal

Created: 07/Mar/11 10:34 AM   Updated: 17/Dec/12 02:09 PM
Component/s: broker
Affects Version/s: 5.4.2-fuse-01-00
Fix Version/s: JBoss A-MQ 6 (5.8.0-fuse-xx-xx)

Environment: All

External Issue URL: https://issues.apache.org/jira/browse/AMQ-3833


 Description  « Hide
Email trail below: after some analysis of the contents of the KahaDB journal log files, there seems to be an excessive number of KahaProducerAuditCommand entries. If there's away to optimize this to reduce the number of audit commands written to the log, then we should save on disk IO and have more compact journal files.

On 4 March 2011 16:23, Trenaman, Adrian <trenaman@fusesource.com> wrote:
> > Thanks for the clarification,Gary!
> >
> > If there's away to optimize these writes, then I think we shoulkd
> > consider it. Right now I've got tons of these commands in my journal
> > I suspect that this may lead to bloated and large journal files on our
> > customer sites! Am also wondering that all these audit commands will
> > consume precious disk IO...
> >
> > Cheers,
> > Ade
> >
> >
> > On 04/03/2011, Gary Tully <gary.tully@gmail.com> wrote:
>> >> Ade,
>> >> those are keeping track of the last message produced such that
>> >> duplicates can be suppressed when producers failover. They in memory
>> >> record is synced with every checkpoint so that is will be valid on
>> >> recovery.
>> >> It would make sense to only sync if the inmemory record has changed
>> >> (so that they are not written for an idle broker), but in normal usage
>> >> it will change frequently.
>> >>
>> >>
>> >> On 4 March 2011 13:11, Adrian Trenaman <trenaman@fusesource.com> wrote:
>>> >>> Hi Geeks,
>>> >>>
>>> >>> Just a little note to say that this week I've been working with a customer
>>> >>> who had some very large (> 30Gb) KahaDB files; the customer was happy for
>>> >>> me
>>> >>> to extend my defrag utility to provide some analysis of what is going on
>>> >>> in
>>> >>> their very large dataset. If anyone would like the latest version of the
>>> >>> defragger, let me know.
>>> >>>
>>> >>> While working with the defragger, I noticed that my KahaDB logs are full
>>> >>> of
>>> >>> KahaProducerAuditCommands. There's loads of them! What do these commands
>>> >>> do?
>>> >>> Do we really need them? The seem to take up lots of space...
>>> >>>
>>> >>> Curious,
>>> >>> Ade.
>>> >>>
>> >>
>> >>
>> >>
>> >> –
>> >> http://blog.garytully.com
>> >> http://fusesource.com
>> >>
> >

http://blog.garytully.com http://fusesource.com



 All   Comments   Change History      Sort Order: Ascending order - Click to sort in descending order
Gary Tully added a comment - 17/Dec/12 02:09 PM
fix in 5.8