I am trying to learn Grizzly. My background is in .NET. When I read through Grizzly's tutorials, a few things confused me.
My confusion is related to the basic difference between HttpHandler and FilterChain. What I understood is that we can create custom filters which can act upon requests and then invoke the next item in a filter chain.
Is a filter chain kind of a pipeline for processing incoming requests? HTTP handlers do the same thing, but only for HTTP requests, right? What is the basic difference between the two, and where do they fit together?
It would be helpful to have a diagram which shows the network listener, filter chain and HTTP handler all fitting together and processing requests.
Filter and FilterChain are the core abstractions in the Grizzly framework. They are used to implement any protocol, and HTTP is one of them.
HttpServer and HttpHandler are higher-level abstractions. They provide a Servlet-like API to work with HTTP requests. The HttpServer, under the hood, is built on top of FilterChain. Filters and HttpHandler represent a piece of logic that processes HTTP requests sent for the specific URL, which you set when registering an HttpHandler on an HttpServer.
Coming back to the HttpServer vs. FilterChain question, here is an example of how HttpServer's FilterChain looks:
HTTP protocol: TransportFilter <-> HttpCodecFilter <-> HttpServerFilter
HTTPS protocol: TransportFilter <-> SslFilter <-> HttpCodecFilter <-> HttpServerFilter
Did that help?
Related
Our use case is to design a micro-service for caching. This micro-service would use Redis as its back-end caching layer. Micro-service would first do some computation before storing the data to Redis. Now, as our micro-service provides capability to cache data, other micro-services should be able to use it for caching data. So, considering this use case, which transport layer (from other service to our caching service) should be better for us ? So far, our thought process has been that since we have to provide caching service, our transport layer should be fast enough. We have been thinking of below options 1. Websocket 2. Http2 3. GRPC (which is over http2) 4. REST (over http) - This might turn out to be very inefficient as it would have the overhead of creating and closing the connection for each request.
Any pointers on this would be helpful.
As per the design and option you have mentioned above, I feel GRPC is the best way to achieve the required goal.
Background : I am using spring boot with embedded jetty. My app calls bunch of rest apis. For calling these rest apis I use spring rest template.
Question: Is Spring rest template any good at high concurrency? Searching on the web search suggests moving to reactive but still there are apps which are written in blocking way and need to continue that way. Question is what alternate is there or what can be done to make rest template more responsive under heavy load. PoolingHttpClientConnectionManager improves things a bit but essentially still not at par with is required.
There are suggestions to move to rest easy and other http clients but no slid reasoning behind it. End of the day, they all make pool of connections and essentially works the same. Please note, reactive is not an option yet. This question is very specific to traditional blocking rest calls. Any suggestions in optimizing connection pooling or using rest template right will be of great help.
RestTemplate does not do an actual rest call by itself, its just a "wrapper" - a convenient API.
Now when it comes to connection pooling, by default it doesn't use any kind of pooling and just opens URL connections available in Java anyway. No third-parties are required, but performance is not so good.
You can configure rest template to use, say, OkHttp Client under the hood. See here for different ways to work with different clients. The interesting part is that its possible to configure connection pools there and achieve a better performance.
So you should really check what exactly the expected performance is and configure the connection pool accordingly.
Now one more thing about Reactive stuff - it won't give you a performance gain, however it will allow to serve better multiple concurrent requests by reusing resources more efficiently. However if you'll measure how long it takes to perform one single request - its not expected to be performed faster.
In other words you should consider the transition to reactive stack if the application has too many concurrent requests that it can't serve, but not if you want to process every single request faster.
Spring RestTemplate is used to write application level code. It obtains the HTTP connection from ClientHttpRequestFactory implementation which is what glues low-level HTTP client library to Spring e.g. HttpComponentsClientHttpRequestFactory for Apache HTTP Client.
Bottom line, in most cases you have to tune the underlying low-level HTTP client library and not RestTemplate when you are tuning outgoing requests to external APIs.
You are confusing a lot of concepts in your question. Try understanding what is Reactive programming, HTTP, HTTP pipelining, and TCP/IP before you start tuning anything. Otherwise you won't find where is your code's bottleneck and you will end up tuning wrong part of the software stack.
I have an spring boot application that pulls message from an cloud message queue and put it back to a cloud db. I realize that my program is single thread(I am not using request mapping, just pull,process,put to db). I want Spring handle concurrency things. So can I make a dispatcher function, which calls controller in the application with #RequestMapping?
#RestController
#RequestMapping("/test")
public class GatewayController {
#RequestMapping("/service")
public void InvokeService(...) {...}
}
I need mutithread to call other service for response, which I don't want it to block others. If I recieve 10 messages, I want it to call /test/service... which have 10 threads processing them.
My question is:
Will Spring make the controller multithread?
How to call its own controller? Send request to the url? (I don't need response from controller, just let controller call a service to put response in a db on could)
RequestMapping is MVC thing - intended to issue http requests. And yes, it uses tomcat under the hood.
If you'll inject RestController into your class it won't issue any HTTP requests, you'll only call the controller as a regular bean. If you consume messages in one thread, it won't become multithreaded to answer your first question.
You can, of course, create HTTP request but frankly it's just wrong. So don't do it. This answers your second question to some extent :)
Now, there is nothing wrong conceptually if your microservice acts as a consumer and producer and deals with queues, not all microservices have to be accessible via HTTP.
In order to work in a multi threaded environment:
Check whether you can consume messages in a multi-threaded manner. Maybe the client of your "cloud message queue" offers multi-threaded configuration (thread pool or something).
If it's not possible, create a thread pool executor by yourself and upon each message submit the processing task to this thread pool. This will make the processing logic multithreaded with a parallelism level confined by the thread pool size and thread pool configurations.
Its an old question asked by someone, e.g. how to log Spring 5 WebClient call, Spring Boot - How to log all requests and responses with exceptions in single place?
Above solutions have limitation, e.g. webclient solution can't log body info and not sure the log level can be dynamically changed without restart.
So, as a spring webclient consumer, because webclient wrap low level things for us, e.g. http client, servlet, http stuff, etc. So I think its natural for webclient to give us some additional info as titled, because these info is more often needed, especially when debugging, trouble shooting. you know sometime we print the entity bean may be not exactly the http messages send out or received. and also sometime we need to know the header info. all these info can be logged based on dynamically configurable log level. So its better webclient can supply an interface to get these info from somewhere and let consumer to use it convenient.
Thanks.
I was experimenting with reactive web framework.I have certain question regarding how it will work.
In typical application,we have datastore(Relational or No SQL).
Application Layer(Controllers) to connect to store and get the Data.
Client Layer(Calls your API End Points) and get the data.
To best of my knowledge,there are no async or reactive drivers published by Vendors.Only Mongo and may be Cassandra has reactive drivers).
Controller layer will beam back the data using Mono or Flux or Single.
Client layer will be consuming this data.
Since HTTP is synchronous in nature,how will client layer or application benefit from reactive support in Spring.
Question:Let us says I have 10 records in JSON coming from my Flux response.Does it mean,my client will get data in stream or entire data set will be fetched first at client side and then process of consuming it will be reactive in nature.Currently ,we have InputStream as a response of service call,which is blocking in nature,due to design of HTTP protocol.
Question:Does it then make sense to have reactive architecture for typical web application,when very medium on which we are going to get response is Blocking in Nature.
Spring Web Reactive makes use of Servlet 3.1 non-blocking I/O and runs on Servlet 3.1 containers. It also runs on non-Servlet runtimes such as Netty and Undertow. Each runtime is adapted to a set of shared, reactive ServerHttpRequest and ServerHttpResponse abstractions that expose the request and response body as Flux with full backpressure support on the read and the write side.
Source:
https://docs.spring.io/spring-framework/docs/5.0.0.M1/spring-framework-reference/html/web-reactive.html
Datastore vendors and OSS communities are working on that. There's already support for Cassandra, Couchbase, MongoDB and Redis in Spring Data Kay.
I think you're conflating the HTTP protocol itself and blocking Java APIs. You're not getting the full HTTP request or response in one big block, so the HTTP procotol is not synchronous. The underlying networking library you choose also drives the choice between blocking or non-blocking I/O.
Now about your HTTP client question: if you're using WebClient, the returned Flux will emit elements as soon as they're available. The underlying libraries are reading and decoding messages as soon as possible, while still respecting backpressure.
I'm not sure I get your last question - but if you're wondering when and why you should use a reactive approach: this approach has benefits if you're already running into scalability/efficiency issues, or if your application is communicating with many external services and is then sensitive to latency. See more about that in the Spring Framework 5.0 FAQ.