Am running Solr in Https(8443) port on top of tomcat, How can i access that solr using solrj client, I can see only CommonsHttpSolrServer is availble,
Please suggest is there any way to access the https port enabled solr using SolrJ?.
Solrj internally uses Apache Http Client. When using CommonsHttpSolrServer it will create one & use it, if you are not providing it with one.
In this case since you need support for SSL you could provide your own SSL configured HttpClient to CommonsHttpSolrServer constructor. Check its API that accepts HttpClient.
CommonsHttpSolrServer(String solrServerUrl, HttpClient sslHttpClient, ...
You can see the following guide, on how to create SSL enabled http client SSL Guide.
This should help.
Related
Following Jetty documentation of enabling HTTP/2,
I reached till the following step,
2015-06-17 14:16:12.549:INFO:oejs.ServerConnector:main: Started
ServerConnector#6f32cd1e{HTTP/1.1,[http/1.1, h2c]}{0.0.0.0:8080}
From the docs,
No major browser currently supports plain text HTTP/2, so the 8080
port will only be able to use HTTP/2 with specific clients (eg curl)
that use the upgrade mechanism or assume HTTP/2.
The documentation mentions "specific clients", but what client I can use for overcoming this issue? I tried okHttp and apache-httpclient, okHttp doesn't support the upgrade mechanism (AFAIK, Would be great if it is otherwise), and apache-httpClient doesn't support h2.
I basically need to make GET/POST request from my program to this endpoint(Obviously, using HTTP/2).
To put in a simple words, Please suggest any Java client which support non-encrypted http/2 (h2c)
Thanks!
Apache HttpCore and HttpClient 5.0 support h2 as well as h2c but presently do not support the http/1.1 to h2c upgrade mechanism. I am not sure they ever will given it is unclear how useful this upgrade mechanism is in the first place.
For code examples please refer to
http://hc.apache.org/httpcomponents-client-5.0.x/examples-async.html
For HttpClient 4.5.x to HttpClient 5.0 upgrade guide please refer to:
https://ok2c.github.io/httpclient-migration-guide/
The Jetty Project has a HTTP client library that can be used as HTTP client and supports HTTP/2, both clear text and encrypted.
You want to look at this documentation.
See also how the Jetty Project uses that same client for tests.
When we configure the SSL on standalone ActiveMQ, we may need to provide the TrustStore,TrustStore Password, KeyStore and KeyStore password in client code to connect to the Active MQ over SSL protocol but in case of AmazonMQ, though they have provided SSL endpoint, but we can connect to it simply without providing the trust and key related values.
Client code snippet for Simple ActiveMQ over SSL:
ActiveMQSslConnectionFactory connFactory = new ActiveMQSslConnectionFactory("ssl://<someHost>:61617");
String trustStore = "pathTo/client_new.ts";
String keyStore = "PathTo/client_new.ks";
try {
connFactory.setTrustStore(trustStore);
connFactory.setTrustStorePassword("password");
connFactory.setKeyStore(keyStore);
connFactory.setKeyStorePassword("password");
} catch (Exception e) {
e.printStackTrace();
}
Client code snippet for Amazon MQ over SSL:
ActiveMQConnectionFactory connFactory = new ActiveMQConnectionFactory("ssl://xyz.amazonaws.com:61617");
Basically, what make this difference?
Firstly AmazonMQ works on top of the ActiveMQ, amazon has written a wrapper layer over activeMQ so as functionality wise it works pretty much the same. AmazonMQ is managed Message Broker Service for ActiveMQ.
It manages everything related to space, configuring active/passive endpoints in different regions and some benefits mentioned in the below links.
https://docs.aws.amazon.com/amazon-mq/latest/developer-guide/welcome.html
Other benefits of amazonMQ is you can setup alerts and many more as part of using other services of amazon like upgrading activemq version to the latest.
Now coming to you application part, one good thing was the way you have configured activemq was via SSL connection, though activemq exposes tcp endpoint as well which can be connected by simply providing broker URL but in case of amazonMQ it does not exposes any TCP endpoint only way to connect is by providing SSL endpoint and related parameters.
Refer this link on how application is connected to amazonMQ:
https://docs.aws.amazon.com/amazon-mq/latest/developer-guide/amazon-mq-connecting-application.html
What is the best practice using ElasticSearch from Java?
For instance one can easily find documentation and examples for delete-by-query functionality using REST API.
This is not the case for Java Transport Client.
Where can I find usage examples for Java Transport Client ?
Does Java Transport Client cover whole ElasticSearch functionality like HTTP client via REST API?
The best practice of using Elasticsearch from Java: Follow This
Nexts:
You can follow the library : JEST
Yes, in maximum time, Java Transport Client cover whole ElasticSearch functionality like HTTP client via REST API
To complete #sunkuet02 answer:
As mentioned in documentation, the TransportClient is the preferred way if you're using java (performance, serialization, ...).
But the jar is quite heavy (with dependencies) and it requires that you use the same versions between client and server to work.
If you want a very lightweight client, there is a new Java REST client in Elastic 5.x.
I don't know the differences with Jest, but it's compatible with last Elastic 5.x versions (but not with previous versions) and it's developed by the Elastic team.
So it might be a good option to consider, according to your needs.
I haven't found any solution about this. It seems Jetty doesn't support this feature yet. I might be wrong so please, enlighten me.
I've got a very simple Java client which connects to a Java server at localhost:8080. I would like to add a transparent proxy between them in order to simulate what we could find in a company's private network.
Update: May, 2017
Starting in Jetty 9.4.0 and onwards, the native Jetty WebSocketClient supports Proxies via the Jetty HttpClient.
This works by declaring an HttpClient, along with its proxy configurations, and then handing that off to the WebSocketClient constructor to use.
This only works with the following:
HTTP/1.1 upgrade to WebSocket
Native Jetty WebSocket APIs
This does not work with the following:
HTTP/2 (there is no spec for WebSocket over HTTP/2 as of yet)
JSR356 javax.websocket (there are ideas for API breaking changes to the JSR356 ClientContainer to allow passing in a Jetty HttpClient via a constructor, let us know if this is viable option for you by filing a new issue on github saying so)
Original Answer
With Jetty 9, there's no Proxy support for either the Jetty Native WebSocket client, or the JSR-356 (javax.websocket) client implementation.
This support is scheduled for Jetty 10 (which is tracking Servlet 4), and will result in a complete reworking of the entire client library suite in Jetty to have equal support for :
HTTP/1.1
HTTP/2 (native/direct)
HTTP/1.1 upgrade to HTTP/2 (h2c)
HTTP/1.1 upgrade to WebSocket
HTTP/2 websocket channel (currently in draft specs)
Proxy support
Cookie support
etc ...
The existing WebSocket client implementations on Jetty are standalone, due to the JSR-356 support requirements.
The existing WebSocket client does not leverage the existing Jetty HttpClient in Jetty 9.x. If it did then proxy support could, maybe, under a very limited set of scenarios, work.
This is a low priority feature request, as there are few existing proxies out there that support WebSocket so far (actually, they have generally bad support for HTTP/1.1 upgrade). Even Jetty's own Server side Proxy does not currently support HTTP/1.1 upgraded connections.
According to Figure 2 in How HTML5 Web Sockets Interact With Proxy Servers, if you are trying to use a transparent proxy, you don't have to require a proxy support on the client side. On the other hand, an explicit proxy requires client libraries to support proxy.
Jetty WebSocket client won't have any problem if your proxy is transparent.
I am using the camel elasticsearch component : http://camel.apache.org/elasticsearch.html
My assumption, based on the docs, is that the elasticsearch server must be on the same network as the running camel route in order to work. Is this correct?
To clarify, the only connection property available is 'clustername'. I assume this is discovered by searching the network via multicast for the cluster.
My code needs to connect to a remote service. Is this just not possible?
I am fairly new to elasticsearch in general.
I had a similar problem with the autodiscovery of elasticsearch. I had a camel route that tried to index some exchanges, but the cluster was located in another subnet and thus not discoverd.
With the java api of ES it is possible to connect to a remote cluster with a TransportClient specifying an IP adress. I don't have acces to the code at the moment but the Java API in the ES documentation provides clean example code. You could make such a connection from within a bean in the route for example.
I also submitted a patch to Camel to add an ip parameter to the route, which should then connect to the remote cluster with such a TransportClient. The documentation states that should be available with Camel 2.12
Hope this helps.