WebServiceTemplate performance issue with spring boot - spring-boot

I am consuming soap web services using WebServiceTemplate its working fine with good performance in spring3+ .
spring :- 3.2.4.RELEASE
spring-ws-core :- 2.1.4.RELEASE
spring-ws-support :- 2.1.4.RELEASE
spring-ws-security :-2.1.4.RELEASE
Class for calling soap service
SaajSoapMessageFactory messageFactory = new SaajSoapMessageFactory(MessageFactory.newInstance());
messageFactory.afterPropertiesSet();
WebServiceTemplate webServiceTemplate = new WebServiceTemplate(messageFactory);
Jaxb2Marshaller marshaller = new Jaxb2Marshaller();
marshaller.setContextPath("some package");
marshaller.afterPropertiesSet();
webServiceTemplate.setMarshaller(marshaller);
webServiceTemplate.setUnmarshaller(marshaller);
webServiceTemplate.afterPropertiesSet();
webServiceTemplate.setInterceptors(clientInterceptors);
webServiceTemplate.setMessageSender(webServiceMessageSenderWithAuth);
webServiceTemplate.setDefaultUri(url);
Output result= ((JAXBElement<Output >) webServiceTemplate.marshalSendAndReceive(jaxbRequest)).getValue();
Configuration File
#Configuration
public class WebServiceConfiguration {
#Autowired
private SaajSoapMessageFactory messageFactory;
#Autowired
private WebServiceMessageSenderWithAuth webServiceMessageSenderWithAuth;
#Bean
public Wss4jSecurityInterceptor getWss4jSecurityInterceptor(#Value("${WSDL.UserName}") String userName,
#Value("${WSDL.Password}") String password) {
Wss4jSecurityInterceptor wss4jSecurityInterceptor = new Wss4jSecurityInterceptor();
wss4jSecurityInterceptor.setSecurementActions("UsernameToken");
wss4jSecurityInterceptor.setSecurementPasswordType("PasswordText");
wss4jSecurityInterceptor.setSecurementUsername(userName);
wss4jSecurityInterceptor.setSecurementPassword(password);
return wss4jSecurityInterceptor;
}
#Bean
public SaajSoapMessageFactory getSaajSoapMessageFactory() {
return new SaajSoapMessageFactory();
}
#Bean
public ClientInterceptor[] clientInterceptors(Wss4jSecurityInterceptor wsSecurityInterceptor) {
return new ClientInterceptor[] { wsSecurityInterceptor };
}
}
Performance result
Timings -- around 500ms average time , max time :- 1 sec
Spring Boot 1.5.20.RELEASE and 2.2.2.RELEASE
With spring boot same code without any change takes around 4sec for first call and if continue hitting the same then takes around 2sec for
Performance result with spring boot
First Call :- 4 sec
Subsequent calls without interval (1-10 sec gap) :- 2 sec to 800 ms
Its keep on decreasing while keep hitting the same call again and again with less interval and goes down to spring mvc 3 like result but if tried again after some interval like 5 min then again follow the same pattern
If same tried after 5 mins then again the result is same for first and further calls.
Note:- With spring boot i have tried wss4j as well instead of wss4j2
Also tried AxiomSoapMessageFactory but no luck
i have tried connection keep alive etc etc but still no luck

