We have a swing UI that is a restlet client. We are accessing the services on the LAN, but the communication is taking a bit long. We are using Tomcat 7.0 and mysql on the server side.
Is it a known issue with restlet based applications ?
How can we speedup the communication time?
In version 2.0 the internal HTTP client isn't designed for speed/production purpose, more for developement/convenience purpose. This has been redesigned in version 2.1.
However, in version 2.0, you can drop "org.restlet.ext.net.jar" in your classpath to switch from the internal connector to a faster one based on HTTPUrlConnection.
Related
I am new to elasticsearch and I have a elasticsearch springboot project. We use docker to setup elasticsearch cluster and use springboot(backend),esclient to fetch data from elasticsearch. It is an old project and now I have the task of upgrading the cluster to it's latest version which is 8.x. Upon glancing upon the dependencies I saw that the project uses transport client but as per documentation the transport client is long deprecated and instead of that we were to use High level rest client client which was again deprecated in favor of JAVA Api client. So for the app to work I have to update the dependencies. I found the migration guide from transport client to high level rest client and the migration guide from high level rest client to java api client. I also gathered from the documentation that java api client and high level rest client do not have any relation and the transition to java api client can be done gradually)
Now my question is that
Suppose I upgrade from transport to java api client. Will this bring a whole lot of changes in my code as it is a really big project or is there a workaround in which I don't have to make that many changes in my code and I can work with elasticsearch version 8.
The need for the client upgrade didn't arise till now as we were still using 7.17.x and that was working fine till now but when I upgraded the cluster to version 8 and with that they are not providing transport client. My one approach is that I migrate to HLRC first and then gradually transition to JAVA api client.
Any help will be appreciated.
Regards
Why would Neo4J be slow to respond over HTTPS compared to HTTP?
I have the same database configured to run with both protocols. The same query takes well under 1,000ms when using the HTTP endpoint, but over 30,000ms on the HTTPS endpoint. In addition, just loading the Neo4J browser is taking a lot longer.
According to Neo4J devs, there was a Jetty (the embedded web server) bug in the version of Neo4J I am using, 2.2.6. Version 2.3.7 seems to perform as expected in my limited testing, but I could not test with my actual data for other reasons.
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.
Does anyone know of any benchmarks of using the native Elasticsearch driver over the rest client? I'm specifically working with the Java client but any other language would be fine.
If you are using Java then you can use native java client, which would be faster than HTTP Client. But if you are using any other language, then use REST Client would be faster, since client libraries in most programming languages use the HTTP Client themselves.
we're developing standard Java SE application and it is necessary to implement some logic on remote server (using Java EE running on OpenShift PaaS). My question is, what is the best way to remote call classes/methods between the SE client and EE application?
My tips:
EJB remote call: however, is the communication encrypted (or possibility to do that)?
Expose EBJs through JAX-RS: looks line nice one, with possibility to use SSL encryption
Thanks for any suggestions.
Title of this question indicates that the Java SE client is in Spring. If the PaaS provided allows, you can even choose Spring. That will help you in long term as the skillset to maintain your application will be small. It'll also improve efficiency.
JAX-RS is features provided by Spring and EJB are almost same.
Assuming you are bound to use EJBs, I'd suggest to go with 'Expose EBJs through JAX-RS'.
Pros -
It avoids tight coupling of client and service. Remote calls will make client aware of EJBs.
In future, you can choose to change your technology from EJB to something else, then client will be minimally impacted.
If you think to write client in any other technology than Java, then it'll be smooth.
Saves time related to JNDI setup
Cons -
Additional time for marshalling and un-marshalling.
Request-response convertes on client and server sides