I want to use Java API client provided by ElasticSearch but I don't know if it would be compatible with my cluster.
I saw there was ElasticSearch High Level REST client which has been deprecated for the new Java API client. I could find information about what ES cluster would the High level REST client support but none regarding the new Java API client. Can someone point me in the right direction?
Compatibility information for high level REST client: https://www.elastic.co/guide/en/elasticsearch/client/java-rest/6.8/java-rest-high-compatibility.html
This section is missing for the new Java API client
You need to use Java High Level Client only because New Java Client support only forward compatible, below is what mentioned in documentation.
The Elasticsearch Java client is forward compatible; meaning that the
client supports communicating with greater or equal minor versions of
Elasticsearch. Elasticsearch language clients are only backwards
compatible with default distributions and without guarantees made.
However, You can use Java high level client with Elasticsearch 8.x version with compatibility mode enabled.
Related
I want to use this java client library for Kubernetes from app engine. But I ran into issues because this client library uses okhttp client which doesn't work in app engine as per this link.
The error described in the previous SO link is the exact error I am getting on app engine.
As per this link, okhttp exposes the method which can be over-ridden such that this issue isn't seen. There is actually a library for this here. But the issue is that the OkHttpClient has been moved from package com.squareup.okhttp to okhttp3 from version 3.x onwards in which the changes that I require are present. This old version of okhttp is used in the Kubernetes client library and shows error if I try to set the new okhttp.
Is there any way to solve this issue? Or are there any other client libraries which can be used from app engine. I know of client from fabric8 but it has support only till kubernetes version 1.7.10 as of now. I still haven't tried it on app engine though.
Edit:
Even the fabric8 client has the same issue in app engine. It is trying to get the ProxySelector which is not a whitelisted class in appengine.
Alternatively, you could try the Java 8 runtime where you can use all the standard Java library, unlike the Java 7 runtime which allows only select whitelisted JRE classes. After all, the Java 7 runtime is now deprecated: https://cloud.google.com/appengine/docs/standard/java/runtime
However, do note that there are some differences, so you may want to take a look at the migration guide: https://cloud.google.com/appengine/docs/standard/java/migrating-to-java8
Can someone let me know if elasticsearch java client 2.4..x backward compatible with elasticsearch server 2.3.1?
I couldn't locate this information anywhere in elasticsearch docs.
As stated in this link:
https://www.elastic.co/guide/en/elasticsearch/client/java-api/current/client.html
The client must have the same major version (e.g. 2.x, or 5.x) as the
nodes in the cluster. Clients may connect to clusters which have a
different minor version (e.g. 2.3.x) but it is possible that new
functionality may not be supported. Ideally, the client should have
the same version as the cluster.
they are compatible. However, the ideal scenario is that both client and nodes are in the same version.
I have a few Google App Engine standard Java environment applications that are backends for mobile apps, there are both Android and iOS clients.
Some time ago I received an email that the Cloud Endpoints v1 will be no longer supported and that I need to migrate to the new version v2.
What happens to the already existing (and using endpoints v1) mobile clients when I upgrade the version of the server?
My Android clients use maven-generated libs and the integration with iOS is based on discovery docs generated by another maven command.
I'm afraid that after the upgrade the clients will not be able to communicate with my backend anymore (as long as they do not update their libs / docs). As we cannot make the app-users upgrade their apps, I hope that the server changes will not affect all the clients that are already running on production.
No. It will not affect anything. The old version would not be supported after 2, August 2018. The new version has few benefits as given in the documentation.
Reduced request latency
Better integration with App Engine features (such as custom domains)
Official support for Guice configurations
Optionally, new API management features
Please follow the instructions given here. I have shifted to the new version just a few days ago and everything is working as usual.
There are several examples of configuring the service bus environment to use http/https with C#, using the call:
ServiceBusEnvironment.SystemConnectivity.Mode = ConnectivityMode.Http;
My question is - can and how do I do this via a java client?
The newer versions of the SDK (1.0 and later) do not support HTTP connectivity (AMQP only), and the older ones do not support AMQP (HTTP only). As a result there's no "need" for connectivity mode settings.
The Java SDK is AMQP only.
If http is what you want, try Azure SDK for Java older version, which is http only. It can be found at https://github.com/yvgopal/azure-sdk-for-java/blob/0.9/services/azure-servicebus/pom.xml. Be careful with the version of the package as the new AMQP only SDK also has the same package name. You should be good with any version starting with 0.9, but before 1.0. Also note that the SDKs are completely different. Applications written with one SDk don't work with the other SDK.
https://github.com/Azure/azure-service-bus-java/issues/171
I'm looking at the Java API for MarkLogic, which I assume leverages the HTTP protocol for database connections. Is it possible to establish a connection over TCP? If not with the Java API, is it possible to interrogate the database by any means over TCP?
Our current architecture is based on a Microservice architecture concept, and includes a number of stages in any given process flow through the system, including Queueing, Message-brokering, etc. Given the number of steps, I'd like to optimise traffic-speed insofar as possible by leveraging TCP connections.
The Java API uses the REST Application services on MarkLogic which is fully HTTP 1.1 compliant and TCP/IP.
Not sure what else you are asking for.
For programs written in Java the Java API is the recommended API for most uses
http://developer.marklogic.com/products/java
You can also use the REST services directly, but the Java API adds a lot of Best Practice and exposes a higher level of abstraction to make coding simplier.
You can use the REST API from any application that can do HTTP
http://docs.marklogic.com/guide/rest-dev/intro
But its a bit more work as you have to construct your HTTP messages directly.
You can also create your own HTTP interface and access it through TCP/IP (HTTP) by making an HTTP App Server (written in XQuery).
Finally if you want very low level but effecient access, using Java or .NET you can use the XCC interface which is more tedious to use but provides a lower level feature for advanced users. This requires the Java or .NET library as the protocol is not documented.
https://developer.marklogic.com/products/xcc
What language are you going to be using and what kinds of operations ? That can help focus on which API is best for you.
-David Lee
HTTP is built on TCP. So by definition all HTTP connections are over TCP.
If you'd like a proprietary protocol instead of HTTP, one option is to forget the fact you learned that the Java API uses HTTP and imagine it uses TCP directly. :)
If you really want a proprietary protocol over TCP, you can use the XDBC protocol in combination with the XCC client. By default XDBC uses a wire protocol on TCP that isn't published.