We Keep Coding

Build a report in Apache Camel to measure transaction times

I want to make some performance tests on my Camel app (I'm using Spring Boot for development) and build a report based on the time that each transaction took to finish, but I'm not quite sure what will be the best approach (first time doing something like this).
This app is layered in three parts: each part will publish a message to a JMS queue, so the next part can pick it up. So, I know that I can get the elapsed time for each Exchange like this:
List<MessageHistory> historyList = exchange.getProperty(Exchange.MESSAGE_HISTORY, List.class);
for (MessageHistory history : historyList) {
history.getElapsed();
}
But, as I will have three different parts inside the app I will get three different Exchanges. Each message coming inside the app will have an ID inside the payload so maybe I can group each transaction using that (unless there is a more Camel-oriented way to do it that I'm not aware of).
I can write something custom to make the report I suppose, but I'm wondering if maybe there are some frameworks that I can use.
Any recommendations are appreciated
Thanks!

I suppose you want to capture the total time it took for the message to traverse in your application. If so, you can use camel interceptors.
You can capture the starting time using the FromInterceptor, save the time in a property, and get the end time using the sendToEndPoint interceptor. Calculate the time it took for the message to travel

Events handling between Spring boot and Reactjs

This might seem like an easy solution got on the internet, but believe me, I have seen through a lot of examples and couldn't figure out which approach to choose.
Requirement :
I have a subscriber at the application service(spring boot/Java) end, subscribed to blockchain events( corda ). I want to push this event to UI (ReactJS) whenever there is a change in state.
I could subscribe to the blockchain events successfully but stuck with multiple in-complete or tangled ideas of pushing it to the UI and how UI would receive my events ( kindly don't suggest paid services, APIs, Libraries etc ).
I have come across and tried out all approach, since I'm newly working on events I need some ray of light as to how to approach towards a complete solution.
Publisher-subscriber pattern
Observable pattern
Sse emitter
Flux & Mono
Firebase ( a clear NO )
+Boggler :
events handling between service and UI , should it be via API/endpoint calls or can it be emitted just in air( i'm not clear) and based on event name can we subscribe to it in UI ?
should i have two APIs dedicated for this ? one trigger subscribe and other actually executes emitter ?
If the endpoint is always being heard doesn't it needs dedicated resource ?
I basically need a CLEAR approach to handle this.
Code can be provided based on demand

I see you mention you are able to capture events in Spring Boot. So you are left with sending the event information to the front-end. I could think of three ways to do this.
Websockets: Might be an over-kill, as I suppose you won't need bi-directional communication.
SEE: Perhaps a better choice than WebSockets.
Or simply Polling: Not a bad choice either, if you are not looking for realtime notifications.

Yes Long Polling.
The solution seems to be pretty simple. Make the connection once and let them wait for as long as possible. So that in the meanwhile if any new data comes to the server, the server can directly give the response back. This way we can definitely reduce the number of requests and response cycles involved.
You will find multiple implementation examples of How Long Polling is done as part of Spring Boot project on internet.

Building proxies hub

First of all I'm gathering information about this question and so that i could implement this feature in a more elegant way.
Let's look at the picture below
The target server (green circle)
This is an api server that I use to fetch some data.
Features:
Only https connection
Response in json format.
Can accept get requests like these [ https://api.server.com/user=1&option&api_key=? ]
Proxy controller (blue square)
It's a simple server that stores list of proxies; Send and receive some data; And I want to talk about the software that i will to run on top of it.
Features:
Proxy list
Api keys list
I think it should be a hashmap that stores ip=>token list or database table if I want to scale my application.
Workers
Just analyze a json response and pass data to the db.
Let's go closer to the proxy controller server.
The first idea:
Create newFixedThreadPoolExecutor
Pass url/token to worker: server.submit(new Worker(url, token, proxy))
Worker analyze the data and pass it to db.
But in my opinion this solution is quite big and hard to maintain, I want to engage endpoint that gather stats, kill or spawn new workers and so on.
The second idea:
Worker generates an request like https://host/user=1&option=1
Pass it to the Proxy controller
Proxy controller assign to the request the api key and proxy server
Execute the request
Accept the response
Pass it back to a worker (I think that the best idea is to put a load balancer between workers and proxy controller).
This solution seems to me quite hacky. For example if the worker is dead the proxy server sends bunch of requests to the dead worker and it could led to dataloss.
The third idea:
The same as the second but instead of sending data directly to the worker the proxy controller pass it to some bus. I find some information about apache camel that allow me to organize this solution. In this case the dead worker is dead worker and dataloss equals zero (maybe).
Of course all three cases don't handle an errors. Some errors can be solved by resending the request with additional data. Some errors can be solved by re-span the workers.
So in your opinion what is the best solution in this case? Do I miss some hidden problems that can appear later? Which tools I should use?
Thanks

What are trying to reach?
Maybe you consider using this architecture:
NGINX (proxy + load balance) -> WORKER SERVERS -> DB SERVER (maybe use some NoSQL like Cassandra)

Pausing and notifying particular threads in a Java Webservice

I'm writing a Java webservice with CXF. I have the following problem: A client calls a method from the webservice. The webservice has to do two things in parallel and starts two threads. One of the threads needs some additional information from the client. It is not possible to add this information when calling the webservice method, because it is dependent from the calculation done in the webservice. I cannot redesign the webservice becuase it is part of a course assignement and the assignements states that I have to do it this way. I want to pause the thread and notify it when the client delivers the additional information. Unfortunately it is not possible in Java to notify a particular thread. I can't find any other way to solve my problem.
Has anybody a suggestion?

I've edited my answer after thinking about this some more.
You have a fairly complex architecture and if your client requires information from the server in order to complete the request then I think you need to publish one or more 'helper' methods.
For example, you could publish (without all the Web Service annotation):
MyData validateMyData(MyData data);
boolean processMyData(MyData data);
The client would then call validateMyData() as many times as it liked, until it knew it had complete information. The server can modify (through calculation, database look-up, or whatever) the variables in MyData in order to help complete the information and pass it back to the client (for updating the UI, if there is one).
Once the information is complete the client can then call processMyData() to process the complete request.
This has the advantage that the server methods can be implemented without the need for background threads as they should be able to do their thing using the request-thread supplied by the server environment.
The only caveat to this is if MyData can get very large and you don't want to keep passing it back and forth between client and server. In that case you would need to come up with a smaller class that just contains the changes the server wants to make to MyData and exclude data that doesn't need correcting.

IMO it's pretty odd for a web service request to effectively be incomplete. Why can't the request pass all the information in one go? I would try to redesign your service like that, and make it fail if you don't pass in all the information required to process the request.
EDIT: Okay, if you really have to do this, I wouldn't actually start a new thread when you receive the first request. I would store the information from the first request (whether in a database or just in memory if this is just a dummy one) and then when the second request comes in, launch the thread.

Get status of servlet request before the response is returned

Good evening,
I am in the process of writing a Java Servlet (Struts 2, Tomcat, JSP etc) which is capable of doing some fairly complex simulations. These can take up to 2 minutes to complete on the and will return a graph of the results. It is trivial to calculate the percentage of the simulation completed because the process works by repeating the same calculations 1000s of times.
I would be interested to know if anyone has ever tried to use client side technology to provide any estimate of the percentage complete. I.e query the servlet processing to get the number of cycles completed at various point throughout the simulation. This could then be displayed as a bar in the client browser.
Any thoughts, advice, resources would be much appreciated.
Thanks,
Alex

In your database, have a table to maintain a list of simulations along with their server-calculated progress.
In your web-application, use AJAX to query the server every few seconds (1-20 depending on load is what I'd go with) and update a graphical progress bar. Most javascript libraries have simple timer-based AJAX functions to do exactly this sort of thing.
There's a few details to figure out, such as whether or not completed simulations remain in the DB (could be useful logging info), but overall, this should be fairly simple.

You could encapsulate your response in a mime/multipart message and sends your updates until you have a full response done.
Bugzilla uses this in their search to show "Searching ..."-screen until the searchresult is done.

If you want to use plain Struts2, you should take a look at the ExecuteAndWait Interceptor.
It works by the old refresh-with-timeout method. Sure, it has lower coolness factor than some AJAX thing, but it's simple and works (I've used it).
Struts2 takes care (by using this interceptor) of executing the action method (which would typically take a long time) in a separate thread, and it returns a special result wait until the work is completed. You just have to code a jsp that shows some "waiting..." message for this result, and make it refresh to the same action, repeatedly, with (say) two or three seconds of timeout. The jsp has access to the action properties, of course, hence you can code some getProgress() method to show a progress message or bar.

AJAX is the way to go here.