i'm new to web development, so bear with. I just came across Celery, an asynchronous task queue. After reading the documentation, what i get that celery is adding a delay to a code and then run its process in background. I don't really get it, i thought it's just like a normal AJAX, if yes, what's the advantage using this so-called asynchronous task queue, if not, what's the difference between a normal ajax call and async task queue. Would be good if you guys give me some real world example. Thanks.
Related
What is the meaning of Synchronous and Asynchronous in general?
What are the use of Synchronous and Asynchronous communication in microservice? When to use synchronous and when to use Asynchronous.
Please explain with example thanks in advance.
Under synchronous, the communication between components is live all the time. An example would be a service making a GET/ POST call and waiting for the response to proceed to the immediate next step.
Asynchronous meaning one component does not wait for the other components to react. An example would be a service publishing message to a Kafka topic. The service which creates the event does not know when the clients will consume it.
I would start thinking about the application end-user use case to decide when I should use what.
can any one explain. when to use Synchronous and Asynchronous request with example.enter code here
Generally speaking, asynchronous requests do not block the running environment until they get a response. This keeps your UI responsive while waiting for the response, and enables your user to use it. With synchronous requests, the UI would feel like it would be frozen.
I would say that while developing a web application, you would probably use asynchronous requests 99.9% of time.
From a software engineering stand of point, synchronous code is using one process, while asynchronous code executes a concurrent process. That is exactly how your UI is enabled to be responsive. It's like as if the asynchronous code ran as another program, if you will.
I've joined a project that uses Jax-RS (and originally there was quite a bit of Spring-based Controller code in there too, but all URL handlers use Jax-RS now). Now we want to be able to fill in a queue of tasks that should be run with a small delay between each of them. The delay can be specified in ms. I've avoided Thread.sleep, as I've heard you should not manage threads manually in Java EE. Before I came in there was already a busy wait loop implemented.
I would like to switch this to an asynchronous background task. I could of course let the client poll the server with the given delay, and just have an AsyncResponse that can be resumed. But can the same AsyncResponse be resumed/suspended multiple times? The resource does have state, so it would be possible to drop the asynchrony completely and just do client polling to handle all of it.
A lot of example code for showing off asynchronous tasks use Thread.sleep. How bad is it to do this in a background task on an ExecutorService or something similar?
The point of the delay is to simulate human interaction, and post a long list of JMS messages to a queue but ensure that two listeners don't pick up and handle messages that depend on one another.
Is it easier/better to handle this on the client side rather than the server side? Writing some JavaScript that handles all the polling would be quite simple, so if this seems like a bad idea for handling on the server side, it's not that big a deal.
The tool is only going to be used by a single user, as it's a developer testing tool. Therefore we went for solving this on the client side, pushing the messages onto the queue through AJAX calls. This works fine for our purposes, but if anyone has a solution that might help someone else. Feel free to drop a new answer.
I'm building a simple task manager that will at this moment execute tasks in a serial manner. I have been reading about threads in flex and it seems it is not quite clear/prepared for real threads.
What I'm looking at this moment is a way to execute a method at the beginning or end of a flash builder update. This method will be the one that will take the responsibility to start tasks added in the previous update. The removing of finished tasks will be done through event notification (the task will notify it finished) then the scheduler will remove it and dispatch the message again to let the outside world know the task was over.
A rough workflow of the system woudl be:
1) Add Tasks to the scheduler. And listen to events of the task (finished, etc...)
2) At the beginning/ End of a flex update (don't know if this really happen) Start tasks waiting. And run tasks that have a runnable method per update.
3) When a task finishes it notifies the scheduler and it is removed from the scheduler queue and redispatches the event to let the outside world the task finsihed.
Could anybody suggest the correct place to have a method like this? Any suggestion to the scheduler?.
Thanks in advance,
Aaron.
Based on your description you don't seem to be doing anything new and that unique. I'd start first with researching existing task and concurrency solutions. If they won't do what you want, extending the code will probably still be easier than starting from scratch.
Get familiar first with Cairngorm 3 Tasks and/or Parsley Tasks.
Also take a look at the callLater() method.
Finally there is the GreenThreads project.
I'm setting up a web service in Axis2 whose job it will be to take a bunch of XML and put it on to a queue to be processed later. I understand its possible to set up a client to invoke a synchronous web service asynchronously by creating a using an "invokeNonBlocking" operation on the "Call" instance. (ref http://onjava.com/pub/a/onjava/2005/07/27/axis2.html?page=4)
So, my question is, is there any advantage to using an asynchronous web service in this case? It seems redundant because 1) the client isn't blocked and 2) the service has to accept and write the xml to queue regardless if it's synchronous or asynchronous
In my opinion, asynchronous is the appropriate way to go. A couple of things to consider:
Do you have multiple clients accessing this service at any given moment?
How often is this process occurring?
It does take a little more effort to implement the async methods. But I guarantee, in the end you will be much happier with the result. For one, you don't have to manage threading. Your primary concern might just be the volatility of the data in the que (i.e. race/deadlock conditions).
A "sync call" seems appropriate, I agree.
If the request from the client isn't time consuming, then I don't see the advantage either in making the call asynchronous. From what I understand of the situation in question here, the web-service will perform its "processing" against the request some time in the future.
If, on the contrary, the request had required a time consuming process, then an async call would haven been appropriate.
After ruminating some more about it, I'm thinking that the service should be asynchronous. The reason is that it would put the task of writing the data to the queue into a separate thread, thus lessening the chances of a timeout. It makes the process more complicated, but if I can avoid a timeout, then it's got to be done.