Skip to content


Subversion checkout URL

You can clone with
Download ZIP
Commits on Dec 5, 2012
  1. @Vagabond @kellymclaughlin
Commits on Oct 17, 2012
  1. @jaredmorrow

    Merge pull request #232 from basho/core232-sysmon-memory-usage

    jaredmorrow committed
    Address high memory use by riak_core_sysmon_handler
  2. @kellymclaughlin
  3. @kellymclaughlin
Commits on Oct 1, 2012
  1. @kellymclaughlin

    Address high memory usage by riak_core_sysmon_handler.

    kellymclaughlin committed
    Fixes CORE232
    Change riak_core_sysmon_handler to use hibernation to free up
    resources when it is idle since it does not do a good job of freeing
    these resources on its own. Also force garbage collection on the
    riak_core_sysmon_handler process if it receives a large_heap message
    about itself. This is to avoid a feedback loop that can lead to severe
    memory usage by the handler, node slowness, and even cause the node to
    crash after consuming all available memory.
Commits on Sep 27, 2012
  1. @kellymclaughlin
Commits on Sep 26, 2012
  1. @kellymclaughlin

    Improve exception handling for synchronous calls in riak_core_vnode_p…

    kellymclaughlin committed
    Fixes CORE231
    The call functions in riak_core_vnode_proxy only expected a result
    of {ok, Res}. This change calls a new function, call_reply, to
    better handle the case when an exception is thrown and wrap
    the reason in an error tuple.
Commits on Sep 25, 2012
  1. @jtuple
Commits on Sep 21, 2012
  1. @reiddraper

    Call ring_trans synchronously, not in a spawn

    reiddraper committed
    Calling `add_supported_to_ring` is not threadsafe.
    If a process retrieves the member_meta and then
    it's concurrently updated by another process,
    the original process' changed will be overwritten.
    To exhibit the original bug, I added a
    timer:sleep(crypto:rand_uniform(1, 1000))
    line inside the spawned fun that calls
    riak_core_ring_manager:ring_trans(F, ok)
Commits on Sep 13, 2012
  1. @jaredmorrow

    Merge pull request #223 from basho/jdb-timers

    jaredmorrow committed
    Change ticks from timer to more efficient erlang:send_after
  2. @jaredmorrow

    Merge pull request #224 from basho/adt-os-timestamp

    jaredmorrow committed
    erlang:now() -> os:timestamp() in all the places it is safe
Commits on Sep 8, 2012
  1. @jaredmorrow @Vagabond
  2. @Vagabond

    erlang:now() -> os:timestamp() in all the places it is safe

    Vagabond committed
    There are a few places I didn't touch as it was unclear if the values
    needed to be monotonic or not. Specifically core_claimant, core_gossip,
    core_ring and core_ring_manager.
Commits on Sep 7, 2012
  1. @jaredmorrow
Commits on Aug 29, 2012
  1. @kellymclaughlin
  2. @kellymclaughlin

    Include eunit header.

    kellymclaughlin committed
  3. @kellymclaughlin

    Add eunit test.

    kellymclaughlin committed
  4. @kellymclaughlin
  5. @kellymclaughlin
  6. @kellymclaughlin
Commits on Aug 16, 2012
  1. @jonmeredith

    Take newer upstream poolboy.

    jonmeredith committed
    @vagabond promised it works.
Commits on Aug 3, 2012
  1. @jtuple
  2. @jtuple

    Ensure legacy nodes are probed when new capabilities registered

    jtuple committed
    The capability system caches prior probes of legacy app vars when dealing
    with legacy nodes. Prior to this commit, the logic was simple. If there
    were any cached results, no probes were performed. Unfortunately, this
    could lead to a race condition. If capabilities were probed before all
    applications (eg. riak_core, riak_kv) had started and registered their
    capabilities, the cache would only include some results, and no probes
    would be performed for the newly registered capabilities. This commit
    makes things more fine-grained, checking for cached results of individual
    This change does nothing for non-legacy nodes. All nodes that support
    the capability system natively already worked with delayed registration.
Commits on Jul 25, 2012
  1. @jtuple
  2. @jtuple

    Fix spurious "Forcing update of stalled ring"

    jtuple committed
    Changed the force update logic in riak_core_claimant to not perform
    a forced update if we have pending staged joins and no auto-joining
    nodes. Forcing a ring update because of staged joins will not actually
    change the ring, because staged joins will not transition until
    committed. This was a false positive detection of a stalled ring.
  3. @russelldb

    restructure supervision tree so that folsom is an included app

    russelldb committed
    All stat mods depend on folsom, yet they are not linked to it.
    This change brings folsom under supervision of a core stat sup,
    which also supervises the riak stat subsystem. Now when folsom exits
    everyone gets to restart clean and recover.
    riak_core_stat_sup (rest_for_one)
           - folsom_sup
           - riak_core_stats_sup (one_for_one)
              - riak_*_stat
              - riak_stat_cache
    riak_core_stats_sup will start and supervise gen_server stat mods at
    registration time, and will re-start them should the sup crash.
Commits on Jul 24, 2012
  1. @jtuple
  2. @jtuple
Commits on Jul 22, 2012
  1. @jtuple

    Merge pull request #214 from basho/jdb-ring-manager-load

    jtuple committed
    Fix race during start-up that could overwrite existing ring file.
    Fix issue #166.
  2. @jtuple

    Fix capability system race condition

    jtuple committed
    Prevent the node from crashing when the capability system attempts to
    negotiate capabilities before the node has registered any capabilities.
  3. @jtuple

    Make the ring manager responsible for loading the ring

    jtuple committed
    Change riak_core_ring_manager and riak_core_app so that the ring manager
    is responsible for loading the ring file from the disk rather than starting
    with an initially empty ring and then relying upon the riak_core app to
    later load the ring. This avoids a race condition with the ring manager
    writing the empty ring to the disk before the riak_core app loads the
    prior ring.
    Note: Riak previously relied upon starting with a fresh ring in order to
    ensure secondary vnodes were started in case any had fallback data that
    needed to be handed off. The act of starting secondaries has long since
    been moved to the riak_core_vnode_manager that periodically starts up
    secondary vnodes over time, therefore there is no longer any need to
    start with a fresh ring. This commit will therefore always load a saved
    ring when the ring_manager starts, rather than starting with a fresh ring.
Commits on Jul 20, 2012
  1. @russelldb
  2. @russelldb

    Register stat mods with the riak_core app

    russelldb committed
    When the stat cache crashes, we must re-register stat mods with
    the cache so that it works when re-started.
    Delete stats before register
    This is to ensure that a restarted riak_core_stat will not
    leave any orphaned folsom stats. Folsom needs some work to handle
    crashing owners better. Some table in folsom are owned
    by the creating process, and some by folsom. If riak_core_stat
    crashes some folsom can be left inconsistent. This cleans up
    at start time.
Commits on Jul 18, 2012
  1. @jaredmorrow
Commits on Jul 17, 2012
  1. @russelldb

    Merge pull request #210 from basho/rdb-stat-crash

    russelldb committed
    Don't crash the cache when a stat mod crashes
Something went wrong with that request. Please try again.