Caching could be one of the factors for the results above
Caching is a mechanism to enhance the performance of a system. It is a temporary memory that lies between the application and the persistent database. Cache memory stores recently used data items in order to reduce the number of database hits as much as possible.
JVM warm-up effect
When a JVM based app is launched, the first requests it receives are generally significantly slower than the average response time. This warm-up effect is usually due to class loading and bytecode interpretation at startup.
For further optimizing the application, use the Hypersistence Optimizer, which allows you to get the most out of JPA and Spring boot by scanning your application configuration and mappings.
Running Hypersitence Optimizer is very easy, as you just have to pass the EntityManagerFactory instance to the HypersistenceOptimizer object constructor, and call the init method
I suppose you already did, but if you haven't, take a look at Faster StartUp and implement the fixes suggested there.
For disabling scanning with embedded tomcat, there is a suggestion in the comments here Tomcat JarScanning
Enable Asynchronous Calls in a SpringBootApplication
#EnableSync
#SpringBootApplication
public class App {
public static void main(String[] args) {
SpringApplication.run(App.class, args);
}

So the issue is not with code. I finally deployed it on jboss Wildfly and bang..
It just start performing really well without a single line change.
Now its taking around 300ms to 500ms. So the problem is with embedded tomcat and embedded jetty is not good

Related

Spring Integration Flow with #Restcontoller Timing issue

A simple #RestController is connected with a #MessagingGateway to an IntegrationFlow.
After a load test we saw within the tracing that we lose "a lot of time" before even starting the processing within the flow:
Tracing result
In this example we can see that over 90ms spend befor sending the message to the flow.
Did anyone have some idea what leads to this behavior?
As far as I understood the documentation, everything is handled in the sender thread and therefore no special worker threads are created.
We use the Restcontroller since we need to create the documentation with springdoc-openapi-ui
ExampleCode:
RestController
#RestController
public class DescriptionEndpoint {
HttpMessageGateway httpMessageGateway;
public Result findData(#Valid dataRequest dataRequest) {
final Map<String, Object> headerParams = new HashMap<>();
return httpMessageGateway.basicDataDescriptionFlow(dataRequest, headerParams);
}
}
Gateway
#MessagingGateway
public interface HttpMessageGateway {
#Gateway(requestChannel = "startDataFlow.input")
Result basicDataDescriptionFlow(#Payload dataRequest prDataRequest, #Headers Map<String, Object> map);
}
IntegrationFlow
public class ExampleFlow {
#Bean
public IntegrationFlow startDataFlow() {
return new FlowExtension()
.handle(someHandler1)
.handle(someHandler2)
.handle(someHandler3)
.get();
}
}
After adding some more traces I realized, that this timing issue is caused by my spring security configuration.
Unfortunatelly, i thought, the span is only representing the time after the start of findData(..). But it seems, the tracing starts already in the proxy methods and security chain.
After improving some implementation on our JWTToken filter, the spend times for these endpoints are OK.

Spring Integration Framework - Slowness in registering flows dynamically

We are developing a Spring Boot (2.4.0) application that uses Spring Integration framework(5.4.1) to build SOAP Integration flows and register them dynamically. The time taken to register ‘IntegrationFlow’ with ‘FlowContext’ is increasing exponentially as the number of flows being registered increase.
Following is a quick snapshot of time taken to register flows:
5 flows – 500 ms
100 flows – 80 sec
300 flows – 300 sec
We see that first few flows are taking about 100ms to register, and as it reaches 300 it is taking up to 7 sec to register each flow. These flows are identical in nature (and they simply log an info message and return).
Any help to resolve this issue would be highly appreciated.
SoapFlowsAutoConfiguration.java (Auto Configuration class that registers Flows dynamically(manually))
#Bean
public UriEndpointMapping uriEndpointMapping(
ServerProperties serverProps,
WebServicesProperties webServiceProps,
IntegrationFlowContext flowContext,
FlowMetadataProvider flowMetadataProvider,
#ErrorChannel(Usage.SOAP) Optional<MessageChannel> errorChannel,
BeanFactory beanFactory) {
UriEndpointMapping uriEndpointMapping = new UriEndpointMapping();
uriEndpointMapping.setUsePath(true);
Map<String, Object> endpointMap = new HashMap<>();
flowMetadataProvider
.flowMetadatas()
.forEach(
metadata -> {
String contextPath = serverProps.getServlet().getContextPath();
String soapPath = webServiceProps.getPath();
String serviceId = metadata.id();
String serviceVersion = metadata.version();
String basePath = contextPath + soapPath;
String endpointPath = String.join("/", basePath, serviceId, serviceVersion);
SimpleWebServiceInboundGateway inboundGateway = new SimpleWebServiceInboundGateway();
errorChannel.ifPresent(inboundGateway::setErrorChannel);
endpointMap.put(endpointPath, inboundGateway);
IntegrationFlowFactory flowFactory = beanFactory.getBean(metadata.flowFactoryClass());
IntegrationFlow integrationFlow =
IntegrationFlows.from(inboundGateway).gateway(flowFactory.createFlow()).get();
flowContext.registration(integrationFlow).register();
});
uriEndpointMapping.setEndpointMap(endpointMap);
return uriEndpointMapping;
}
SoapFlow.java (Integration Flow)
#Autowired private SoapFlowResolver soapFlowResolver;
#Autowired private CoreFlow delegate;
#Override
public IntegrationFlow createFlow() {
IntegrationFlow a =
flow -> flow.gateway(soapFlowResolver.resolveSoapFlow(delegate.createFlow()));
return a;
}
SoapFlowResolver.java (Common class used by all integration flows to delegate request to a Coreflow that is responsible for business logic implementation)
public IntegrationFlow resolveSoapFlow(
IntegrationFlow coreFlow) {
return flow -> {
flow.gateway(coreFlow);
};
}
CoreFlow.java (Class that handles the business logic)
#Override
public IntegrationFlow createFlow() {
return flow -> flow.logAndReply("Reached CoreFlow");
}
You are crating too many beans, where each of them checks the rest if it wasn't created before. That's how you get increase with the start time when you add more and more flows dynamically.
What I see is an abuse of the dynamic flows purpose. Each time we decide to go this way we need to think twice if we definitely need to have the whole flow as a fresh instance. Again: the flow is not volatile object, it registers a bunch of beans in the application context which are going to stay there until you remove them. And they are singletons, so can be reused in any other places of your application.
Another concern that you don't count with the best feature of Spring Integration MessageChannel pattern implementation. You definitely can have some common flows in advance and connect your dynamic with those through channel between them. You probably just need to create dynamically a SimpleWebServiceInboundGateway and wire it with the channel for your target logic which is the same for all the flows and so on.

Feign Client throws HystrixTimeoutException even though the underlying request is successful

I have a feign client like this with endpoints to two APIs from PROJECT-SERVICE
#FeignClient(name = "PROJECT-SERVICE", fallbackFactory = ProjectServiceFallbackFactory.class)
public interface ProjectServiceClient {
#GetMapping("/api/projects/{projectKey}")
public ResponseEntity<Project> getProjectDetails(#PathVariable("projectKey") String projectKey);
#PostMapping("/api/projects")
public ResponseEntity<Project> createProject(#RequestBody Project project);
}
I'm using those clients like this:
#Service
public class MyService {
#Autowired
private ProjectServiceClient projectServiceClient;
public void doSomething() {
// Some code
ResponseEntity<Project> projectResponse = projectServiceClient.getProjectDetails(projectKey);
// Some more code
}
public void doSomethingElse() {
// Some code
ResponseEntity<Project> projectResponse = projectServiceClient.createProject(Project projectToBeCreated);
// Some more code
}
}
My problem is, most of the times (around 60% of the time), either one of these Feign calls result in a HystrixTimeoutException.
I initially thought there could be a problem in the downstream micro service (PROJECT-SERVICE in this case), but that is not the case. In fact, when getProjectDetails() or createProject() is called, the PROJECT-SERVICE actually does the job and returns a ResponseEntity<Project> with status 200 and 201 respectively, but my fallback is activated with the HystrixTimeoutException.
I'm trying in vain to find what might be causing this issue.
I, however, have this in my main application configuration:
feign.hystrix.enabled=true
feign.client.config.default.connect-timeout=5000
feign.client.config.default.read-timeout=60000
Can anyone point me towards a solution?
Thanks,
Sriram Sridharan
Hystrix's timeout is not tied to that of Feign. There is a default 1 second execution timeout enabled for Hystrix. You need to configure this timeout to be slightly longer than Feign's, to avoid HystrixTimeoutException getting thrown earlier than desired timeout. Like so:
feign.client.config.default.connect-timeout=5000
feign.client.config.default.read-timeout=5000
hystrix.command.default.execution.isolation.thread.timeoutInMilliseconds=6000
Doing so would allow FeignException, caused by timeout after 5 seconds, to be thrown first, and then wrapped in a HystrixTimeoutException

Spring data rest base path is loosing it's #RepositoryRestResource links after running an unkown period of time

I have a very strange behavior since I updated to Spring Boot v2.2.6-RELEASE.
My spring data rest base path (/api/v1) is loosing it's #RepositoryRestResource links. Custom links are still available.
After a server restart I got:
After an unkown period of time (2-3 days) I got:
My base path it customized this way:
#Bean
public RepresentationModelProcessor<RepositoryLinksResource> globalLinkProcessor() {
// do not replace with lambda!!!
return new RepresentationModelProcessor<RepositoryLinksResource>() {
#Override
public RepositoryLinksResource process(final RepositoryLinksResource repositoryLinksResource) {
repositoryLinksResource.add(linkHelper.newLinkFromMethodInvocation(
WebMvcLinkBuilder.methodOn(FileProcessorController.class).status(), "fileProcessor"));
repositoryLinksResource.add(linkHelper.newLinkFromMethodInvocation(
WebMvcLinkBuilder.methodOn(CurrentUserController.class).whoAmI(), "whoAmI"));
repositoryLinksResource.add(linkHelper.newLinkFromMethodInvocation(
WebMvcLinkBuilder.methodOn(UserController.class).listOperations(), "users"));
repositoryLinksResource.add(linkHelper.newLinkFromMethodInvocation(
WebMvcLinkBuilder.methodOn(StatisticController.class).listOperations(), "statistics"));
return repositoryLinksResource;
}
};
}
There is NO exception in any log output. When I debug from my local machine everything is fine. I am not getting any hands on it. Can anyone help here?
Thanks for reading,
Christian
An update to Spring Boot v2.3.0-RELEASE solved the problem. (until now)

jdbc connection pool using ThreadpoolExecutor in spring boot

I have an application that runs through multiple databases and for each database runs select query on all tables and dumps it to hadoop.
My design is to create one datasource connection at a time and use the connection pool obtained to run select queries in multiple threads. Once done for this datasource, close the connection and create new one.
Here is the Async code
#Component
public class MySampleService {
private final static Logger LOGGER = Logger
.getLogger(MySampleService.class);
#Async
public Future<String> callAsync(JdbcTemplate template, String query) throws InterruptedException {
try {
jdbcTemplate.query(query);
//process the results
return new AsyncResult<String>("success");
}
catch (Exception ex){
return new AsyncResult<String>("failed");
}
}
Here is the caller
public String taskExecutor() throws InterruptedException, ExecutionException {
Future<String> asyncResult1 = mySampleService.callAsync(jdbcTemplate,query1);
Future<String> asyncResult2 = mySampleService.callAsync(jdbcTemplate,query2);
Future<String> asyncResult3 = mySampleService.callAsync(jdbcTemplate,query3);
Future<String> asyncResult4 = mySampleService.callAsync(jdbcTemplate,query4);
LOGGER.info(asyncResult1.get());
LOGGER.info(asyncResult2.get());
LOGGER.info(asyncResult3.get());
LOGGER.info( asyncResult4.get());
//now all threads finished, close the connection
jdbcTemplate.getConnection().close();
}
I am wondering if this is a right way to do it or do any exiting/optimized solution that out of box I am missing. I can't use spring-data-jpa since my queries are complex.
Thanks
Spring Boot docs:
Production database connections can also be auto-configured using a
pooling DataSource. Here’s the algorithm for choosing a specific
implementation:
We prefer the Tomcat pooling DataSource for its performance and concurrency, so if that is available we always choose it.
Otherwise, if HikariCP is available we will use it.
If neither the Tomcat pooling datasource nor HikariCP are available and if Commons DBCP is available we will use it, but we
don’t recommend it in production.
Lastly, if Commons DBCP2 is available we will use it.
If you use the spring-boot-starter-jdbc or
spring-boot-starter-data-jpa ‘starters’ you will automatically get a
dependency to tomcat-jdbc.
So you should be provided with sensible defaults.

Resources