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.
Related
Using google i found two possible solution for now:
-using spring boot with kotlin
-using this kotlin client https://github.com/jillesvangurp/kt-search
I've already finished the android client application in kotlin but now i have to find a way to make this client comunicate with elasticsearch.
What would it be the best solution for my problem that i could look up online
Thanks in advance
First, if you don't use Spring in the current application, integrating it (if possible) would be a lot of work and most likely not worth it.
Another alternative would be to use the officially supported Java client for Elasticsearch (https://www.elastic.co/guide/en/elasticsearch/client/java-api-client/current/index.html).
BUT, you should keep in mind that, if you put the Elasticsearch client in your client application, that the credentials, you may use, will also be in the client application.
They could be accessible for everyone using the Android client and the user could perform any request on the Elasticsearch. Also you couldn't change them without updating the client.
So, it is likely better to use a Three-Tier-Architecture (https://www.ibm.com/topics/three-tier-architecture) and creating an API service to handle the Elasticsearch requests.
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
I am trying to setup a spring boot application and looking for options to store the small data in the local cache and then this local cache interacts with Redis server which will be on google cloud platform. This local cache can be shared across multiple nodes. I see Redis pro can help to achieve this but that is not free. Is there any open source option I can use? Or any other way I can set this up in Spring boot? How can I set this local cache which syncs up with the central cache? Any suggestions please?
You can use Redisson https://github.com/redisson/redisson/wiki/14.-Integration-with-frameworks/#1421-spring-cache-local-cache-and-data-partitioning. It's available in the Pro version.
If you would like to implement it by yourself, you would need to implement custom CacheManager that first looks up entries in local cache (implemented likely with something smarter than a HashMap, like Caffeine, if entry not found goes to Redis based CacheManager and then depending on the result puts the data to Caffeine cache.
For storing data in Redis and making sure all nodes are in sync, you can use Redis Pub/Sub mechanism to notify each connected node to update local cache.
Spring Boot for Apache Geode (SBDG) offers client-side caching, or what is commonly referred to as "Near Caching". See here.
HISTORY
Apache Geode is an open source software (OSS), In-Memory Data Grid (IMDG) technology, having an Apache 2 License. Indeed, it can be much more than a cache if need be, but fits perfectly well in the caching use case, at any layer in the application architecture (Web, Service, Data).
The commercial version of Apache Geode is VMware Tanzu GemFire, built on Apache Geode source with support from VMware, if needed. But, to use Apache Geode, is completely free.
In fact, the original Spring Cache Abstraction was inspired by Costin Leau's development (original lead & creator) of Spring Data GemFire, which has been replaced by Spring Data for Apache Geode (SDG), to focus on the OSS offering. (See here/alt-here, then here, as well as from Boot).
SBDG is an extension of SDG to give users of Apache Geode (or alternatively, VMware Tanzu GemFire) a proper and first-class experience using Apache Geode in a Spring context, and specifically with Spring Boot features (e.g. auto-configuration). That is, SBDG is a special extension of Spring Boot catered specifically to Apache Geode to handle a variety of application concerns (like caching) that is owned and maintained by the Spring Team, itself.
SBDG is even capable of handling several caching patterns in addition to "Near Caching". See the topic of caching in general.
Finally, SBDG also includes Spring Session for Apache Geode (SSDG) to handle your Web, HTTP Session state caching concerns independent of you Web container (e.g. Tomcat) using Apache Geode as the caching provider for the HTTP Session state. It is, of course, built on Spring Session core (see here).
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.
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.