[NCBC-78] Enhance discussion of return codes/values Created: 26/Jun/12 Updated: 07/Dec/12 |
|
| Status: | Open |
| Project: | Couchbase .NET client library |
| Component/s: | docs |
| Affects Version/s: | 1.1.6 |
| Fix Version/s: | 1.3 |
| Type: | Bug | Priority: | Blocker |
| Reporter: | Perry Krug | Assignee: | John Zablocki |
| Resolution: | Unresolved | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Description |
|
Given the comments on this page: http://www.couchbase.com/docs/couchbase-sdk-net-1.1/couchbase-sdk-net-retrieve-set.html
Perhaps there can be a section on the possible return codes/values, what they mean, when they might happen, and how to deal with them? |
| Comments |
| Comment by Mark Nunberg [ 22/Nov/12 ] |
|
This is a must-have for SDK testing. It is very difficult to determine failure types and severities without knowing what types of errors, exception classes, or such to expect.
At the very least, there should be standard return codes (in a well-defined location) for memcached error codes. |
[NCBC-126] Implement keep-alive logic for data connections Created: 27/Sep/12 Updated: 28/Nov/12 |
|
| Status: | Open |
| Project: | Couchbase .NET client library |
| Component/s: | library |
| Affects Version/s: | 1.1.6 |
| Fix Version/s: | 1.3 |
| Type: | Improvement | Priority: | Major |
| Reporter: | Perry Krug | Assignee: | John Zablocki |
| Resolution: | Unresolved | Votes: | 1 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Description |
|
A customer has been experiencing connection resets due to a firewall in place between the application servers and Couchbase closing idle connections.
While we have a heartbeat on 8091, we do not for 11210. This is necessary to prevent the firewall from seeing these connections as idle. |
| Comments |
| Comment by Alejandro [ 28/Nov/12 ] |
| Will this fix be also implemented for Java libraries? |
[NCBC-120] Statistics through Stats() Enyim.Caching.MemcachedClient. Created: 17/Sep/12 Updated: 05/Oct/12 |
|
| Status: | Open |
| Project: | Couchbase .NET client library |
| Component/s: | library |
| Affects Version/s: | 1.1.6 |
| Fix Version/s: | 1.3 |
| Type: | New Feature | Priority: | Major |
| Reporter: | Alex Ma | Assignee: | John Zablocki |
| Resolution: | Unresolved | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Description |
|
User is collecting statistics and would like to collect some of the histogram type data that is available for specific stats through cbstats timings. Particularly: "disk_insert" and "item_alloc_sizes" with the Stats command to get data as described in 2.5 Timing Stats for link: https://github.com/membase/ep-engine/blob/master/docs/stats.org. They would like to be able to do this through Enyim.Caching.dll as it is already used by their "Core" code so they support statistics gathering with what that interface offers and like its simplicity. Currently the dll support memcached specific stats but not ep-engine. Enhancment request is to expand the functionality of the stats call in Enyim.Caching |
[NCBC-113] CouchbaseCluster RESTful wrappers should not expose WebExceptions Created: 05/Sep/12 Updated: 08/Oct/12 |
|
| Status: | Open |
| Project: | Couchbase .NET client library |
| Component/s: | library |
| Affects Version/s: | 1.2 DP3 |
| Fix Version/s: | 1.3 |
| Type: | Improvement | Priority: | Major |
| Reporter: | John Zablocki | Assignee: | John Zablocki |
| Resolution: | Unresolved | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
[NCBC-101] Provide Consistent Timeouts Created: 24/Aug/12 Updated: 05/Oct/12 |
|
| Status: | Open |
| Project: | Couchbase .NET client library |
| Component/s: | None |
| Affects Version/s: | None |
| Fix Version/s: | 1.3 |
| Type: | Improvement | Priority: | Major |
| Reporter: | Karen Zeller | Assignee: | John Zablocki |
| Resolution: | Unresolved | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Description |
|
Provides the consistent level of time outs with other SDKs. Provide ability to set timeouts at: 1) connection, 2) authentication, and 3) ops level.
|
[NCBC-100] Provide Extract of Comments for API Docs Created: 24/Aug/12 Updated: 05/Oct/12 |
|
| Status: | Open |
| Project: | Couchbase .NET client library |
| Component/s: | None |
| Affects Version/s: | None |
| Fix Version/s: | 1.3 |
| Type: | Improvement | Priority: | Major |
| Reporter: | Karen Zeller | Assignee: | John Zablocki |
| Resolution: | Unresolved | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Description |
|
Need to be able to generate extract of comments, preferrably including method signatures for .NET
|
[NCBC-99] Provide Error Handling Consistent with Other SDKs Created: 24/Aug/12 Updated: 05/Oct/12 |
|
| Status: | Open |
| Project: | Couchbase .NET client library |
| Component/s: | None |
| Affects Version/s: | None |
| Fix Version/s: | 1.3 |
| Type: | Task | Priority: | Major |
| Reporter: | Karen Zeller | Assignee: | John Zablocki |
| Resolution: | Unresolved | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Description |
|
Provide Error Handling Consistent with Other SDKs and underlying protocol.
|
| Comments |
| Comment by Matt Ingenthron [ 24/Aug/12 ] |
|
Karen: there are a number of specific bugs filed and work underway on this, planned for 1.1.7. Given the context, I don't know if they'll ever be perfectly consistent, but that's okay.
Was there something specific you were concerned with here? |
[NCBC-97] Stats call doesn't handle I/O error Created: 20/Aug/12 Updated: 05/Oct/12 |
|
| Status: | Open |
| Project: | Couchbase .NET client library |
| Component/s: | library |
| Affects Version/s: | 1.1.6 |
| Fix Version/s: | 1.3 |
| Type: | Bug | Priority: | Major |
| Reporter: | Tim Smith | Assignee: | John Zablocki |
| Resolution: | Unresolved | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Environment: | Couchbase Client 1.1.6, server 1.8.0 build 55 | ||
| Description |
|
Repeat as follows:
- Call to MemcachedClient.Stats(type) - This builds a StatsOperation for each node and asynchronously performs MemcachedNode.Execute(cmd) - An I/O error occurs, so StatsOperation leaves its member "results" as null and Execute returns false to indicate an error - MemcachedClient ignores the returned Boolean value from EndInvoke and puts a null dictionary into its own set of results - ServerStats.GetRaw(key) dies trying to select into the missing dictionary Plausible fix: check the status from EndInvoke and don't stick anything in the dictionary if there was an error. |
| Comments |
| Comment by Tim Smith [ 20/Aug/12 ] |
| Example of how it's called: mc.Stats().GetRaw("uptime"); result is NullReferenceException.... |
[NCBC-81] ExecuteGet() for DictionaryType on multiple keys does not throw a exception if it is not able to connect to a node Created: 28/Jun/12 Updated: 05/Oct/12 |
|
| Status: | Open |
| Project: | Couchbase .NET client library |
| Component/s: | library |
| Affects Version/s: | 1.1.6 |
| Fix Version/s: | 1.3 |
| Type: | Bug | Priority: | Major |
| Reporter: | Alex Ma | Assignee: | John Zablocki |
| Resolution: | Unresolved | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Description |
|
For development purposes i'm using a local Couchbase server installation with a single node. So i guess that turning off the CouchbaseServer service means the whole cluster in my case.
Here's a simple demo code: System.Configuration.Configuration cfg = ConfigurationManager.OpenExeConfiguration(ConfigurationUserLevel.None); ICouchbaseClientConfiguration section = cfg.GetSection("Couchbase") as ICouchbaseClientConfiguration; using (CouchbaseClient client = new CouchbaseClient(section)) { IOperationResult res = client.ExecuteStore(Enyim.Caching.Memcached.StoreMode.Set, "Test1", 1); Console.WriteLine("Set1 Success:{0} StatusCode:{1} Message:{2}", res.Success, res.StatusCode, res.Message); res = client.ExecuteStore(Enyim.Caching.Memcached.StoreMode.Set, "Test2", 2); Console.WriteLine("Set2 Success:{0} StatusCode:{1} Message:{2}", res.Success, res.StatusCode, res.Message); IDictionary<string, IGetOperationResult> multigetRes = client.ExecuteGet(new string[] { "Test1", "Test2" }); Console.WriteLine("Dictionary count: {0}", multigetRes.Count); foreach (KeyValuePair<string, IGetOperationResult> kvp in multigetRes) { Console.WriteLine("Get {0} Success:{1}, StatusCode: {2} Message: {3}", kvp.Key, kvp.Value.Success, kvp.Value.StatusCode, kvp.Value.Message); } } Output with CouchbaseServer service on: Set1 Success:True StatusCode:0 Message: Set2 Success:True StatusCode:0 Message: Dictionary count: 2 Get Test1 Success:True, StatusCode: Message: Get Test2 Success:True, StatusCode: Message: Output with CouchbaseServer service off: Set1 Success:False StatusCode: Message:Failed to locate node Set2 Success:False StatusCode: Message:Failed to locate node Dictionary count: 0 Singular gets result in the correct exception error message: Modified demo: System.Configuration.Configuration cfg = ConfigurationManager.OpenExeConfiguration(ConfigurationUserLevel.None); ICouchbaseClientConfiguration section = cfg.GetSection("Couchbase") as ICouchbaseClientConfiguration; using (CouchbaseClient client = new CouchbaseClient(section)) { IOperationResult res = client.ExecuteStore(Enyim.Caching.Memcached.StoreMode.Set, "Test1", 1); Console.WriteLine("Set1 Success:{0} StatusCode:{1} Message:{2}", res.Success, res.StatusCode, res.Message); res = client.ExecuteStore(Enyim.Caching.Memcached.StoreMode.Set, "Test2", 2); Console.WriteLine("Set2 Success:{0} StatusCode:{1} Message:{2}", res.Success, res.StatusCode, res.Message); IDictionary<string, IGetOperationResult> multigetRes = client.ExecuteGet(new string[] { "Test1", "Test2" }); Console.WriteLine("Dictionary count: {0}", multigetRes.Count); foreach (KeyValuePair<string, IGetOperationResult> kvp in multigetRes) { Console.WriteLine("MultiGet {0} Success:{1}, StatusCode: {2} Message: {3}", kvp.Key, kvp.Value.Success, kvp.Value.StatusCode, kvp.Value.Message); } res = client.ExecuteGet("Test1"); Console.WriteLine("Get1 Success:{0} StatusCode:{1} Message:{2}", res.Success, res.StatusCode, res.Message); res = client.ExecuteGet("Test2"); Console.WriteLine("Get2 Success:{0} StatusCode:{1} Message:{2}", res.Success, res.StatusCode, res.Message); } Output: Set1 Success:False StatusCode: Message:Failed to locate node Set2 Success:False StatusCode: Message:Failed to locate node Dictionary count: 0 Get1 Success:False StatusCode: Message:Unable to locate node Get2 Success:False StatusCode: Message:Unable to locate node |
[NCBC-58] Way to determine which Servers are active Created: 05/Jun/12 Updated: 18/Feb/13 |
|
| Status: | Open |
| Project: | Couchbase .NET client library |
| Component/s: | None |
| Affects Version/s: | None |
| Fix Version/s: | 1.3 |
| Type: | Improvement | Priority: | Major |
| Reporter: | James Mauss | Assignee: | John Zablocki |
| Resolution: | Unresolved | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Description |
|
Can there a way to determine if there are no available Couchbase servers?
There should be someway to check the status of the cluster from the Client. |
| Comments |
| Comment by Hari Subramaniam [ 28/Jun/12 ] |
|
along same lines, another customer requests enhancement to the .NET client to include the following methods
getUnavailableServers getAvailableServers These methods are already available in the Couchbase JAVA SDK. Would like .NET SDK to provide the same functionality |
| Comment by Matt Ingenthron [ 12/Feb/13 ] |
| This RFE will remain open for that. |
[NCBC-44] Optimize multiple set (multi-set or mset bulk update) with setq Created: 21/May/12 Updated: 05/Oct/12 |
|
| Status: | Open |
| Project: | Couchbase .NET client library |
| Component/s: | library |
| Affects Version/s: | 1.1 |
| Fix Version/s: | 1.3 |
| Type: | New Feature | Priority: | Major |
| Reporter: | Tim Smith | Assignee: | John Zablocki |
| Resolution: | Unresolved | Votes: | 0 |
| Labels: | customer | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Description |
|
The Java client, and others, implement a more efficient bulk loading feature when multiple updates are sent to the cluster at one time. They use setq to send multiple requests without needing to round-trip the result after each one.
The .NET client does not implement this; it only implements a multi-get operation. The multi-set is important for efficiently loading data. This probaby doesn't have to be Couchbase-specific, but would apply to vanilla memcached servers, too. |
| Comments |
| Comment by Tim Smith [ 21/May/12 ] |
|
To be clear, I'm talking about the kind of optimization described here:
http://dustin.github.com/2009/09/23/spymemcached-optimizations.html Thanks, Tim |
[NCBC-18] deploying to download locations directly from CI Created: 12/Jan/12 Updated: 05/Oct/12 |
|
| Status: | Open |
| Project: | Couchbase .NET client library |
| Component/s: | None |
| Affects Version/s: | None |
| Fix Version/s: | 1.3 |
| Type: | Task | Priority: | Major |
| Reporter: | Matt Ingenthron | Assignee: | John Zablocki |
| Resolution: | Unresolved | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Description |
|
The idea here is that interim builds, as they come through code review, generate artifacts and upload to a given location. If they're actual release builds, they upload to a different location. This could also go to nuget, if appropriate.
|
[NCBC-17] building shippable artifacts under CI Created: 12/Jan/12 Updated: 05/Oct/12 |
|
| Status: | Open |
| Project: | Couchbase .NET client library |
| Component/s: | None |
| Affects Version/s: | None |
| Fix Version/s: | 1.3 |
| Type: | Task | Priority: | Major |
| Reporter: | Matt Ingenthron | Assignee: | John Zablocki |
| Resolution: | Unresolved | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
[NCBC-16] running integration tests under CI Created: 12/Jan/12 Updated: 05/Oct/12 |
|
| Status: | Open |
| Project: | Couchbase .NET client library |
| Component/s: | None |
| Affects Version/s: | None |
| Fix Version/s: | 1.3 |
| Type: | Task | Priority: | Major |
| Reporter: | Matt Ingenthron | Assignee: | John Zablocki |
| Resolution: | Unresolved | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
[NCBC-14] building under CI Created: 12/Jan/12 Updated: 05/Oct/12 |
|
| Status: | In Progress |
| Project: | Couchbase .NET client library |
| Component/s: | None |
| Affects Version/s: | None |
| Fix Version/s: | 1.3 |
| Type: | Task | Priority: | Major |
| Reporter: | Matt Ingenthron | Assignee: | John Zablocki |
| Resolution: | Unresolved | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Comments |
| Comment by John Zablocki [ 13/Jan/12 ] |
| Currently building under CI. |
[NCBC-13] generating shippable artifacts Created: 12/Jan/12 Updated: 05/Oct/12 |
|
| Status: | Open |
| Project: | Couchbase .NET client library |
| Component/s: | None |
| Affects Version/s: | None |
| Fix Version/s: | 1.3 |
| Type: | Task | Priority: | Major |
| Reporter: | Matt Ingenthron | Assignee: | John Zablocki |
| Resolution: | Unresolved | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
[NCBC-15] running unit tests under CI Created: 12/Jan/12 Updated: 17/May/13 |
|
| Status: | Open |
| Project: | Couchbase .NET client library |
| Component/s: | None |
| Affects Version/s: | None |
| Fix Version/s: | 1.3 |
| Type: | Task | Priority: | Major |
| Reporter: | Matt Ingenthron | Assignee: | Saakshi Manocha |
| Resolution: | Unresolved | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Comments |
| Comment by Matt Ingenthron [ 17/May/13 ] |
| Perhaps you have this one done? |
[NCBC-183] Docs should use Execute* methods with best practice error handling and logging in all examples Created: 14/Dec/12 Updated: 17/May/13 |
|
| Status: | Open |
| Project: | Couchbase .NET client library |
| Component/s: | docs |
| Affects Version/s: | 1.2.0 |
| Fix Version/s: | 1.3 |
| Type: | Improvement | Priority: | Major |
| Reporter: | Tim Smith | Assignee: | John Zablocki |
| Resolution: | Unresolved | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | 24h | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | 24h | ||
| Environment: | http://www.couchbase.com/docs/couchbase-sdk-net-1.2/crud.html | ||
| Description |
|
While proper error handling may be application-specific (some apps may be fine treating any error as "not found", while others need to handle those as very distinct cases, for example), I think the documentation the docs provide, and especially the tutorials and examples that people are likely to copy from, should perform explicit and thorough error handling and logging. Docs should make it easy for people to do it the right way.
The current .NET docs have an OK example in the ASP.NET tutorial, where at least the return value is checked and exceptions are rethrown. So that's a good start, although there's no evidence of testing result.Success (which could be false, even if result.Exception is null). There's no mention, too, of what happens higher up when the result code is returned, and no logging of errors that folks can cut and paste. http://www.couchbase.com/docs/couchbase-sdk-net-1.2/brewerycrud.html One method uses this: return result.StatusCode.HasValue ? result.StatusCode.Value : 0; While the others just return result.StatusCode.Value with no test. Why is that? Where is that documented? Then this example uses the non-Execute versions which don't allow for proper error handling. That may be OK in a very basic tutorial, but there should be a very clear and explicit pointer anywhere these are used that goes to a "Error handling with the .NET client" page that details why you shouldn't use those in most production code, and that you'll have a very hard time writing correct code unless you use the Execute* methods, and that also provides succinct and complete example for cut-and-pastability of correct error handling. Even so, I'd prefer that the basic "hello world" tutorial use Execute* methods in the first place, so people who only skim the docs only see the correct way to do things. http://www.couchbase.com/docs/couchbase-sdk-net-1.2/crud.html |
| Comments |
| Comment by Matt Ingenthron [ 17/May/13 ] |
| This is probably not something we want to do as written. We want the simple approach to be, well, simple. Future API will hopefully make this better. |
[NCBC-219] Write the .NET/Windows Getting Started Section for the Essentials Guides Created: 04/Feb/13 Updated: 17/May/13 |
|
| Status: | Open |
| Project: | Couchbase .NET client library |
| Component/s: | None |
| Affects Version/s: | None |
| Fix Version/s: | 1.3 |
| Type: | Task | Priority: | Major |
| Reporter: | MC Brown | Assignee: | John Zablocki |
| Resolution: | Unresolved | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Description |
|
Write the .NET/Windows Getting Started section of the Essentials Guide
Needs to cover: Basic Setup of the .NET environment Adding the .NET Client library to a project Writing your first (small) app using Couchbase and .NET Submissions should be to MC, either through the couchbase/docs repo, or direct to MC in whatever format suits. Must include both the text and images. |
[NCBC-242] ExecuteGet-multi should return detailed status results for each key Created: 27/Mar/13 Updated: 17/May/13 |
|
| Status: | Open |
| Project: | Couchbase .NET client library |
| Component/s: | None |
| Affects Version/s: | 1.2.4 |
| Fix Version/s: | 1.3 |
| Type: | Task | Priority: | Major |
| Reporter: | John Zablocki | Assignee: | John Zablocki |
| Resolution: | Unresolved | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
[NCBC-29] programmatically set all the Couchbase configurations Created: 07/Mar/12 Updated: 17/May/13 |
|
| Status: | Open |
| Project: | Couchbase .NET client library |
| Component/s: | None |
| Affects Version/s: | None |
| Fix Version/s: | 1.3 |
| Type: | New Feature | Priority: | Major |
| Reporter: | James Mauss | Assignee: | John Zablocki |
| Resolution: | Unresolved | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Description |
|
We can programmatically set some the Couchbase configurations, however we cannot set the SocketPool settings Programmatically.
These settings can be set in the config file, but it would be nice to be able to set these through the program. |
[NCBC-188] Provide file based caching of config for stateless .NET apps Created: 21/Dec/12 Updated: 17/May/13 |
|
| Status: | Open |
| Project: | Couchbase .NET client library |
| Component/s: | None |
| Affects Version/s: | None |
| Fix Version/s: | 1.3 |
| Type: | New Feature | Priority: | Major |
| Reporter: | John Zablocki | Assignee: | John Zablocki |
| Resolution: | Unresolved | Votes: | 1 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Description |
|
With stateless apps, such as WCF, it's not possible to create a static client variable that is used across the lifetime of the app. An alternate approach would be to write config to a file and update it periodically instead of bootstrapping with each object creation.
|
[NCBC-175] Authenticated view tests should use app.config Created: 07/Dec/12 Updated: 17/May/13 |
|
| Status: | Open |
| Project: | Couchbase .NET client library |
| Component/s: | None |
| Affects Version/s: | 1.2 Beta-3, 1.2.0 |
| Fix Version/s: | 1.3 |
| Type: | Bug | Priority: | Major |
| Reporter: | John Zablocki | Assignee: | John Zablocki |
| Resolution: | Unresolved | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
[NCBC-233] Enhance packaging to not conflict with other tools that include Enyim.Caching via Nuget Created: 26/Feb/13 Updated: 08/May/13 |
|
| Status: | Open |
| Project: | Couchbase .NET client library |
| Component/s: | library |
| Affects Version/s: | 1.2.1 |
| Fix Version/s: | 1.3 |
| Type: | Improvement | Priority: | Minor |
| Reporter: | Perry Krug | Assignee: | John Zablocki |
| Resolution: | Unresolved | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||
| Description |
|
The CouchbaseClient nuget package includes Enyim.Caching which causes compatibility issues with 3rd party applications also relying on the Enyim.Caching assembly.
The third party tool we were looking at using was ServiceStack's Caching interface, specifically the Memcached client implementation. This tool was where were were getting the conflict as they include the Enyim.Caching assembly as a nuget dependency. See also http://www.couchbase.com/issues/browse/CBSE-412 |
| Comments |
| Comment by Sergey Avseyev [ 25/Apr/13 ] |
|
Not sure if it is related, but IMHO it is http://www.couchbase.com/forums/thread/please-use-nuget-correctly > Your NuGet packages have several problems. > 1. You take binary dependencies on other things which are available via NuGet, but you're shipping those binaries yourself. You should be taking a package dependency instead, so that things can be referenced and versioned correctly. > 2. Your "Couchbase with Logging" package should be an additive package that takes a package dependency on your "Couchbase" package, rather than shipping an entirely separate copy of the assembly. This causes linking conflicts. Probably it worth to increase priority of this issue |
| Comment by Sergey Avseyev [ 25/Apr/13 ] |
|
http://www.couchbase.com/forums/thread/please-stop-using-private-build-restsharp-couchbase-net-client > You are currently shipping an unsigned but otherwise identically named DLL called RestSharp, which conflicts with anybody who actually uses the real shipping version of RestSharp. > Either use the signed production version of RestSharp, or else rename the assembly so it does not collide with the real version of RestSharp. |
| Comment by John Zablocki [ 25/Apr/13 ] |
|
This is actually being addressed in |
[NCBC-135] Client not properly handling cluster_run server Created: 03/Oct/12 Updated: 17/May/13 |
|
| Status: | Open |
| Project: | Couchbase .NET client library |
| Component/s: | library |
| Affects Version/s: | 1.2 Beta |
| Fix Version/s: | 1.3 |
| Type: | Bug | Priority: | Minor |
| Reporter: | Mark Nunberg | Assignee: | John Zablocki |
| Resolution: | Unresolved | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Environment: | Using cluster_run from branch-2.0 xml | ||
| Description |
|
I can't do simple things like get/set stuff..
PS C:\Users\Administrator\Documents\GitHub\cbc-net\src\CbcNet\bin\Debug> .\cbc-net.exe -c set -k foo -V bar -H 10.0.0.99 :8091; .\cbc-net.exe -c get -k foo -H 10.0.0.99:8091 URI: http://10.0.0.99:8091/pools http://10.0.0.99:8091/pools Created new client.. Arguments to ExecuteStore: 0x00000003, 'foo', 'bar', 00:00:00, Zero, Zero Operation Succeeded. Cas: 610018894666114 Duration was 3.07 Sec. URI: http://10.0.0.99:8091/pools http://10.0.0.99:8091/pools Created new client.. Command OK Value is bar Cas is 610018894666114 Duration was 3.09 Sec. PS C:\Users\Administrator\Documents\GitHub\cbc-net\src\CbcNet\bin\Debug> echo "hi" | C:\Users\Administrator\Documents\Gi tHub\deps\bin\cbc.exe create -h 10.0.0.99 foo2 PS C:\Users\Administrator\Documents\GitHub\cbc-net\src\CbcNet\bin\Debug> # Now with the cluster_run cluster PS C:\Users\Administrator\Documents\GitHub\cbc-net\src\CbcNet\bin\Debug> .\cbc-net.exe -c set -k foo -V bar -H 10.0.0.99 :9000; .\cbc-net.exe -c get -k foo -H 10.0.0.99:9000 URI: http://10.0.0.99:9000/pools http://10.0.0.99:9000/pools Created new client.. Arguments to ExecuteStore: 0x00000003, 'foo', 'bar', 00:00:00, Zero, Zero Initial command failed (Store operation failed, see InnerResult or StatusCode for details). Trying simple version.. .. Inner Message: Failed to execute operation Command Failed Code is 0 Message is Store operation failed, see InnerResult or StatusCode for details Duration was 3.02 Sec. URI: http://10.0.0.99:9000/pools http://10.0.0.99:9000/pools Created new client.. Command Failed Code is Message is Unable to locate node Duration was 3.05 Sec. PS C:\Users\Administrator\Documents\GitHub\cbc-net\src\CbcNet\bin\Debug> ## This works fine with libcouchbase: PS C:\Users\Administrator\Documents\GitHub\cbc-net\src\CbcNet\bin\Debug> PS C:\Users\Administrator\Documents\GitHub\cbc-net\src\CbcNet\bin\Debug> PS C:\Users\Administrator\Documents\GitHub\cbc-net\src\CbcNet\bin\Debug> echo "hi" | C:\Users\Administrator\Documents\Gi tHub\deps\bin\cbc.exe create -h 10.0.0.99:9000 foo2 Stored "foo2" CAS:911342e1e62a0200 PS C:\Users\Administrator\Documents\GitHub\cbc-net\src\CbcNet\bin\Debug> C:\Users\Administrator\Documents\GitHub\deps\bi n\cbc.exe cat -h 10.0.0.99:9000 foo2 "foo2" Size:3 Flags:0 CAS:911342e1e62a0200 hi PS C:\Users\Administrator\Documents\GitHub\cbc-net\src\CbcNet\bin\Debug> |
| Comments |
| Comment by Mark Nunberg [ 03/Oct/12 ] |
| Currently this forces me to run tests against a remote cluster with .net. It would be nice to have the ability to run these tests locally via 'cluster_run' |
| Comment by Mark Nunberg [ 03/Oct/12 ] |
| fyi, it seems from running tcpdump that it's connecting to the rest server and also connecting to some memcached port.. but the op still fails.. |
[NCBC-207] Could not find the pool '...' at http://host:8091/pools : password-less buckets make the other buckets unavailable Created: 17/Jan/13 Updated: 17/May/13 |
|
| Status: | Open |
| Project: | Couchbase .NET client library |
| Component/s: | None |
| Affects Version/s: | None |
| Fix Version/s: | 1.3 |
| Type: | Bug | Priority: | Minor |
| Reporter: | guillaume.pitel | Assignee: | John Zablocki |
| Resolution: | Unresolved | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Environment: | Mono 2.10.8.1 (Debian 2.10.8.1-1ubuntu2.2) Ubuntu 12.04 / Couchbase server 2.0 | ||
| Description |
|
Hi, we stumbled on a minor bug.
After importing the beer bucket for testing purpose, we had this kind of errors : (Couchbase .Net 1.2 / mono client) 2013-01-17 11:13:28 [DEBUG] 1 Couchbase.MessageStreamListener - Starting the listener. Queue=True 2013-01-17 11:13:28 [DEBUG] 11 Couchbase.MessageStreamListener - Started working. 2013-01-17 11:13:28 [DEBUG] 11 Couchbase.MessageStreamListener - Looking for the first working node. 2013-01-17 11:13:29 [WARN] 11 Couchbase.ConfigHelper - Could not find the pool 'static' at http://10.1.44.1:8091/pools 2013-01-17 11:13:29 [WARN] 11 Couchbase.MessageStreamListener - Could not resolve url http://10.1.44.1:8091/pools; trying the next in the list 2013-01-17 11:13:29 [WARN] 11 Couchbase.ConfigHelper - Could not find the pool 'static' at http://10.1.44.2:8091/pools 2013-01-17 11:13:29 [WARN] 11 Couchbase.MessageStreamListener - Could not resolve url http://10.1.44.2:8091/pools; trying the next in the list 2013-01-17 11:13:29 [WARN] 11 Couchbase.MessageStreamListener - Could not found a working node. 2013-01-17 11:13:29 [WARN] 11 Couchbase.MessageStreamListener - All nodes are dead, sleeping for a while. 2013-01-17 11:13:29 [INFO] 11 Couchbase.CouchbasePool - Received new configuration. 2013-01-17 11:13:29 [INFO] 11 Couchbase.CouchbasePool - Config is empty, all nodes are down. 2013-01-17 11:13:29 [DEBUG] 11 Couchbase.MessageStreamListener - Processing message: It appears that if a bucket with authentication is passwordless (like the beer sample bucket at creation), the client cannot find the other pools. |
| Comments |
| Comment by John Zablocki [ 18/Jan/13 ] |
|
Hi Guillaume,
How did this affect the client's behavior? Did operations fail? Could you describe a bit more what you were seeing? Thanks. -- John |
| Comment by guillaume.pitel [ 19/Jan/13 ] |
| It's the connection creation that fails, so every subsequent operation fails. |
[NCBC-202] add a keyStats feature Created: 12/Jan/13 Updated: 17/May/13 |
|
| Status: | Open |
| Project: | Couchbase .NET client library |
| Component/s: | library |
| Affects Version/s: | 1.2.0 |
| Fix Version/s: | 1.3 |
| Type: | New Feature | Priority: | Minor |
| Reporter: | Matt Ingenthron | Assignee: | John Zablocki |
| Resolution: | Unresolved | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Description |
|
At times it's useful to get information about a key through underlying "stats key <key> <vbucket>", but using just the stats command is complex because the vbucket hashing isn't exposed. One better though is a keyStats() operation that would return a map of the return for "stats key".
|