I have a data-push web service implemented in REST which pushes the data in database.
Now I want to create one more web service which will take input from a data-push web service and perform some business logic for any alerts. If any alert is present then it will call an alert service. In this case data-push web service should detach as soon as it posts the required data.
My doubt is if there are too many request on data-push web service - lets say for every second - then how will it handle threading mechanism and post on new web service?
If you are worried about the throughput of the service pushing data, you can queue the data push requests up and have a pool of worker threads process them as time and system resources permit.
The queuing mechanism could be any number of solutions depending on your scalability and throughput requirements:
In-Memory
JMS Messaging Middleware
Relational Database
Distributed Cache
Related
We are trying to migrate our legacy system to Micro service
With Paas environment, we have scheduler jobs to trigger and put messages in MQ one by one and we have MQ listener in our Microservice to get message and create request and send request to external party.
Here the problem comes our micro service is capable doing Asynchronous call to external service, but our external service is not able to handle Asynchronous call so it is returning wrong data.
For example, we are hitting external service with 40 to 60 request per minute and external service is capable to handle only 6 request per minute.
So how can I make the MQ listener to process slowly.
I have tried reducing setMaxConcurrenceConsumer to 1 and
Used observable.toblocking.single() to make the process to run in only one thread.
We use RxJava in our micro service.
It sounds like either your micro service or the external service is not following the use case for Request-Reply messaging.
(1) Is the external service setting the Reply's message Correlation ID with the Request message's Message ID?
(2) Is your micro service performing an MQGET with the matching option of getting by Correlation ID.
You can blame the external service for the error but if your micro service is actually picking up the wrong message then it is your application's fault. i.e. Does your micro service simply get the "next" message on the queue?
Read this answer: How to match MQ Server reply messages to the correct request
Here's a explanation (looks like from the 90's but has good information): https://www.enterpriseintegrationpatterns.com/patterns/messaging/RequestReplyJmsExample.html
In long term approach we are planning to migrate the External service to as well.
In short time i have fixed it using the observable.toblocking.single() ,thread.sleep(), and setMaxConcurrenceConsumer() to 1 so only one thread will run at a time. which will avoid the Asynchronous call to external service.The sleep time will set dynamically with some analysis done on the external service.
I've got a legacy monolith application that I have to redesign. Unfortunately, the mandate is to redesign in bite-sized approaches.
At the moment, I need to implement a new public facing web-service for a particular module. I'm taking advantage of the situation to split it off into its own service. However, I am stuck with an issue. The server generated GUI (struts monolith) needs some data from my microservice. The obvious answer is to provide a REST interface (JSON/Protocol Buffers, etc) in the web service for my monolith to consume in order to provide results to the user. But is this my only choice?
Ideally, I would like to move to asynchronous communications between the monolith and the service, but what do I do when a user needs specific data from the microservice? How can one do that in an asynchronous process? With the user waiting on the GUI (a synchronous event), how can I have the communication protocol between the GUI and the webservice not be synchronous as well?
In this particular instance, the user will use the microservice to upload data in bulk (csv file). The microservice will process the data and provide options to the user to manipulate the data once ready (all via API calls). The business wants an option in the GUI to view/download the uploaded file. Essentially, the monolith (responsible for the GUI) needs to request the file from the service and return it to the user.
Is there any way to structure this design without using a synchronous IPC between the monolith and the microservice?
I am currently working on order management system for ecommerce portal
The backend are rest webservices in java while the front end is angular js.
The rest service in java does many tasks when an order is placed /updated
store/update order and items in the order in the db
Notify 3rd party logistics regd this order
send email notification to the customer
send sms notification to the customer
etc
We already have an async queue implemented for another feature using blocking queue.
1. use the same queue(current size is 200 and is in memory) and post to it
2. create a new queue inside the rest webservice application
3. integrate with 3rd party queues.
Can someone give insights on #3? or is it wise to go for #1 or #2?
Order management of e-commerce portal is not a simple problem. It will most likely have scalability requirements and using simple Blocking Queue for async processing will not be a good idea.
JVM based Blocking Queue is in-memory queue and requires producers and consumers to be running in same JVM process.
For sending emails whenver a customer places a new order, you need to ensure that email was really sent and application restarts does not result in loss of data present in Blocking Queue.
Hence, most likely you should use an out-of-process Queue systems such as Apache Kafka or Apache ActiveMQ or equivalent.
I have a two restful webservices:
getMarketData
stopMarketData
getMarketData pulls the data from external service. stopMarketData will stop the pulling process of data being fetched from external service.
Now the problem is, when I fire getMarketData it creates a connection with the external service and start fetching the data (its continuous process as it continuously fetches the data until we call stopMarketData).
After that if I make a call to stopMarketData webservice it doesn't stop the fetching data process as the connection is not in the context of getMarketData so how can i persist the connection between getMarketData and stopMarketData calls in restful webservice.
I don't think you're supposed to maintain state in RESTful services. How would you scale this solution out to run on multiple machines or even multiple processes?
If you really do want to do this, you will have to somehow place the connection in a global area (such as in the Application object if you're doing JSP or ASP) that is available from multiple requests. Then, the stopMarketData call could get the connection from that global area and close it. This approach is definitely not very scalable.
Another option would be to use an asynchronous technology like Message Driven EJBs. startMarketData and stopMarketData calls would simply post messages to these EJBs to start and stop, respectively.
Hope this helps.
Nate
I have a Java SOAP data service which sits on top of a Sybase database which, for reasons out of my control, has unreliable performance. The database is part of a vendor package which has been modified by an internal team and most of the issues are caused by slow response times at certain times of the day.
The SOAP service provides data to a calculation grid and when I request data, I need the response time to be both fast and consistent. The service provides basic CRUD functionality, but the ratio of reads to writes is approximately 100:1.
What is the best strategy to isolate myself from the database's unreliable performance and ensure that the SOAP service is fast and reliable?
I have seen this issue a few times, normally with a vendor database.
If this is on Windows, you could create a Windows service as an intermediary between the SOAP service and the database. Then put a message queue (either MSMQ or a JMS implementation such as MQ Series) between the SOAP service and Windows service for asynchronous communications. In this way the database performance issues will no longer affect the SOAP service. This solution does, however, come at the cost of increased complexity.
Note that a .NET web service can be called by, and respond asynchronously to, its clients. I'm not sure if that's possible with a Java SOAP service.
If this is on some flavour of Unix, I assume it has similar functionality to a Windows service - maybe a daemon.
Why not use a thread? That way, the application could gently wait even if the database is slow.
RoadWarrior's response is right on. Requests to do any operation get put in a queue. The user comes in once to make the request, and once to pick up the request. This is in fact what is happening on sites like Expedia where it is talking to an unreliable service (the backend). The user's browser is pinging the server until the red light turns green.
How about caching the responses from the web service (either on the client invoking the WS request, or by setting up a proxy web service in between)?
You could cache the results from the DB if the DB Is not too big.
Get the other internal team to tune that database, so everyone using the app benefits. I do love me some indexes!