Cuba non-blocking?

Support
#1

Hi,
I am quite new to Cuba, JAVA and Spring …
I read that Spring was originally not designed non-blocking but is getting there now.
Cuba uses the Spring framework.
So, is Cuba non-blocking?

Cuba and Spring 5 and reactive stream
#2

Hi Oliver,

can you elaborate on what should or could be non blocking? Are you talking about HTTP requests to the web client, the JDBC connection to the database, or are you talking about the reactive stuff going on in the upcoming spring 5?

> So, is Cuba non-blocking?

I think the answer to this is no, because a framework / platform in itself can’t be “blocking” or “non-blocking” - exactly as Spring is neither blocking nor non-blocking. Spring consists of many parts: Dependency Injection, AOP, Security, Web flow, etc. So some of the parts might contain reactive elements, while the (buzz-)word doesn’t make any sense in others…

Bye
Mario

1 Like
#3

Hi Mario,

Thanks for your comments.
I am referring to all three areas you said (HTTP requests, JDBC connections and the new reactive Spring “stuff”) because I think these are the main areas where blocking code could be an issue.
Any further thoughts anybody … ?

Cheers
Oliver

#4

Hi Oliver,

so from my point of view, CUBA is blocking in all of the above mentioned parts. But i might be wrong on that. So if anyone with more insights on that topic see’s that im writing bullshit here, don’t hesitate to correct me :slight_smile:

Let’s begin with the database access part. The problem with this in the Java space is that JDBC itself is blocking. This means that all ORMs will not be really be capable of asynchronous database calls. See this SO thread for more information. There are exceptions like for Postgres there is a async driver, but these are not based on JDBC. In the NoSQL world there are more examples of async like the async mongo db driver. When you look at the recent blog post about the future of spring data, you’ll see reactive examples (but all for non JDBC). So therefore this is quite a hard sell. I think there is much buzz around it especially in the java world.
Since CUBA uses JPA as a ORM (which is based on JDBC), therefore the database access is blocking (with the normal thread pool model).

For HTTP requests i think we have to differentiate between the generic UI and the REST API as well as the Portal module. I know that for generic UI it’s based on Vaadin which uses atmosphere since a few versions. I’m not really aware if the server threads are non-blocking, but i’d assume not.

For the portal module, it is the case that the application developer is allowed to write their own Spring MVC controllers - so we’re are quite near to the metal here :slight_smile: Spring MVC has async support since quite some time, since the servlet spec 3.0 is async aware. Here are some more information about this topic.

So this we’re my two cents on that. I hope this helps :slight_smile:

Bye,
Mario

#5

Hi Oliver,

All parts of CUBA are written in good old blocking paradigm, using threads for asynchronous execution. We are not in a hurry to become a “reactive” framework by a number of reasons:

  • CUBA is designed for database-centric applications, and currently neither major databases nor data access layer in Java supports non-blocking access.

  • Performance benefits for an “average” applications are unclear - there is a lot of opinions on the internet. At the same time, everybody agrees that reactive programming is harder and debugging is MUCH harder.

So we are going to wait until the technology becomes more ubiquitous and mainstream - if that’s at all possible. Of course, we don’t mind to incorporate any non-blocking techniques if they come for free and don’t contradict with the current programming paradigm, as in the case of NIO connector in Tomcat for example.

#6

Hi Konstantin,
Thanks for clarifying this.
I think this only probably becomes a problem if there are a huge amount of users for an application and I think I will be using CUBA for some projects in the future.