I am using neo4j-connector-apache-spark_2.11-4.0.2_for_spark_2.4.jar this connector with spark version 2.4.4, scala 2.11.12 and neo4j 3.3.x
Throwing this org.neo4j.driver.exceptions.ClientException: The server does not support any of the protocol versions supported by this driver. Ensure that you are using driver and server versions that are compatible with one another, while trying to read data from neo4j.
TL;DR
This error means that the underlying Neo4j driver is either very old (unlikely) or too recent (most likely) for the target Neo4j server.
You should either downgrade the Neo4j driver (and hope it is still compatible with the Spark connector) or upgrade the 3.3 server to 4.4 or 5.x (since 3.3 has reached EOL in 2019).
Long version
Neo4j drivers negotiate a Bolt protocol version with the server after establishing a connection. Drivers have a limited range of versions they can offer, so older protocol versions are excluded from newer driver releases. The server also offers a range of protocol versions it can support. The server then selects a version from the overlap of all these versions.
Since Neo4j server 3.3 has reached end of life in 2019 (see https://neo4j.com/developer/kb/neo4j-supported-versions/), the associated Bolt protocol version (1, according to the docs) has not been included in any recent drivers' negotiated version range.
Because of this, there is no overlap so no protocol version can be picked up and this error happens, reported back by the Java driver as a ClientException.
Related
We have multiple applications using mongodb as database. In our current case our applications are using the mongo driver 3.4.
On the server side currently we are running with Mongo 3.4 but we would like to keep the Mongo version up to date as long as possible.
I know that mongo drivers provide such level of backward compatibility, but I don't know whether an old version of mongo driver can work without any problem with a newer version of a mongo server.
Can mongo driver 3.4 work with 3.6 server without any problem?
Officially supported drivers provide a form of backward compatibility.
That is, newer drivers should be compatible with older server versions, but thorough testing of the application to double-check is always strongly recommended.
Note that the opposite is not always true, e.g. newer servers may be compatible with older drivers, but there is no guarantee. This is especially true if you apply setFeatureCompatibilityVersion command after a server upgrade.
The page Driver Compatibility in the documentation should be up-to-date with driver versions vs. server versions. You might be able to refer to this page in the future.
As of December 2021, the driver compatibility pages containing compatibility matrices for Python can be found at:
PyMongo: https://docs.mongodb.com/drivers/pymongo/#mongodb-compatibility
Motor: https://docs.mongodb.com/drivers/motor/#mongodb-compatibility
We have an app that uses the C# Mongodb client lib from mongo, version 1.1.0.4184
This code currently runs against mongodb 2.6.4
We would like to stand up a new mongodb server, the current version (3.2.11). Will our code run against newer mongodb?
It really depends what you mean by "will it run". The MongoDB v1.1.0.4184 C# driver was released in June, 2011 and dates to roughly the MongoDB 1.8 server release timeframe. This driver version is certainly no longer tested or supported, and will not be fully compatible with newer server features like the WiredTiger storage engine (default in MongoDB 3.2+) or SCRAM-SHA-1 authentication (default in MongoDB 3.0+).
The MongoDB documentation includes a reference table with recommended version(s) of the drivers for use with a specific version of MongoDB: C#/.NET Driver Compatibility.
If this is a production system I would strongly recommend taking the time to update and test a supported version of the C# driver for use with MongoDB 3.2 (eg. the v1.11 C# driver). I suspect it is very likely you will encounter fixed (or novel) bugs/behaviour using a driver that is more than five years old. Your application won't be able to take advantage of many of the newer server features, and this obsolete driver predates specifications such as standard Server Discovery and Monitoring (SDAM) behaviour.
That said, assuming you aren't using any features the driver isn't aware of your code may continue to run (or at least appear to run) successfully. In my opinion doing so is a high risk deployment strategy.
Yes, i am using it, but however we have to chek on specific features, which you were using. using MongoDB latest driver is much better in terms of latest features and there are few features were removed(like 'eval()').
Seems the MongoDB release is a significant performance upgrade - ay idea when Spring Data MongoDB will support this version?
Strictly speaking, the MongoDB 3.0 server can even be used with the latest 2.13 Java driver and thus the currently released Spring Data MongoDB 1.6.2. For a full compatibility overview of the driver and server versions, see this wiki page.
The recently released first release candidate of Spring Data MongoDB 1.7 ships support for the MongoDB 3.0 Java driver. This is mostly a compatibility release, we don't target special 3.0 features yet (although you should be able to benefit from an upgrade nonetheless).
Find more information about this in the release train wiki, the JIRA ticket as well as the corresponding section of the reference documentation.
The GA release of Spring Data MongoDB 1.7 is scheduled to be part of the Fowler release train GA end of March.
Spring Data Mongo has 1.7RC1 -> http://docs.spring.io/spring-data/data-mongo/docs/1.7.0.RC1/ Hopefully that one will be released soon.
As Java Driver github repo says, they released a 2.13.0 version on January 29th and it is stable -> https://github.com/mongodb/mongo-java-driver/releases/tag/r2.13.0 It includes all the features for mongo 3.0, but you need to go through the compatibility to upgrade to this version.
Also, they are working on v. 3.0.0. for Java Driver, you can find it here -> https://github.com/mongodb/mongo-java-driver/releases/tag/r3.0.0-beta3 (its still in beta though)
i have a question about Firebird Client and Server versions. I know that the Database-File have to match the Firebird Server due to ODS Changes. i.e. Firebird recommends to Backup/Restore the Database-File between Server-Version 2.5.1 and 2.5.2...
But what about Client connections to the Server?
Which combinations are ok?
Client 2.5.2 --> Server 2.5.2 (should be ok. ;) )
Client 2.5.2 --> Server 2.5.1
Client 2.5.1 --> Server 2.5.2
Client 2.5.x --> Server 1.5
Client 1.5.x --> Server 2.5.2
Are there any known problems? What is the recommendation from Firebird?
Is it a good why to use always the new official Client? But due to we have a lot of Customer Installations i can not be sure that the server matches the client-version.
Hope someone can give me some advice.
The Firebird protocol has a versioning mechanism: the client and server negotiate which version of the protocol to use. Current Firebird server versions support all previous protocol versions of Firebird (upto and including Interbase 6.0 from which it was forked). This means that any Firebird client version can talk to any Firebird version. However if you use an older client, you can't use features added in newer protocol versions, and you won't be able to use some of the performance improvements in the protocol.
So: yes you can use older versions, but it is advisable to use the latest because bugs will have been fixed and new features or performance improvements have been added.
My answer only applies to TCP/IP connections. For 'local' connections with XNET or named pipes I know there were breaking changes between 1.5 and 2.0, and you might even need a client version that matches the Firebird server version.
For Firebird 3, using older client versions does have some caveats: by default Firebird 3 requires wire protocol encryption and a new authentication mechanism, both of which were introduced in Firebird 3 with wire protocol version 13. To be able to connect with an older client version you will need to make the following changes to firebird.conf and restart Firebird:
Relax the encryption requirement with setting WireCrypt = Enabled (default is Required)
Enable the legacy authentication with setting AuthServer = Srp, Legacy_Auth (default is Srp)
https://i.stack.imgur.com/mxQ7S.png
You cant read v2.1v database on v2.5 server.
You cant read v1.5v database on v2.5 server.
You can read v2.0v database on v2.1 server.
You can read v1.5v database on v2.1 server.
I have to set up a Hornetq Core-Bridge to a Hornetq 2.1.X Server, but I would like to use a more updated version on my side of the architecture (2.2.X). Is it compatible?
I haven't found info about it on documentation (as always btw, regarding to hornetq).
Obs: The 2.1.X Server is running on a JBoss AS, and mine is on stand-alone mode.
Until hornetq 2.2.2, hornetq didn't have version compatibility support. That means that you would need all your servers on the same version. (same as you would need for your clients).
After hornetQ 2.2.2 we offer version compatibility, however the client has to be older than the server. We don't test a 2.2.5 talking to a 2.2.2 server.
So, if the core-bridge is installed in a 2.2.2 talking to a 2.2.5, you would be fine.
a 2.2.5 talking to a 2.2.2.. probably not
A 2.1.X talking to 2.2.x.. definitely not.