I've got a Grails app (version 2.2.4) with a controller method that "logs" all requests to an external web service (JSON over HTTP - one way message, response is not needed). I want to decouple the controller method from calling the web service directly/synchronously and provide a simple "queue" which can store the calls if the web service is unavailable and then send them through once the service is back up again.
This sounds like a good fit for some sort of JMS solution but I've not got any experience with using JMS (so learning curve could be an issue). Should I be using one of the available messaging plugins or is that overkill for my simple requirements? I don't want a separate messaging app, it has to be embedded in my webapp and I'd prefer something small and simple vs more complicated and robust (so advice on which plugin would be welcome).
The alternative is to implement an async service myself and queue the "messages" in the database (reading them via a Quartz job) or with something like java.util.concurrent.ConcurrentLinkedQueue?
EDIT: Another approach could be to use log4j with a custom appender set up as a AsyncAppender.
The alternative is to implement an async service myself and queue the "messages" in the database (reading them via a Quartz job)
I went ahead and tried this approach. It was very straight forward and was only a "screen" length of code in the end. I tested it with a failing web service end point as well as an app restart (crash) and it handled both. I used a single service class to both persist the messages (Grails domain class) and to flush the queue (triggered by Quartz scheduler) which reads the DB and fires off the web service calls, removing the DB entity when web service returns 200 status code.
Related
I have a question on how can we integrate kafka producer with a front end web app. get the data for every minute or second . Can the web app pass the JSON object to a running producer each time the it is created ? or do we need to initiate the kafka client each time we get a JSON object ?
You would want to probably open a new Producer for every session, probably not open and close for each and every request. And this would be done on the backend, not the frontend.
But a web server consisting of a Kafka client is no different underneath the HTTP layer vs a regular console app; you accept an incoming request, deserialize it, then optionally parse, then serialize again for Kafka output, then optionally render something back to the user.
If you're really asking, "is Kafka with HTTP requests possible", regardless of the language and platforms, then sure, the Confluent REST Proxy operates similarly, only written in Java
As far as webapps tracking goes, I would suggest looking into Divolte Collector
I am trying to use an UWP app service to provide some non-UI processing service to other app including the host app. For responsiveness, I want to return the result progressively. Think about grep-ping a folder for files containing a certain string: It would be better to report the files as we found it instead of reporting everything at the end.
So my question is: Can this scenario be achieved with the current UWP technology? (I think it is probably possible via polling using the multiple app instances approach. I want to know if there's an easier method with app service.)
The AppServiceConnection is a bi-directional communication pipe, so you can use it to communicate progress updates from the service to the client. No need for polling. Just retain a reference to the AppServiceConnection instance in your service implementation once the client has connected and then call SendMessageAsync to send progress updates to client whenever you want.
Background:
I've a local application that process the user input for 3 second (approximately) and then return an answer (output) to the user.
(I don't want to go into details about my application in purpose of not complicate the question and keep it a pure architectural question)
My Goal:
I want to make my application a service in the cloud and expose API
(for the upcoming website and for clients that will connect the service without install the software locally)
Possible Solutions:
Deploy WCF on the cloud and use my application there, so clients can invoke the service and use my application on the cloud. (RPC style)
Use a Web-API that will insert the request into queue and then a worker role will dequeue requests and post the results to a DB, so the client will send one request for creating a request in the queue, and another request for getting the result (which the Web-API will get from the DB).
The Problems:
If I go with the WCF solution (#1) I cant handle great loads of requests, maybe 10-20 simultaneously.
If I go with the WebAPI-Queue-WorkerRole solution (#2) sometimes the client will need to request the results multiple times its can be a problem.
If I go with the WebAPI-Queue-WorkerRole solution (#2) the process isn't sync, the client will not get the result once the process of his request is done, he need to request the result.
Questions:
In the WebAPI-Queue-WorkerRole solution (#2), can I somehow alert the client once his request has processed and done ? so I can save the client multiple request (for the result).
Asking multiple times for the result isn't old stuff ? I remmemeber that 10 - 15 years ago its was accepted but now ? I know that VirusTotal API use this kind of design.
There is a better solution ? one that will handle great loads and will be sync or async (returning result to the client once it done) ?
Thank you.
If you're using Azure, why not simply fire up more servers and use load balancing to handle more load? In that way, as your load increases, you have more servers to handle the requests.
Microsoft recently made available the Azure Service Fabric, which gives you a lot of control over spinning up and shutting down these services.
We have a system using EJB 3 Stateless bean which is also exposed as web service.
There's a integration request from other team that want our system to fire a notification to other system after invocation (by web services or other means). Since this is not totally related to our system I would prefer to have this feature loosely coupled with our own system instead of hard coding these features in to our system code.
Is there any feature on EJB or web services that can achieve what I desire? We would require a method level invocation listener so that when the EJB method/ web service get invoked, it can trigger a callback/message so we can do something according to it. I would expect it to be some kind of annotation/configuration for setting up JMS or something.
We are using JBoss as the application server. If there's any JBoss specific solution it's also welcomed.
I would suggest two options:
use JMS. When you mentioned loose coupling, JMS first crossed my mind - you can put a message on some queue/topic after method invocation and let the listener to perform futher actions. JMS messages can carry various kinds of objects - the only request is that class implements Serializable (ObjectMessage#setObject); other advantage is that you can (un)deploy your Stateless bean and other system independently. They can be on different JVMs.
use Interceptors. Technically, they would be invoked before your methods runs, but of course there is always some nice workaround :-) Here is the official documentation about Interceptors, but since you mentioned that you're using JBoss, there can be also found some interesting material on JBoss pages.
What would be a more standard way of notifying a web service consumer of a data change?
Having the consumer periodically calling the web service to pull change notification.
Consumer setting up a call back web service that can be invoked to forward notification about the change.
Other?
Both of these are options. There is also something called "comet" which is like setting up a stream between between the consumer and producer - messages can then be passed back and forth between the two. Wikipedia is probably the best place to start investigating to see if it will work for you project: http://en.wikipedia.org/wiki/Comet_(programming)
Depends on the scenario. If you're working in a closed environment with only a few consumers of your service, you could switch to a COMET style service which allows a callback from the service to the client. More about that here:
Wikipedia - COMET
From what I've read, that method doesn't scale well in larger environments so I'd be careful.
The more traditional method is your first option of polling the service for changes. As long as your service performs well and you have the appropriate hardware to serve up the requests, it's probably your best bet for a public facing web service.
In case you weren't aware of it, and in case it helps: WCF can work with a Duplex contract that in effect creates a callback service contract on the client. It's fairly transparent.