I have question about http request and rabbit mq .
How I can have this sample
1- client request to server with http request
2- severe after receive request put to rabbit mq
3- in one job , lisiner read message after process on time response to client with http response
Is it possible ? If yes please help me
it's possible to save your httpRequest in rabbitMq and it's possible to read them in a job from rabbit.
but it's not possible to send back HttpResponse to a request which you have red from rabbit !!!!
it's because of :
http basically is an online protocol which means that client wait until you respond back to client and if you don't send back the response online it will get an error.
but let me help you with what are you looking for :
what you are looking for is an event base system . in such a system everything is status base.
in an event base system you get the request from client . then you persist the request somewhere with requested status and respond back to client and tell him your request persisted successfully ( but not processed ).
then in a job or other ways you fetch requests with requested status , then start to process them.
after processing them , you persist them again somewhere with processed status or ErrorWhileProcessing status .
then clients can send request to observe the status of their requests.
for example the client ask for transferring some money . then you just persist the request somewhere with requested status and respond back to client that your transfer request is persisted successfully ( but not processed yet ).
after a while , by using a job or a listener on your rabbit , you fetch the requested transfers (transfers with requested status ) and start to process them. after processing if the transfer where successfully done , persist that again with successfully processed status and if encounter some error , persist it with error status ( with reason ) .
then whenever client want, can send request to observe the status of his transfer request.
Related
I have a Spring Boot application that is pushing JSON messages to a queue, and in the other place it is consuming those JSON messages using #JmsListener. Those messages are then send via HTTP Post request. The response code might be 200 and that's OK, but I would like to handle situations when client is down or just simply response code is different than 200.
Is there any mechanism that I could use for retrying the messages? Maybe I could push back the message at the end of the queue and retry them for lets say 3 times? Is there any internal ActiveMQ mechanism for doing that after message was actually dequeued?
Sounds like you are looking for a transaction between the consumer and HTTP Post. JMS won't acknowledge the message off the queue until your code calls session.commit(). You can then call up to one HTTP endpoint and maintain reasonable transaction and single message delivery quality of service.
The key to making this self-healing is to detect invalid message payloads (ie bad JSON format or bad data) and move those messages into a DLQ.
Look into adding JMS local transaction support instead of using AUTO_ACKNOWLEDGE
connection.createSession(true, Session.SESSION_TRANSACTED);
Then in your psuedo-code:
Message message = session.receive ..
.. do valid message checks
.. call HTTP endpoint..
// now take action based on HTTP return code
switch(httpReturnCode)
case 200:
session.commit();
case .. invalid message returned from HTTP:
.. produce message to DLQ for inspection
session.commit();
case .. http not available..:
.. do some time delay, retry to http endpoint
Third party integration, browser redirection function is triggering multiple request (only IE), 2 requests within 2 nano sec difference. I am using request attribute to deduct duplicate request and processing correct request(first request), duplicate request is sending error message. Unexpectedly, the browser is getting an error on the first request and stops further process(redirect to another component due to error).
Because error response is sending immediately, correct request is taking few nano seconds for processing the business logic.
How can I stop the duplicate request? Can I put Thread.sleep(20 sec) in error request , so duplicate request will be redirected after 20 sec by that time correct request will be processed and redirected to browser.
Is this advisable?
If I understand your question correctly, your problem is : have 2 requests and they send them together to your web application, but 1 of requests got error message.
If it's correct. The solution will be depend on the expected of the client, what's kink of response they expect on this case. We have 2 ways to go :
Return the error message when 1 message have problem to the client
Ignore error request, and send the response for the second request.
In my point of view , don't use this one :
Thread.sleep(20 sec)
What's happen if your request take more than 20 sec to process.
Hope it helps.
I am using Java servlets using Apache tomcat.
I've configured a threadpool and am dealing with each request.
My page is taking in many GET requests at the same time, I'm wondering if I can respond to the server after each get request before any of the logic happens?
So server gives me a request -> I respond with either 'good send another' or 'bad send another' before I start my queueing.
Any help would be much appreciated!
EDIT
Sorry that was terribly written :(
What I'm asking for is a way to send a Header to the client (in this case it's a server which sends me lots of requests). The response would just be 200 or error based on the information I get sent.
What my program is doing:
My servlet gets sent lots of GET requests from one client. (over 100,000) Which I am using tomcat to queue and put into a threadpool. It is then assigned to a worker thread which processes it and puts it into a database.
I've been told to do is send a request back to that server saying 'ok received it'. I think I can use a header response but I don't have the URL of that client (and the client can change for different campaigns). So was wondering what the best way would be to send that response.
After doing some more research I think what I'm looking for is ServletOutputStream.
response.setContentType("text/html");
ServletOutputStream output = response.getOutputStream();
output.flush();
output.close();
Using servlet output stream where do I set the <head><body> tag? and insert the header response afterwards.
The simple answer is "sure".
If these are get requests from a web page for a web page, include a refresh timer and send back some token that can be used to identify the difference between a first-time-request and an I-requested-earlier-are-you-done request. In this case the refresh timer can be set via a meta refresh tag.
If the get requests are part of a REST API then you can define "got it and I'm working" into the protocol. For instance, return a 202 to indicate "got it but not done" and return 200 to indicate "done". As with the html page, consider sending some token back with the 202 that identifies the pending request.
I am using the Twilio java wrapper provided on the website and started making some tests. I am able to send text messages that are successfully received. However, I would like to make sure that the messages have been sent successfully and that no problem has been encountered by Twilio (bad phone number or whatever reason).
I understand that when you make a REST request to Twilio to send a SMS, Twilio responds with the Status. How could I get this response?
Here is the explanation page I found: http://www.twilio.com/docs/howto/sms-notifications-and-alerts
If you specify a StatusCallback URL when you make the request to send an SMS, we will make a request to the callback URL you provided after the message has finished processing, with the parameters either SmsStatus=sent or SmsStatus=failed. You can use this information to do more processing on the SMS message. There's more information here: http://www.twilio.com/docs/api/rest/sending-sms#post-parameters-optional
Alternately, if you hang on to the SMS Message Sid, you should be able to query the API for the message and get the status in the response. So if the sid is SM123, making a GET request to https://api.twilio.com/2010-04-01/Accounts/AC123/SMS/Messages/SM123.json should return a object with the status of the SMS Message.
I recall that the response comes to your url and can be matched up by an ID. In the REST post to SMSMessages you can specify a statuscallback url where Twilio will post a status message to your url.
When you receive that post to your site, you can record it or take any other action you need, such as retrying or using another mode of communication.
In 2020, with the Java SDK, you can now create a MessageFetcher with that SID and then call fetch to ask for the Message instance until its getStatus returns "delivered", "undelivered", or "failed".
Is it possible to make GET & POST requests in Java or another language such that you don't care about what is returned?
As in just sending the requests but not wanting to receive any responses?
Whether you care about the response or not, it will be sent. The HTTP protocol specifications say that it must be.
If you don't care about the response, your client could just close the connection immediately after sending the request. But the chances are that you do want to know that the request was processed (i.e. the response status) even if you don't want to look at the contents of the response message.
So maybe you could send the request and request body, and read the response status and then close the connection without reading the response body. However, this has a downside. It means that you can't reuse the HTTP connection to make further requests. The next request to the same server has to open a new connection.
You could use anynchronous HTTP requests if you don't care about the responses (that way your worker thread will not have to wait for the response to come back). See http://www.javaworld.com/javaworld/jw-03-2008/jw-03-asynchhttp.html for some details on Asynchronous/Synchronous HTTP queries in Java. Then you can control if the anychronous thread does or does not handle the response (or any failure flagged on the communication) - as long as there were no TCP level failures on the request the connection will still be opened.
You can't control whether or not the server returns a response. Your code is free to ignore any response it receives.
It's pretty hard to not get responses because they're part of the HTTP protocol. but you can certainly ignore the responses.