I need to write an API, when client invoke that API it publish message on request topic of MQTT and wait for response on response topic. If response topic doesn't return anything then API should return default response.
My problem is while consuming message from topic. I am able to publish but how I can wait for response (to consuming message) for a specific topic and send it as response or after specific time send default response of API.
I am using Spring 4, Java.
You can implement steps:
Your HTTP server receive a request and publish a request message with an unique correlation-id to MQTT, and create event loop E to wait message response
Consumer C1 consume the message and handle, then response (publish) a message with the same correlation-id to MQTT
Consumer C2 in your HTTP server consume the response message and give it to event loop E
Event loop E break a loop and return message response to HTTP client
Related
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.
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
I'm implementing a http client app with Netty. The task is to send the same request to several endpoints and collect the answers for further processing. Many such requests can be sent concurrently to the same endpoints. The problem is to match responses received from one endpoint to requests.
One possible solution is to create a new handler (and pipeline) for each request as describe here https://stackoverflow.com/a/7905761/4926576. In this case request can be mapped to handler and handler can store the response. But this means creating new connection for each request which will degrade the performance.
I also don't want to change the protocol and include request ids in requests/responses only for the purpose of matching.
If both the client and server are respecting HTTP pipelining semantics, then the server must respond to requests in order. Therefore, for each connection, you can maintain a queue of requests. Each new request goes on the back of the queue and each response pops it's matching request from the front of the queue.
In the event of connection failure the queue also provides you with the list of requests that were sent but for which you have not received a response. You can then take appropriate error correcting action for each request.
I'm reading the OSCWCD books by Charles Lyon on section about asynchoronous request. It says that in a asynchronous cycle, one can dispatch even when a response has been committed. I don't understand why so? Any insight would be great!
The general approach for asynchronous approach is that client will open a new channel to receive the asynchronous response and will provide the handle of that channel to the server. The asynchronous response is not sent on the intial client request/response channel, rather it is sent on a different channel, which remains active till the client does not receive the asynchronous response.
If client is not able to provide any channel for the server to send the asynchronous response, then another approach is to use the polling. In this case, server as part of the intial request response, will provide a polling URL. The client can poll it periodicall, and when server has the response ready, will return the response. When server does not have a response, it should return a meaningful in-progress message.
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.