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.
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.
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.
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).
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.
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?