Getting error with version 3.x SDK

@brett19 any more thoughts on what. could be the issue?

Hey @Karlen91,

Can you try to use the Administrator username/password rather than a test user?

Cheers, Brett

Hey @brett19, thanks for the reply. The "test"s here are just for demonstrative purposes. I’m using admin user. I even created another user with full access but still getting the same isssue. Any more thoughts? :confused:

@brett19 I’m trying to debug the code inside the Couchbase package. The error I’m getting is “cluster object was closed” and it is being thrown from the “close” method of “Connection” class, but the thing is that I removed this line “cluster.close();” from my usage code. So I wonder, is it ok that it still calls the “connection.close()”?

Update: Ok, so connect is failing, that’s why the close is being called (in cluster._getConn)

Hey @Karlen91,

Can you describe a bit more about the environment you are operating in, and could you try the newly release 3.0.6 SDK? Looking at the logs you posted, it appears that our underlying libcouchbase library set up a timeout for 2s, but that the 2s timer expired nearly immediately. I’ve seen this show up on the forums once before, but have never been able to reproduce it and I don’t believe the user ever posted what had resolved it.

Cheers, Brett

Hey @brett,
As I posted earlier, here’s the environment I’m operating in:

Couchbase Server v6.6.0 (6.> 6.0 - 7909) - non-Docker
Node v12.18.2
Couchbase SDK v3.0.6
macOS Catalina v10.15.6

Please note that the following code (which is pretty much the equivalent code for version 2.x) is working perfectly with the same host/credentials using Couchbase SDK v2.6.12.

const couchbase = require('couchbase');

const username = "test", password = "test123";
cluster = new couchbase.Cluster("couchbase://127.0.0.1");
cluster.authenticate(username, password);
bucket = cluster.openBucket("travel-sample");

bucket.get("airport_1254", { timeout: 60 }, (_, res) => {
    console.log(res);
});

Also I wonder, is it possible to see the exact (underlying) error, which causes the v3 to fail, instead of LCB_ERR_TIMEOUT? And what are some major differences of creating a connection between these 2 versions?

I appreciate your help! Thanks.

@Karlen91 Here is the screenshot of my environment working

Thanks @raju. Unfortunately that doesn’t help much :frowning:
@brett19 any info regarding my last comment?

@brett19 I’ve just tried the same setup on my friend’s MacBook Pro (with macOS Mojave) and still getting the exact same error.

Hey @Karlen91,

I’ve set up a 6.5.0, 6.6.0 and 7.0.0 cluster. Each time, I login, go to the settings and load the travel-sample bucket. Then wait for it to finish loading and then finally ran your exact code on my macOS Catalina v10.15.6 MacBook Pro with Node.js v12.18.2 and SDK 3.0.6. Each time it executed flawlessly, it’s very strange that you’ve been having such issues!

Can you use wireshark and take a packet trace of the SDK communicating with your cluster? Specifically everything to/from ports 8091 and 11210 would be important to include in the recording.

Cheers, Brett

Hey @brett19, thanks for the reply.

If it helps, I’ve tried to connect to different ports in range 8091-8096 using “cbq” tool and here’s the output of all:

Also, I’ve tried the solution proposed in this thread: Trouble connecting with nodejs, i.e. to use couchbase.Cluster.connect() instead, but still getting the same issue.

Will try to get the report using Wireshark as soon as possible and share with you. Please note once again that it does work with latest v2. I think the issue is related to the change in how the package works with network to make a connection.

Hey @brett19,

Here’s the trace for the following range of ports: 8091 - 11210 on Loopback: lo0 interface. I haven’t worked much with Wireshark, but I gues this is correct.

Here first I ran the app without even starting the Couchbase server. You can see the red lines there. Starting from line: 90 (I believe) is when I started the Couchbase server and then executed the script again. Captured a bit more packets and stopped. So here’s the compressed file as the forum doesn’t allow attachments with unknown file types.

couchbase-app-wireshark.pcapng.zip (2.0 MB)

Looking forward to your response. Thanks!

Hey @brett19, any insights on my latest comments?

I believe this is the same issue as I faced, reported in this post: Trouble connecting with nodejs

I was solved by awaiting the completion of the first Cluster.connect call. Your initialization seems slightly different so I’m not sure which one needs to be awaited, but I’m fairly confident that is the issue.

Hey @Yann_Jouanique and thanks for your reply.
I’ve already tried your solution and unfortunately it didn’t help as well (see my reply two comments above).

Oh indeed, sorry I didn’t read properly…
Anyway, I see that couchnode 3.0.6 actually has upgraded to v3.0.4 of the underlying libcouchbase SDK, which fixes https://issues.couchbase.com/browse/CCBC-1200 and therefore https://issues.couchbase.com/browse/JSCBC-706 that I think was the root cause of it, so it can’t be that…

Hey @Karlen91,

From what I can tell from the packet capture, there appears to be some sort of firewall blocking port 8091 (all connections end in an immediate RST). Additionally, the SDK appears to be trying to connect via HTTP (8091) rather than CCCP (11210), but I’m not sure why this would happen unless an http:// connection string was being used.

Cheers, Brett

Hey @brett19,

I’ve used the Network Utility tool to scan the ports between 8090 - 8092, and here’s the result: image

For the connection string the couchbase:// protocol is being used and here’s the output stating that:

couchnode:lcb:info (instance @ …/deps/lcb/src/instance.cc:510) Effective connection string: couchbase://127.0.0.1?client_string=couchnode%2F3.0.6%20(node%2F12.13.1%3B%20v8%2F7.7.299.13-node.16%3B%20ssl%2F1.1.1d). Bucket=(null) +0ms

Also, I’d like to note one more time, that the exact same setup with 2.x SDK works perfectly. So I guess if there was a network issue or some port was blocked as you mentioned, then the 2.x SDK woudn’t connect as well. I believe the issue lies in the process of making a connection. Not sure how is it different from 2.x SDK, but it seems there are some significant changes in 3.x SDK.

I’ve tried to use both the latest 2.x SDK and the first 3.x SDK (alpha). I assumed there are some updates on 3.x SDK, which caused the issue, but even then the alpha verson failed and latest 2.x SDK still succeeded.

Would appreciate any more thoughts or investigation results. I wonder, is it possible to get an update on 3.x SDK, which will show even more details about the errors, so that I can see what exactly is failing and why?

@Karlen91 hi, i haved same problem, but i change host url and work.

i work with docker and i use ip for docker container, but i change ip for ‘localhost’
before

const cluster = new couchbase.Cluster('couchbase://172.17.0.2', {
    username: 'user',
    password: '123456',
});

after

const cluster = new couchbase.Cluster(‘couchbase://localhost’, {
    username: ‘user’,
    password: ‘123456’,
    });

works for my .

my enviroment:
macOS Catalina 10.15.7
Nodejs 14.12.0
Npm 6.14.8
node SDK 3.0.6
Docker container
Couchbase community 6.6.0
nestjs 7.0.0

could you find a solution?

We had that strange issue on some servers.
The solution was to enhance the connection string from

couchbase://172.27.71.124

to

couchbase://172.27.71.124,172.27.71.125,172.27.71.126,172.27.71.127,172.27.71.128

That idea came from this nice official diagnostic tool ’ sdk-doctor