Hey Leif,
When using :fsync-interval, the actual calls to .force() on the underlying
ByteBuffers occur on another thread, making it effectively a background
process. This is contrasted with :fsync-threshold, which will
synchronously call fsync when the write threshold is hit. Note that if the
Hi, Zach.
I was trying to benchmark at different values of the :fysnc-* parameters,
and I noticed that it didn't matter what value of :fsync-interval I set,
the performance was constant, and about what it is with both :fsync-put?
and :fsync-take? disabled.
Any suggestions on how to test if dat
I added the above-described features a few weeks back, but only got around
to marking 0.1.1 today. Fsync batching is described at the end of the
README, let me know if you have any questions.
On Friday, February 7, 2014 11:52:11 AM UTC-8, Zach Tellman wrote:
>
> Hi Bob,
>
> Right now the API on
Hi Bob,
Right now the API only allows for single puts, and fsyncing is
all-or-nothing. However, this is just an artifact of my major use case for
the library, which relies on upstream batching of tasks. I'm planning an
0.1.1 release which has an explicit `sync` method, and support for
sync-inter
On Feb 6, 2014, at 6:45 PM, Zach Tellman wrote:
> At Factual we get a lot of data thrown at us, and often don't have control
> over the rate at which it comes in. As such, it's preferable that our buffer
> isn't bounded by the process' memory, since a temporary blip in throughput
> may cause
At Factual we get a lot of data thrown at us, and often don't have control
over the rate at which it comes in. As such, it's preferable that our
buffer isn't bounded by the process' memory, since a temporary blip in
throughput may cause GC pauses, OOM exceptions, and other things that will
onl
