Sporadic bursts of errors, but no error information from c# driver, how do we diagnose?

[Tom DeMille]

A few times a day we get a 'burst' of errors. The C# driver doesn't
really report the reason, we just log it from our own error handler.
After 500 errors within 5 seconds we disable the caching layer for 5
minutes. So we see these spikes 2 or 3 times a day of 500 errors.

I'm guessing it's timeouts but not sure how we go about finding out
for sure.

[John Zablocki]

Hi Tom,

What version of the C# library are you using? Starting with 1.1,
there is a new API that returns more details that true/false. See the
ExecuteXXX methods @ http://www.couchbase.com/docs/couchbase-sdk-net-1.1/api-overview.html.

You also might want to try enabling logging:

http://www.couchbase.com/docs/couchbase-sdk-net-1.1/couchbase-sdk-net-logging.html

The logging assemblies are available for download @
http://www.couchbase.com/develop/net/current.

-- John

[Tom DeMille]

I heard that the logging is a performance killer? We can take a
5-10% performance degradation for a day, that sound reasonable or is
it a complete performance killer?

enyim.caching is version 2.12.0.0
couchbase is 1.0

On Jun 7, 8:31 am, John Zablocki <j...@zblock.net> wrote:
> Hi Tom,
>
> What version of the C# library are you using?  Starting with 1.1,
> there is a new API that returns more details that true/false.  See the

> ExecuteXXX methods @http://www.couchbase.com/docs/couchbase-sdk-net-1.1/api-overview.html.

>
> You also might want to try enabling logging:
>

> http://www.couchbase.com/docs/couchbase-sdk-net-1.1/couchbase-sdk-net...
>
> The logging assemblies are available for download @http://www.couchbase.com/develop/net/current.

[Tom DeMille]

Also, why are the called ExecuteXX, does that imply async execution,
or a different form of execution?

On Jun 7, 12:54 pm, Tom DeMille <tdemi...@gmail.com> wrote:
> I heard that the logging is a performance killer?   We can take a
> 5-10% performance degradation for a day, that sound reasonable or is
> it a complete performance killer?
>
> enyim.caching is version 2.12.0.0

> Why couchbase is 1.0

[Tom DeMille]

Can't find any code examples on how to use the ExecuteXXX methods, for
instance do you do something like this? Check .Success, and then grab
the error if .Success is not true?


var retVal = BoomTownCache.ExecuteStore(StoreMode.Set,
key, item, defaultValidFor);

if (!retVal.Success)
var errStr = retVal.Exception.ToString()

[Matt Ingenthron]

On 6/7/12 10:46 AM, "Tom DeMille" <tdem...@gmail.com> wrote:

>Can't find any code examples on how to use the ExecuteXXX methods, for
>instance do you do something like this? Check .Success, and then grab
>the error if .Success is not true?

See the docs:
http://www.couchbase.com/docs/couchbase-sdk-net-1.1/couchbase-sdk-net-retri
eve-set.html

--
Matt Ingenthron - Director, Developer Solutions
Couchbase, Inc.

[Tom DeMille]

thanks found that, can't find documentation for executeTryGet..




On Jun 7, 1:49 pm, Matt Ingenthron <m...@couchbase.com> wrote:

> On 6/7/12 10:46 AM, "Tom DeMille" <tdemi...@gmail.com> wrote:
>
> >Can't find any code examples on how to use the ExecuteXXX methods, for
> >instance do you do something like this?  Check .Success, and then grab
> >the error if .Success is not true?
>

> See the docs:http://www.couchbase.com/docs/couchbase-sdk-net-1.1/couchbase-sdk-net...

[Tom DeMille]

would I check .success first and then if .success check .Value for the
boolean normally returned from TryGet?

On Jun 7, 1:49 pm, Matt Ingenthron <m...@couchbase.com> wrote:

> On 6/7/12 10:46 AM, "Tom DeMille" <tdemi...@gmail.com> wrote:
>
> >Can't find any code examples on how to use the ExecuteXXX methods, for
> >instance do you do something like this?  Check .Success, and then grab
> >the error if .Success is not true?
>

> See the docs:http://www.couchbase.com/docs/couchbase-sdk-net-1.1/couchbase-sdk-net...

[Matt Ingenthron]

Sorry Tom, I read the thread backwards. I see John had already replied
with a pointer to the docs.

On 6/7/12 10:49 AM, "Matt Ingenthron" <ma...@couchbase.com> wrote:

>On 6/7/12 10:46 AM, "Tom DeMille" <tdem...@gmail.com> wrote:
>
>>Can't find any code examples on how to use the ExecuteXXX methods, for
>>instance do you do something like this? Check .Success, and then grab
>>the error if .Success is not true?
>
>See the docs:
>http://www.couchbase.com/docs/couchbase-sdk-net-1.1/couchbase-sdk-net-retr
>i
>eve-set.html

