I think I described almost everything I need in title. So there is some WMB flows. And one wait for the answer in queue. I need to throw exception if there will be no message in queue after timeout.
Thank you for your time
Yes it is possibe, but you will need to develop it in your flows. MQ is made for asyncronous communication, so a timeout is not something which is native to it. I can think of 2 possible solutions now:
Use the TimeoutControl and TimeoutNotification nodes in your flows
In the flow which sends the request, after sending the request you add a TimeoutControl node and set up the desired timeout.
Create a new flow, which starts with the TimeoutNotification flow. In that flow you send your timeout error if the response has not yet been received.
And to know which response has been received you can use different methods, for example the flows sending the request and receiving the response could maintain a database table, or you could store this information in a queue as well.
Start waiting for the response after sending the request
Set up the response handler flow to start with an MQ Input followed by an MQ Get node. You listen for the response with the MQ Get, on which you can set a wait interval, that will be your timeout threshold. The MQ Input gets technical messages sent by the request sender flow after sending the request.
This is a worse solution then the first, as you will block a message flow thread while listening for the response.
Or you can just make 1 flow to send the request and receive the response, receiving the response with an MQ Get node.
This is even worse as you will need to turn off transactionality for the MQ Output sending the request.
Related
How does Photon handle a player leaving a room immediately after issuing a RPC? Does the RPC reach the targeted players?
RPCs are sent reliably independent from the transport protocol used.
RPCs are RaiseEvent operation calls under the hood.
The client sends RaiseEvent operation request to the relay server (Game Server) then the relay server will send a custom event to the target active actors if any.
Since this operation request is sent reliably, the client can retry sending it if no ack is received from the server after some time. However, if the client leaves the room, it will switch servers (disconnect from the Game Server and connects to the Master Server). So the retry attempts may be skipped in this case.
If the RaiseEvent operation request successfully reaches the server then the RPC reaching the target will be the responsibility of the server only.
The reference for this method only says what happens locally on the client, and says nothing about what it potentially sends to the server. Apparently, our server has some challenges with receiving a lot of status code 499 from us when we cancel a request, but I can't find anything about how URLSession handles cancellation. Is there a standard cancel-message over the protocol HTTP?
The client doesn’t send 499. Status codes are one-way. Rather, the client closes the network connection. The server records that dropped connection as a 499 status code in its logs.
If the server is HTTP/2 or later, the client may send either a END_STREAM or RST_STREAM message to cancel a single request without canceling other requests on the same connection, or it may just drop the connection. Either way, you’ll probably just see a 499 in your logs. There is little reason to care whether the connection was dropped or cancelled.
Here is our scenario:
We are publishing messages to a topic, and have a queue subscribed to that topic. We have several node.js consumers connected to that queue to process incoming messages, via the solclient package.
What we want to do is process the incoming messages, and after successfully processing the message, acknowledge the message so that it is removed from the queue. The challenge we're having is how to deal with error conditions. We are trying to figure out how to flag to the broker that the message failed to be processed? The expectation would be that the broker would then attempt to send to a consumer again, and once max redeliveries is hit, it moves to the DMQ.
I don't believe there's a way in Solace for a consumer to "NACK" a received message to signal an error in processing. I believe your option would be to unbind from the queue (i.e. disconnect() the Flow object, or MessageConsumer in the Node.js API) which will place allow any unacknowledged messages back on the queue and available for redelivery, and then rebind to the queue.
Alternatively, if you do your processing in the message received callback method, you could throw an exception in there, and that should (?) accomplish the same thing. But probably a lot less graceful.
https://docs.solace.com/Solace-PubSub-Messaging-APIs/Developer-Guide/Creating-Flows.htm
https://docs.solace.com/API-Developer-Online-Ref-Documentation/js/solace.MessageConsumer.html#disconnect
I'm developing a messaging system in Delphi. I'm using idTcpServer in my Server Application and idTcpClient in my client application. the client application pings the server every 10 seconds to see if the connection is active and tell the server to set the status of the user to Online. and also the user may send messages to his contacts. all these requests are followed by a response from server which i get by socket.readln command right after i send the request. for example for pinging the server:
TcpClient.socket.writeln('i am online');
if TcpClient.socket.readln = 'ok' then
begin
{commands}
end;
I also check for new messages using Long Polling. I send 'check for new messages ' + timestamp from tcpClient and then on the server, I check the database for new messages newer than the timestamp i recieved in a While loop so when there is a new message the loop breaks and notification is sent to the client.
But this system doesn't work for me. Sometimes I get the responses intended to be for checking for new messages when the client application is pinging the server.
I have developed the same system in php without a problem. but here there must be a problem.
I think it is not asynchronous. what should I do?
Regarding the check for new messages request, the server should not be looping waiting for new messages to arrive. Either there are new messages available at the time of the request or there are not. Get the request, do the query, report the result, and move on. The client can send a new check for new messages request periodically. Alternatively, have the client tell the server one time that it wants new messages, and then the server can actively push new messages to the client in real-time as they arrive on the server, instead of polling for them (similar to IMAP's IDLE command).
I would suggest you redesign your communication protocol to run asynchronously. Most modern IM services are asynchronous. When the client sends a request, do not expect a reply right away. Just let the client move on to other things. Have it run a separate timer/thread that reads all inbound data. When a reply does arrive, the client can act on it. If needed, include an identifier in the request that gets echoed in the reply so the client can keep track of the requests it sends. This also allows the server to use asynchronous processing on its end, so if a request takes a long time to run, the server can push it off to another thread/process and continue processing other requests in the meantime. Send the final reply when it is ready.
I want to develop a ussd application that waits for user input (PROMPT). I was wondering how to handle a case, when for example ussd message is sent at night and user replies after several hours. For sure any timeout cannot handle it. On my phone (sony xperia) the message with the question is still displayed and i can reply seeing no error. But server side, I do not receive this reply because ussd session expired.
Resending the message several times is not a solution.
You cannot do it!
You want to develop an application(server side) that accept input from mobile handset(client side)
I didn't understand well if your application is:
Mobile-initiated (USSD/ PULL)
Network-initiated (USSD/ PUSH)
but however in both cases you cannot achieve your goal.
Because session timeout is server side and there is nothing client could do about it, beside to resend the request which is not an option in your case.