We Keep Coding

How to configure the Thread Pool for a HTTP Server in Micronaut

I'm trying to configure a HTTP Server for an API made in Micronaut 3.7.5. Reviewing the Micronaut documentation I found many ways to do it and I not sure which is the best way.
Worker event-loop:. If I set a event-loop name not used
micronaut.server.netty.worker.event-loop-group
micronaut.server.netty.worker.threads
Default event-loop: This event-loop is shared with clients also, unless I specify a diferent event-loop for them
micronaut.netty.event-loops.default.num-threads
Parent event-loop: I cound't find any documentation about it and how to use it
micronaut.server.netty.parent.event-loop-group
micronaut.server.netty.parent.threads

How do I get data from a Flux in an AbstractGatewayFilterFactory

I have a ReactiveDiscoveryClient that provides a method Flux<ServiceInstance> getInstances(String serviceId). I want to use the result of that method in my GatewayFilterFactory's apply method. However,
ServiceInstance si = reactiveDiscoveryClient.getInstances(config.getServiceId()).block();
fails because the block operations are not allowed. Is there anyway around it?
What I've done is cheat since my ReactiveDiscoveryClient has an in-memory map that contains the services and I just provide an extra method that gets the value I need.

That's rare, as by default, those actions are allowed. From the Spring Cloud Documentation:
27.1. #EnableDiscoveryClient
Spring Cloud Commons provides the #EnableDiscoveryClient annotation. This looks for
implementations of the DiscoveryClient and ReactiveDiscoveryClient
interfaces with META-INF/spring.factories. Implementations of the
discovery client add a configuration class to spring.factories under
the org.springframework.cloud.client.discovery.EnableDiscoveryClient
key. Examples of DiscoveryClient implementations include Spring Cloud
Netflix Eureka, Spring Cloud Consul Discovery, and Spring Cloud
Zookeeper Discovery.
Spring Cloud will provide both the blocking and reactive service
discovery clients by default. You can disable the blocking and/or
reactive clients easily by setting
spring.cloud.discovery.blocking.enabled=false or
spring.cloud.discovery.reactive.enabled=false. To completely disable
service discovery you just need to set
spring.cloud.discovery.enabled=false.
At least for what it's told in the last paragraph, you should be able to perform a block(). Anyway, you could try by setting these params, as should be enough to be allowed to invoke it:
spring.cloud.discovery.blocking.enabled=true
spring.cloud.discovery.reactive.enabled=true
spring.cloud.discovery.enabled=true
Also, not sure if related, but note this warning as well (just in case)

How to add request timeout or connection timeout in traditional spring mvc application to prevent ''slow http post vulnerability"?

There are following points to make you understand about my application:
I have a traditional spring web application running on Wild-fly.
In my application I have view controller and other controllers.
I have web.xml file and jboss xml file to configure context path.
Request to controller comes through either ajax request or simple get
request from browser.
I want to keep safe my application from possible 'Slow HTTP Post Vulnerability'. For that I have decided if any request takes more than specified amount of time then my application release that connection and throw request time-out exception.
My question is :
How can I implement request time in traditional spring mvc application ?
Note : You are most welcome If you have any other solution to prevent 'slow HTTP post vulnerability'.

You could delegate each controller invocation to a separate thread and then monitor that thread if/until it breaches your timeout condition. Java's ExecutorService already supports something much like this with its awaitTermination() feature.
Using Spring's support for asynchronous controllers (or more generally; implementing non blocking services) would formalise this approach since (a) it would force you to delegate your controller invocations to a separate threadpool and (b) it would encourage you to safely manage the resources available in this threadpool. More details on this approach here and here.
But, however you perform this delegation once you have each controller invocation running in a separate thread (separate from the original invocation, I mean) you will then be able to control how long that thread can run and if it exceeds some configured timeout you can respond with a relevant HTTP status.

Spring security filters interfering with threaded request handling?

The title for this question was difficult as we're having trouble even diagnosing the exact source of our issue. Allow me to begin by framing the structure of the application and then follow up with the issue we're experiencing.
The Setup
We have a decently large, multi-module Spring 4.x application using Spring Security. Spring security advocates the use of filters that check attributes on a request to determine if it should be rejected or handled by the request handler. We make use of these and our authentication works perfectly for single requests. However, our authentication is based on a number of data models from our internal services. To access these data models in the filter, we inject "service beans" (quotes because they're actually #Components but comprise our service layer) into the filter. One of our filters, the EarlyLoadingFilter retrieves several such models based on request parameters and then places those models in the request's attributes before continuing with the chain.
Subsequent filters in the chain retrieves these models from the request's attributes and use them to determine whether the user is authorized.
All of the "service beans" that are injected in this way are marked with the following annotations:
#Component
#Scope(proxyMode = ScopedProxyMode.TARGET_CLASS, value = "request")
The Problem
We're experiencing what appears to be some thread-safety issues when saturating our server with requests. During normal usage, it performs exactly as we expect it to. However, under load, when a high volume of requests are handled in a short period of time, we find that a given request may receive a response based on the preceding request's data. That is, it seems like request attributes are being retained between requests.
Now, I realize that servlet filters are singletons, but the only instance variables we rely on in any of our filters are the autowired beans for the services.
Are we perhaps overlooking some critical configuration of Spring or Spring Security? Is there a way to leverage Spring's HandlerInterceptors to achieve the same result with our authentication without mucking about in servlet filters? Are we completely off the mark with thinking this is thread or filter related?
Thanks in advance for any help you might be able to offer, this issue has become infuriating!

Java webapps security constraints & custom security providers

I'm creating a restful web service using Resteasy. One thing I need to do is to secure the service using a standard HTTP auth request. The tricky part is that the service is multi-tenant and needs to use one of the path parameters to determine the security realm.
There are a lot of articles typical of this link which describe setting up a single-tenant service. What I can't find is what to configure, and what interfaces to implement to describe my own security which is based on a path parameter + the username in the HTTP authentication method.
I envision that prior to calling any of the application logic, tomcat/resteasy would call a SecurityProvider (or whatever) interface with the HttpServletRequest and have me either throw a 401 or return a SecurityContext that gets passed to the JAX-RS handlers. In that routine, I would inspect the path parameters, and make a determination based on parameter+username+password given in the Basic/Digest/Form.
Is there any such beast?

I thought I'd update this since there's bee little activity on this question.
It looks like there's no baked in feature to do what I envisioned, so instead I extended the RestEasy servlet and added the security checks in my override before passing control back to the stock RestEasy servlet.
Seems to work well.