I currently have a Vert.x codebase. I was using Golang, but Golang kinda sucks and doesn't have a good ORM. But apparently, Vert.x doesn't have a good ORM either, primarily because Vert.x is non-blocking and most ORMs for Java were based on blocking APIs.
Anyhow, I have a specific question - I read that Hibernate/JPA could be used with Vert.x - what we could do is put the Hibernate calls in a different Verticle and then it would be non-blocking.
Is that a good idea? Can someone show an example of doing that with 2 different Vert.x verticles?
If it's not a good idea, what might be a good ORM to use? Naked SQL calls sounds cool at first, but for migrations and stuff, might get kinda crazy.
#tsegismont, as he usually does, already provided a good solution in the comments. I would like just to clarify the following sentence:
I read that Hibernate/JPA could be used with Vert.x - what we could do is put the Hibernate calls in a different Verticle and then it would be non-blocking
There is a true and a false part there:
Hibernate/JPA could be used with Vert.x
True. By putting blocking code in a worker verticle you don't block Vert.x event loop, and that allows frameworks based on JDBC to work with Vert.x
put the Hibernate calls in a different Verticle and then it would be non-blocking
False. You don't make Hibernate non-blocking. JDBC is blocking in it's nature, and there's not much that can be done to solve that (although R2DBC is a nice initiative). You'll use the same thread pool you were using before, with the same limitations.
Related
if I dont use the reactive extensions for Quarkus Is the I/O op going to be non-blocking or blocking? I am asking this because I didnt like the reactive programming style, I wish I could have something like c# async await for java
The fact that Quarkus is reactive under the hood, does not force users to do any reactive programming.
Users are free (and in most cases encouraged) to use regular blocking APIs. When that is done, Quarkus will delegate the work to worker threads.
Some details can be found here.
I'm just kind of getting started with Spring and I want to build a RESTful API for a project I'm working on. My backend has a lot of HTTP calls to third-party services, I've decided that it would be prudent to implement a Reactive design and have the architecture be non-blocking. I'm using Retrofit and it has a callback-based async API which will work fine for me. Here's the problem; I've already implemented my database and models using Hibernate and JPA, it's really mature and can handle everything from migrations to validations and everything in between, I like using JPA, but it's blocking and so doesn't fit neatly in my architecture design. Is it okay to have the reactive stack everywhere else and perhaps migrate the persistence stuff to a reactive model later when the tooling and frameworks are almost at par with JPA? The main issue is creating the database schema at start-up, if there's a solution to that, I'd be glad to work with it.
blocking in any fully reactive webflux application is bad from a performance perspective.
Webflux starts with a very few number of threads, which means that if you block there is a high risk that your application will (under load) be susceptible to thread starvation, this because no new threads spawn in reactive applications, and your applications small thread pool will be blocked waiting for responses from your database.
There is a workaround which is that you place all potential blocking calls instead on its own scheduler, using the subscribeOn operator. This is documented in the reactor documentation
Just remember by wrapping blocking calls, you will not get the benefits from reactive programming, like a smaller memory footprint, and potentially higher throughput. But at least you will not suffer from thread starvation.
Those calls will instead behave like "regular calls" to a "regular spring boot web server" since those calls will get assigned a single thread that will follow the call throughout execution.
I have a requirement where I have to persist some data in a table and the persisting may take sometime. Basically I want to persist a log. I don't want the execution to wait till the persisting finishes.
I know I have to use threads to accomplish this task and I know that it is discouraged to create threads in an enterprise application.
So I started reading about worker manager and understood and tried a sample program in websphere application server 8.5.
I used asynchbeans.jar from websphere and now I am bothered that I am writing vendor specific code.
Then I came across commonj work api which is described in oracle java documentation. Now I am thinking to use commonj api from fabric3.
My doubt is, is there a better way to accomplish the same task? An EJB way? Or work manager is good for my requirement?
You have some options:
Asynchronous beans. These are vendor-specific, as you mention.
commonj is just barely not vendor-specific. As far as I know, it was only implemented by IBM WebSphere Application Server and BEA WebLogic. The API was effectively superseded by Concurrency Utilities for Java EE, which is really the best choice.
EJB #Asynchronous methods. Requires using EJBs (unwanted complexity for some).
EJB timers. Requires using EJBs, requires serializable data.
JMS. Probably requires using MDBs to receive the message, requires serializable data.
Actually create threads. The EE specs do not recommend this, but as long as you don't attempt to use EE constructs (lookup("java:..."), JPA, UserTransaction, etc.), then you should be fine.
JavaEE7 has the managed executor, that you can try. You can spawn a task with it, and recieve managed callbacks in a handler. This is part of EE standard and should be platform agnostic.
See JDoc here:
http://docs.oracle.com/javaee/7/api/javax/enterprise/concurrent/ManagedExecutorService.html
If you need to be sure that all your log entries are safely written, then you probably should use JMS with persistent messages. Otherwise you could use #Asynchronous EJB methods.
I am trying to understand exactly what types of problems Apache ZooKeeper ("ZK") solves, and perhaps their Recipes page is the best place to start.
First off, I am making the following assumptions:
The ZooKeeper API (available in both Java and C) exposes these 7 simple methods which then allow you to build up your own usage patterns, known as "ZK Recipes"
It is then up to you to use these ZK Recipes to solve problems in distributed programming yourself
Or, instead of building up your own ZK Recipes, you could just use the ones that ship with Apache Curator
So either way, you're using ZK Recipes (again, homegrown or provided by Curator) to solve distributed computing problems
I believe Apache Kafka is an example of this, where Kafka uses ZK to create a distributed Queue (which is one of the listed ZK Recipes). So if my assumptions are correct, ZK exposes those API methods, and the creators of Apache Kafka either used ZK directly or used Curator to implement the "Queue" ZK Recipe.
If any of my above assumptions are wrong, please begin by correcting me! Assuming I'm more or less on track:
Looking at the list of ZK Recipes, I see the following (non-exhaustive):
Barriers
Locks
Leader Election
In order for me to appreciate these recipes and the solutions they present, I first need to appreciate the problem that they solve! I understand what a lock is from basic Java concurrency, but I'm just not seeing the use case for when a "distributed Lock" would ever be necessary. For leading election, all I can think of - as a use case for needing it in the first place - would be if you were building an application that you wanted to ship with a built-in master/slave or primary/secondary capability. Perhaps in that case you would use ZK to implement your own "Leader Election" recipe, or perhaps just use Curator's Leader Latch out of the box. As for Barriers, I don't see how those are any different than Locks. So I ask:
Is my master/slave or primary/secondary problem an accurate use case for ZK's Leader Election recipe?
What would be an example of a distributed Lock? What problem(s) does it solve?
Ditto for Barriers: and what's the difference between Locks and Barriers?
Yes. Your Zk's leader election recipe example is a correct one. In general, if a recipe already exists why rewrite it?
Quoting Zookeeper documentation:
ZooKeeper is a centralized service for maintaining configuration information, naming, providing distributed synchronization, and providing group services.
Regarding distributed locks - Let's say you have a distributed system where all configuration are saved on Zookeeper, and more than one entity is responsible for updating a certain configuration - In such a case you would want the configuration updates to be synchronous.
Regarding the barrier, I personally never used them - but with a lock you need to aquire the lock to actually do something on the node, a barrier you wait until it's free but do not necessarily need to set the barrier once it's free.
Since working with databases requires input/output, may take unbounded amount of time, etc. it seems natural to want a non-blocking, asynchronous API. Is there one for Java?
I do not think that such API exists but there are 2 different things: DB access libraries and a lot of ways to perform asynchronous calls in java.
You can use either plain JDBC or any other higher level tool that simplifies DB access implementation to access your database.
You can make asynchronous calls using JMS (if you are in Java EE environment) or using queues and executors from concurrency package if your are in JSE environment. Obviously a lot of other solutions available too.
There is no standard API like JBDC which would allow you to asynchronously call any DB. However there is this Google Project which tries to do exactly this for PostgreSQL and MySQL.
You may also take a look at this question, which addresses similar stuff:
Is asynchronous jdbc call possible?
For Couchbase I came across Reactive Couchbase which claims to do this and has a Java Wrapper. Didn't try it but there are several examples in the links.