So what I want to do is have different application properties for each http request that is sent to my application. I know that having profiles allows me to set up different property values for the same property. However this is only beneficial for if testing the application and switching the active profile each time. As if you have both profiles active at the same time if there is a conflicting property then one overrides the other.
In the main property that I want to include for each http request is the http header size so that I can limit the size of the header from each request. However at current I can only set this value once and have it consistent throughout the whole application.
Related
Tried with a simple spring boot application with actuator dependency, but not able to access http://localhost:8080/actuator/beans
I am able to access http://localhost:8080/actuator with the following output :
{"_links":{"self":{"href":"http://localhost:8080/actuator","templated":false},"health-component-instance":{"href":"http://localhost:8080/actuator/health/{component}/{instance}","templated":true},"health-component":{"href":"http://localhost:8080/actuator/health/{component}","templated":true},"health":{"href":"http://localhost:8080/actuator/health","templated":false},"info":{"href":"http://localhost:8080/actuator/info","templated":false}}}
ALso majorly the following url's are not accessible listed from here
/auditevents – lists security audit-related events such as user login/logout. Also, we can filter by principal or type among others fields
/beans – returns all available beans in our BeanFactory. Unlike
/auditevents, it doesn’t support filtering
/conditions – formerly known as /autoconfig, builds a report of conditions around auto-configuration
/configprops – allows us to fetch all #ConfigurationProperties beans
/env – returns the current environment properties. Additionally, we can retrieve single properties
/flyway – provides details about our Flyway database migrations
/health – summarises the health status of our application
/heapdump – builds and returns a heap dump from the JVM used by our application
/info – returns general information. It might be custom data, build information or details about the latest commit
/liquibase – behaves like /flyway but for Liquibase
/logfile – returns ordinary application logs
/loggers – enables us to query and modify the logging level of our application
/metrics – details metrics of our application. This might include generic metrics as well as custom ones
/prometheus – returns metrics like the previous one, but formatted to work with a Prometheus server
/scheduledtasks – provides details about every scheduled task within our application
/sessions – lists HTTP sessions given we are using Spring Session
/shutdown – performs a graceful shutdown of the application
/threaddump – dumps the thread information of the underlying JVM
Default management.endpoints.web.exposure.include, info, health
As actuator/health and actuator/info are provided by default . so that you will get the information
management.endpoints.web.exposure.include = * //will allow all endpoints
to be exposed
management.endpoints.web.exposure.include=health,info # Endpoint IDs that should be included or '*' for all.
management.endpoints.web.exposure.exclude= # Endpoint IDs that should be excluded or '*' for all.
management.endpoints.web.base-path=/actuator # Base path for Web endpoints. Relative to server.servlet.context-path or management.server.servlet.context-path if management.server.port is configured.
management.endpoints.web.path-mapping= # Mapping between endpoint IDs and the path that should expose them.
Securing Endpoint
management.endpoint.health.roles= # Roles used to determine whether or not a user is authorized to be shown details. When empty, all authenticated users are authorized. //for health
management.endpoint.health.show-details=always,never # When to show full health details.
Enable/Disable endpoints
management.endpoint.(endpointName).enabled=true # Whether to enable the health endpoint.
e.g. management.endpoint.health.enabled=true
Refer This for Manual Configurations
Refer This for More Details
I am trying to implement a sticky session based load balancing across two Tomcat instances using the Hazelcast Tomcat Web Session Replication. For testing purposes, I have deployed the application on two different Tomcat instances and the load balancing is handled through Apache HTTPD. The jvmroute parameters and the mod-proxy settings are fine and the load balancing has no issues.
The problem is with the session replication across the two instances. When the first server (currently serving the request) goes down the request is sent to the second server. The Hazelcast cluster identifies that the session is through fail-over and is copying the session with the new session id (suffixed with the jvmroute parameter of the second server) - as described in the Hazelcast documentation https://github.com/hazelcast/hazelcast-tomcat-sessionmanager#sticky-sessions-and-tomcat) . However for the failed-over request, the session attributes are getting updated in the older session(failed over jvmroute) and not getting replicated resulting in the failure of the subsequent request.
I have gone through the documentation but unable to find a resolution at this point. I am sure I am missing some setting as this would be a basic setting for a fail over scenario.
Can someone help me out? Please let me know if you need any additional details.
[UPDATE]
After tracing the flow, able to determine that the handleTomcatSessionChange in com.hazelcast.session.HazelcastSessionChangeValve is being called correctly. The request.changeSessionId(newSessionId) call happens and post this if I display the value of the requestedsession id, the value is updated. However, the session id by itself is not updated and this is resulting in the older id in a request.getSession().getId() call.
Working on a REST service based on Spring Boot with an embedded Tomcat I would like to limit the size of the request body for any HTTP method (POST, PUT, GET, ...).
I know of the maxPostSize property of a connector. But this property seems to limit only POST requests. Another possibility IMHO is to implement javax.servlet.Filter and to check the value of the Content-Length header.
Is there another way to achieve this that I am not aware of?
You may set the multipart.maxRequestSize property in application.properties. The default is 10Mb.
Im developping non OSGI app and i need to update the values of some properties used in camel routes (loaded BridgePropertyPlaceHolder).
So I thought:
To use Hawtio, the cool mangement console, in order update camel using JMX
Create a JMX MBean that will update the properties ..
I successfully create the MBean operations and call them using JMX, but I can't figure out how to update the camel routes that depends on these properties.
Is there a way to update the camel context externally?
Update:
Exemple of use case:when a remote server doesn't return response, we keep sending messages until we reach the max of unsuccessful attempt(messages without ack).
in camel we create a router pattern based on property loaded from file system.
This property can change occasionally, and we want to do this without restarting server, but the problem is that camel parse routes when starting context and i can't find no mean to update routes accordingly.
I am grateful for any proposal that could help:)
If you use Camel error handling to retry (redeliver) then you can use the retryWhile to keep retrying until you return false. This allows you to use java code etc, and that allows you to read the updated configuration option.
See more details at
http://camel.apache.org/exception-clause.html
And if you have a copy of Camel in Action book, see page 152
For what properties you want them to be dynamic.you can move those prop to some db and fetch them whenever you are reading.I think a redesign is required for your camel route.
Changing from endpoint parameters such as URLs etc., following procedure has to be used according to dynamic change endpoint camel:
stop the route
remove the route
change the endpoint
add the route
start the route
If the to endpoint has to be configurable, you may use the recipient list component. Here you may read properties from a database and/or from the filesystem using the appropriate Camel component.
I want to host a tomcat server, which will host 3 web applications. I want to get the total number of requests processed by my server(for any of the 3 web applications). Is there any log from where I can check the total number of requests processed by my server(including HTTP 404 requests)
Note : I can calculate the total requests processed by each individual application and get the total number of requests processed by my server, but the applications deployed in tomcat are third-party and i cant do any changes in it.
Basically, I am building a monitoring application for the tomcat server and I have to provide the total requests served in the application,
Also, My first thought was to over-ride the HTTPServletRequest class constructor in servlet-api.jar and put a static counter. since every request is mapped to HTTPServletRequest object, I guess it will do the job. But is it a good idea to over-ride the HTTPServletRequest or is there any existing solution available for this?
If you do choose to override the HTTPServletRequest class do not just add a static counter, this will cause your counter to reset itself each time the Server goes down/jvm reloads.
I think it might be a better option to either increment it from a database or save the value in a file each time. This way you do not loose your count even if something happens to the server and you have to restart it.
This is all assuming that there isn't already a Apache extension that already dose this and you do want to tinker with the HTTPServletRequest class.
You can use a special filter called Request Dumper Filter for this purpose.
According to official Tomcat Documentation:
The following entries in a web application's web.xml would enable the Request Dumper
filter for all requests for that web application. If the entries were added to
CATALINA_BASE/conf/web.xml, the Request Dumper Filter would be enabled for all web
applications.