You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@activemq.apache.org by Richard Holt <ri...@btopenworld.com> on 2010/04/08 11:07:11 UTC
KahaDB enableJournalDiskSyncs
Hi,
We have currently set this option to true however does this need to be
enabled as the performance of the system decreases dramatically when set to
true. The documentation on it just states that it is a jms requirement?
We have a requirement for no message loss so whichever option provides for
this we will have to use.
Thanks In Advance
--
View this message in context: http://old.nabble.com/KahaDB-enableJournalDiskSyncs-tp28176017p28176017.html
Sent from the ActiveMQ - User mailing list archive at Nabble.com.
Re: KahaDB enableJournalDiskSyncs
Posted by Richard Holt <ri...@btopenworld.com>.
also given that we run in a pure master slave configuration if either fail
could we assume that the disk sync would run on the other activemq instance
(assuming that hasnt failed as well of course!)
--
View this message in context: http://old.nabble.com/KahaDB-enableJournalDiskSyncs-tp28176017p28176709.html
Sent from the ActiveMQ - User mailing list archive at Nabble.com.
Re: KahaDB enableJournalDiskSyncs
Posted by Richard Holt <ri...@btopenworld.com>.
ok thanks
just for you information we tested this with the master/slave and dropping
the master will still allow the slave to carry on with the syncing. so given
that we are in pure master slave the issue goes away.
obviously if we lose master and slave issues will occur though
Gary Tully wrote:
>
> yea, I mean on the client producer size. batch up the sends with a
> transacted session.
>
> On 8 April 2010 11:20, Richard Holt <ri...@btopenworld.com> wrote:
>
>>
>> hi gary, thanks for that it was what i was expecting but the order of
>> speed
>> slowdown is vast. for a simple comparison our test ran to completion in 9
>> minutes with this disabled and it was still running at 12 minutes with
>> only
>> approximately 1/2 of the messages completed at 12 minutes
>>
>> you mention transactions, how would i enable this functionallity to test,
>> i
>> see no mention of transactions except from the client producer side? or
>> is
>> this what you mean?
>>
>>
>> Gary Tully wrote:
>> >
>> > That option enables a blocking fsync on every message enqueue as per
>> the
>> > spec durability requirement. With that option disabled, writes are
>> > synced periodically in batches so in the event of a system crash is is
>> > possible that an enqueue is not durable.
>> > Using transactions is another way to avoid the fsync overhead on every
>> > enqueue as it can be deferred till commit.
>> >
>> > On 8 April 2010 10:07, Richard Holt <ri...@btopenworld.com>
>> wrote:
>> >
>> >>
>> >> Hi,
>> >>
>> >> We have currently set this option to true however does this need to be
>> >> enabled as the performance of the system decreases dramatically when
>> set
>> >> to
>> >> true. The documentation on it just states that it is a jms
>> requirement?
>> >>
>> >> We have a requirement for no message loss so whichever option provides
>> >> for
>> >> this we will have to use.
>> >>
>> >> Thanks In Advance
>> >> --
>> >> View this message in context:
>> >>
>> http://old.nabble.com/KahaDB-enableJournalDiskSyncs-tp28176017p28176017.html
>> >> Sent from the ActiveMQ - User mailing list archive at Nabble.com.
>> >>
>> >>
>> >
>> >
>> > --
>> > http://blog.garytully.com
>> >
>> > Open Source Integration
>> > http://fusesource.com
>> >
>> >
>>
>> --
>> View this message in context:
>> http://old.nabble.com/KahaDB-enableJournalDiskSyncs-tp28176017p28176613.html
>> Sent from the ActiveMQ - User mailing list archive at Nabble.com.
>>
>>
>
>
> --
> http://blog.garytully.com
>
> Open Source Integration
> http://fusesource.com
>
>
--
View this message in context: http://old.nabble.com/KahaDB-enableJournalDiskSyncs-tp28176017p28178412.html
Sent from the ActiveMQ - User mailing list archive at Nabble.com.
Re: KahaDB enableJournalDiskSyncs
Posted by Gary Tully <ga...@gmail.com>.
yea, I mean on the client producer size. batch up the sends with a
transacted session.
On 8 April 2010 11:20, Richard Holt <ri...@btopenworld.com> wrote:
>
> hi gary, thanks for that it was what i was expecting but the order of speed
> slowdown is vast. for a simple comparison our test ran to completion in 9
> minutes with this disabled and it was still running at 12 minutes with only
> approximately 1/2 of the messages completed at 12 minutes
>
> you mention transactions, how would i enable this functionallity to test, i
> see no mention of transactions except from the client producer side? or is
> this what you mean?
>
>
> Gary Tully wrote:
> >
> > That option enables a blocking fsync on every message enqueue as per the
> > spec durability requirement. With that option disabled, writes are
> > synced periodically in batches so in the event of a system crash is is
> > possible that an enqueue is not durable.
> > Using transactions is another way to avoid the fsync overhead on every
> > enqueue as it can be deferred till commit.
> >
> > On 8 April 2010 10:07, Richard Holt <ri...@btopenworld.com>
> wrote:
> >
> >>
> >> Hi,
> >>
> >> We have currently set this option to true however does this need to be
> >> enabled as the performance of the system decreases dramatically when set
> >> to
> >> true. The documentation on it just states that it is a jms requirement?
> >>
> >> We have a requirement for no message loss so whichever option provides
> >> for
> >> this we will have to use.
> >>
> >> Thanks In Advance
> >> --
> >> View this message in context:
> >>
> http://old.nabble.com/KahaDB-enableJournalDiskSyncs-tp28176017p28176017.html
> >> Sent from the ActiveMQ - User mailing list archive at Nabble.com.
> >>
> >>
> >
> >
> > --
> > http://blog.garytully.com
> >
> > Open Source Integration
> > http://fusesource.com
> >
> >
>
> --
> View this message in context:
> http://old.nabble.com/KahaDB-enableJournalDiskSyncs-tp28176017p28176613.html
> Sent from the ActiveMQ - User mailing list archive at Nabble.com.
>
>
--
http://blog.garytully.com
Open Source Integration
http://fusesource.com
Re: KahaDB enableJournalDiskSyncs
Posted by Richard Holt <ri...@btopenworld.com>.
hi gary, thanks for that it was what i was expecting but the order of speed
slowdown is vast. for a simple comparison our test ran to completion in 9
minutes with this disabled and it was still running at 12 minutes with only
approximately 1/2 of the messages completed at 12 minutes
you mention transactions, how would i enable this functionallity to test, i
see no mention of transactions except from the client producer side? or is
this what you mean?
Gary Tully wrote:
>
> That option enables a blocking fsync on every message enqueue as per the
> spec durability requirement. With that option disabled, writes are
> synced periodically in batches so in the event of a system crash is is
> possible that an enqueue is not durable.
> Using transactions is another way to avoid the fsync overhead on every
> enqueue as it can be deferred till commit.
>
> On 8 April 2010 10:07, Richard Holt <ri...@btopenworld.com> wrote:
>
>>
>> Hi,
>>
>> We have currently set this option to true however does this need to be
>> enabled as the performance of the system decreases dramatically when set
>> to
>> true. The documentation on it just states that it is a jms requirement?
>>
>> We have a requirement for no message loss so whichever option provides
>> for
>> this we will have to use.
>>
>> Thanks In Advance
>> --
>> View this message in context:
>> http://old.nabble.com/KahaDB-enableJournalDiskSyncs-tp28176017p28176017.html
>> Sent from the ActiveMQ - User mailing list archive at Nabble.com.
>>
>>
>
>
> --
> http://blog.garytully.com
>
> Open Source Integration
> http://fusesource.com
>
>
--
View this message in context: http://old.nabble.com/KahaDB-enableJournalDiskSyncs-tp28176017p28176613.html
Sent from the ActiveMQ - User mailing list archive at Nabble.com.
Re: KahaDB enableJournalDiskSyncs
Posted by Gary Tully <ga...@gmail.com>.
That option enables a blocking fsync on every message enqueue as per the
spec durability requirement. With that option disabled, writes are
synced periodically in batches so in the event of a system crash is is
possible that an enqueue is not durable.
Using transactions is another way to avoid the fsync overhead on every
enqueue as it can be deferred till commit.
On 8 April 2010 10:07, Richard Holt <ri...@btopenworld.com> wrote:
>
> Hi,
>
> We have currently set this option to true however does this need to be
> enabled as the performance of the system decreases dramatically when set to
> true. The documentation on it just states that it is a jms requirement?
>
> We have a requirement for no message loss so whichever option provides for
> this we will have to use.
>
> Thanks In Advance
> --
> View this message in context:
> http://old.nabble.com/KahaDB-enableJournalDiskSyncs-tp28176017p28176017.html
> Sent from the ActiveMQ - User mailing list archive at Nabble.com.
>
>
--
http://blog.garytully.com
Open Source Integration
http://fusesource.com