I guess I was thinking that in the future we *maybe* implement a
GetMultiRetry() or something similar where if there's a timeout, it'll
automagically retry the request.  What Symonds was talking about was
limiting variance, controlling the outlying slow RPC call.  If one call to
the datastore is slow, the next call may be fast and actually beat the
first one... that was my thought process.  By returning a standard
"timeout" error, applications can put that code into their process.  E.g.,
if it's taking too long to store in the datastore in real-time, I'll put it
into a Task instead...


On Wed, Jan 15, 2014 at 1:36 PM, Matt Jibson <notifications@github.com>wrote:

> In goon.go:
>
> >  )
> >
> >  // Goon holds the app engine context and request memory cache.
> >  type Goon struct {
> > -	context       appengine.Context
> > -	cache         map[string]interface{}
> > -	cacheLock     sync.RWMutex // protect the cache from concurrent goroutines to speed up RPC access
> > -	inTransaction bool
> > -	toSet         map[string]interface{}
> > -	toDelete      map[string]bool
> > +	context             appengine.Context
> > +	cache               map[string]interface{}
> > +	cacheLock           sync.RWMutex // protect the cache from concurrent goroutines to speed up RPC access
> > +	inTransaction       bool
> > +	toSet               map[string]interface{}
> > +	toDelete            map[string]bool
> > +	MemcachePutTimeout  time.Duration //  can be set to 0 to enable concurrent fetching from memcache & datastore
> > +	MemcacheGetTimeout  time.Duration
> > +	DatastorePutTimeout time.Duration
>
> Correct. The entire and sole purpose is to prevent memcache slowness from
> slowing the request. If the datastore is slow, well, we still have to store
> or fetch our data, so we wait.
>
> —
> Reply to this email directly or view it on GitHub<https://github.com/mjibson/goon/pull/17/files#r8906432>
> .
>