Until recently we’ve been unable to reproduce your specific issue. Recently we fixed a memory leak that was discovered due to some reference counting issues between the SDK and v8 (https://issues.couchbase.com/browse/JSCBC-881). Upon fixing this leak, we are now seeing a segfault during shut down of the SDK and are investigating it directly (https://issues.couchbase.com/browse/JSCBC-884). Hopefully we should have a fix for it in the near future and it’s likely that this is the same issue you are encountering.
To recap on the original issue in this thread as well. We are aware of this issue and working towards a long-term solution. You can track the progress on this issue through the following ticket which is intended to cover the improvement to connection behaviour. https://issues.couchbase.com/browse/JSCBC-706
Note that in the majority of cases, the connection failure occurs due to a miss-configuration somewhere, and it is possible to start your application with debugging enabled to see the underlying reason for the failed connection with something akin to: DEBUG=* node index . This is possible to do inside of docker, and you can additionally just set the environment variable DEBUG before starting your app.
hey @EtzBetz, I know that sounds like it’s pretty far out, but actually the problem and the reason you saw that update in JIRA are related.
The next version of the node client has some significant internal changes to make room to address things like this. And while the external API will remain nearly the same, we felt we needed to use the version number to indicate to people that there was a bigger change.
So, seeing 4.0 there isn’t so much “put out” as that’s the next release, and the one that has the improvements you’re seeking. I hope that helps!
I should also mention, we are still thinking through this. The opinion we have at the moment is that we shouldn’t go from 3.2 to 3.3 with significant internal changes. Technically, semantic versioning (which we follow) allows us to do that, but some behavioral items outside the API contract may be different and had to be to accommodate moving to newer node.js APIs. At the end of the day, we didn’t want someone to update dependencies from 3.2 to 3.3 without reading the docs and see something unexpected. That’s why we’re currently thinking to call it a 4.0.
Glad to get your feedback on how we message this @EtzBetz
Hi, I saw in JIRA that you are switching the underlying library from lcb to couchbase++. I guess that is the reason you want to call it 4.0.
Has couchbase++ been used elsewhere or this is going to be a first, meaning it hasn’t been yet thoroughly tested in the field?
No, it won’t be a first. Couchbase++ is actually us extracting a C++ core out of the Ruby client. I will acknowledge that it does not have as many ‘miles on it’ as libcouchbase in node.js does. However, it is from the same team and we know where the architectural limitations are in libcouchbase and what needs to be done differently to both bring reliability and deliver some cool new features.
The connection management logic and some of the updates with managing the scope in node.js are part of this update. It’ll make entire classes of problems easier for us. We’re also updating from node-gyp to a cmake style build system and getting ready for the next node LTS release.
I’ll also mention that 3.x will be supported and get fixes, where possible, for quite some time yet. The new features will be in 4.x. Migrating from 3.2 to 4.0 will be no code changes for nearly all apps.
Like I said, we’re open to feedback. At the moment, we feel that calling it a 3.3 wouldn’t really communicate the significant internal changes. If you think about it from the perspective of someone just seeing a new release and updating their packages.json without reading release notes, there’s just a bit of risk that they’d have a negative experience. It won’t be because we ship with significant bugs we know of, it’ll just be because there could be observed behavioral differences that are deeper than the API.
I agree, I think naming it 4.0 is the correct choice. Even if there are no API changes the underlying change is pretty big and may produce a different behaviour in complex projects, so naming it 3.3 could mean somebody may upgrade without being aware of the change.
Hi @00christian00, thanks for trying out the new release. Would you be able to create a new post with the issue you are seeing? Also, would you be able to share the code you are running, any output you see, what operating system you are using and the Couchbase Server version? It would also help if you share the log you see if you set the environment variable CBPPLOGLEVEL=trace