The main point of the ExecuteXXX methods is to give more information in
the event an operation was not successful. It returns an
IStoreOperationResult which has much more information.

You do describe it correctly above. If the operation is not successful,
what you do after that is really application dependent. In many cases
you'll return an error up the chain, in some cases, you won't care, in the
event of a tempfail (happens if you overwhelm your cluster) you will want
to backoff and retry if you really want it to go in.

There's a (sorry, Java) example of backoff and retry here:
http://www.couchbase.com/wiki/display/couchbase/Couchbase+Java+Client+Libra
ry#CouchbaseJavaClientLibrary-RetryingWhenReceivingaTempfail


It should be pretty straightforward to translate to .NET [or maybe John
can put an equivalent up on the wiki :)]

Hope that helps,

Matt

[Tom DeMille]

the ExecuteTryGet is not implemented correctly. TryGet normally
returns a boolean. This implementation returns the Value of the
object in the cache(if successful).

The implementation should return the boolean that TryGet would
normally return that indicates if their is an object in the cache, it
renders ExecuteTryGet exactly the same as ExecuteGet

[John Zablocki]

Logging is done either by NLog or Log4Net (your choice). Both perform
well, but yes, relative to the the standard performance you'll
probably see performance degrade. I don't have exact metrics, but
I've used NLog with high traffic sites before and the hit was
negligible. 5% does sound reasonable.

[John Zablocki]

I worked out with Attila who owns the Enyim.Caching library that I
wouldn't break the existing interface. The CouchbaseClient is heavily
dependent on that code, so certain naming compromises had to made .
The alternative was to have a great deal of code duplication - most of
the standard API methods come by way of the base MemcachedClient
class.

[John Zablocki]

I agree with your assertion. I was initially attempting to provide an
equivalent ExecuteXXX method for each of the public API methods that
already existed. It probably was overkill and misleading in this
case.

[Tom DeMille]

Thanks John,

one more question, I'm getting a CAS value back with the ExecuteXX
methods, but I'm not using CAS functionality, is that expected?

[Tom DeMille]

I'm having a really hard time figuring out what to expect from the
execute methods, for instance:

My cache is up and operating fine, but certain calls, I'm getting
retVal.Success = false.

Am I correct in assuming that .Success means there was NOT an error?
Or does .Success mean there was no data?

I'm seeing

.Success False
.Exception = null
.Message = Unable to locate Node

I would expect when .Success if false that .Exception would contain a
value?


Perhaps I'm incorrect in my assumptions as to the return values.

How would I check

1. for an error?
2. if the value exists in the cache


my code basically wants to first make sure we don't have any cache
related errors (cache down, etc.)
then I want to check to see if a value was returned from the cache

[Chad Kouse]

I think the CAS value comes back from a gets command so it sounds like they are defaulting to use gets instead of get? 

-- 

Chad Kouse

[Matt Ingenthron]

No, the modern protocol (meaning, binary instead of ASCII) always returns the CAS value.  This client exposes it.  It should just be a couple bytes of garbage to be collected if not used.

Tom: you can simply ignore the CAS if you're not going to perform a CAS operation.

[Chad Kouse]

I never claimed to be a modern man.. thanks for clarifying 

-- 

Chad Kouse

[John Zablocki]

If you're getting an "Unable to locate node" error that most likely
means the client isn't able to reach the node that owns a particular
key. There are at least two scenarios that could cause that. The
most obvious cause is bad configuration, which would lead to failures
across the board - so that's unlikely. The other scenario is more
likely and that is the node was temporarily unavailable. If you have
logging enabled, you should see this reflected in the messages.

The Success == false result with no exception is due to the fact that
Enyim.Caching doesn't throw an exception for this condition because it
should be temporary. I'll try to get some code up in the wiki to
mirror what Matt had previously posted. To diagnose the possible node
issues, you could check the server logs or the Enyim client logs.

If Success is false, you should see that Value is null and HasValue is
false for that request. If the client couldn't get the request to the
node, that would be the condition. Now, that also could mean that the
cached item is still there and a subsequent request could read it just
fine. If Success == true and the Value is null, that's an indication
that the server value is null.

I'll try to document this all better on the wiki today...

[Tom DeMille]

would this be an appropriate way to check for an error using the
IStor4eOperationalResult returned value?

public bool ErrorOccurred(IStoreOperationResult retVal)
{
if (!retVal.Success)
{
if (retVal.Exception != null)
return true;
else
return false;
}

return false;