I've looked by I couldn't find out what happens to conversations when one side has an issue and how to handle it. I think I've seen a few times when there was an error in the TargetService and it caused another error to occur.
I have a stored procedure which begins a conversation and sends a RequestMessage to a TargetQueue associated with a TargetService and a contract. It then waits for up to 5 seconds to receive a message with that conversation handle on the InitiatorQueue.
Meantime an application on another server is waiting in a loop to receive messages on the TargetQueue, process them calling yet another system, and sending a ResponseMessage to the InitiatorQueue.
Timeout
Since the stored procedure should be responsive it waits at most 5 seconds because a user is waiting for a response. If the application takes longer than 5 seconds to send a response, it goes ahead and ends the conversation. When the application finally succeeds it will send the response to the InitiatorQueue and end it's side of the conversation.
So what happens to that ResponseMessage in the InitiatorQueue? Does it have to be cleaned up somehow? Since the requestor only ever listens for a response with the same conversation handle, it will never be received. Will it be deleted when the 60 second lifetime I have specified for the dialog expires?
Error
So what if the application has a critical error and crashes (or the server goes down) while there is a message in the TargetQueue? The initiator will close their side of the conversation, and the 60 second lifetime for the dialog will elapse. Will everything be cleaned up?
What if the message has been received from the TargetQueue and the error occurs before a response is sent. Will that dialog remain out there?
Just doing some testing, there doesn't seem to be a way to tell when I receive a message on TargetQueue if the dialog has been closed by the sender yet. This leads to the application processing the RequestMessage and erroring out on the SEND to the InitiatorQueue. Could/Should I attempt a receive on TargetQueue and close the dialog a second time in the stored procedure to clear the queue before I return a timeout error?
Related
Good afternoon,
I have a production service broker queue which stopped processing messages about a month ago. After clearing out the messages that had backed up there remains 8 messages that will not leave the queue. I assume it is these messages that are blocking me from disabling or deleting the queue which would hopefully allow the whole system to start up again.
If I select from the queue I see the 8 messages and they all have a message_type_name of "http://schemas.microsoft.com/SQL/ServiceBroker/EndDialog".
If I match these messages up with sys.conversation_endpoints I get a state_desc of "DISCONNECTED_INBOUND"
Using ssbdiagnose on a specific conversation handle I receive the following error:
Service broker received an END CONVERSATION message on this conversation. Service Broker will not transmit the message; it will be held until the application ends the conversation.
If I try to end the conversation using:
END CONVERSATION ... WITH CLEANUP;
The query just spins, (currently over 20 min).
I get the impression that my next course of action is the following command:
ALTER DATABASE ... SET NEW_BROKER WITH ROLLBACK IMMEDIATE;
Not a fan of this after reading some of the fallout but if that is the only option then we'll have to deal with it.
So, thoughts on next steps / any other option than the new broker? If additional information is necessary just let me know.
Thanks!
My Google-fu has failed me, Stack Overflow Gods...
I have a very basic bot running on 4 of my servers that handles scheduling and, as long as the bot is online, it works marvelously, but as soon as it goes offline for whatever reason, it stops listening to any of the messages already in the channel and will only listen to newly sent messages.
E.G. Let's say that every time the bot is online is starts a new session and when it goes offline, that session ends. So, if my bot is online for the first time, it's in Session 1 and listens to all messages sent during Session 1, but as soon as it goes offline, Session 1 ends. When it comes back online, it starts Session 2 and stops listening to messages that were sent during Session 1 and only listens to messages that are sent during Session 2.
How can I get the bot to listen to all the messages in one channel? (How can I get it to listen to all messages from all "Sessions")
Thank you kindly
What happens when an Azure Logic App is disabled?
Does the current "run" finish, or is it terminated at whatever action is currently on?
In our case, we have a logic app that has a trigger on a message being added to a Service Bus queue ... the Logic App is doing a Peek/Lock read of the message
Various actions, including a SQL Db write, and finishing with a Service Bus complete on the message
If the current run finishes, then we don't have to worry, as that particular message has been "processed"
But if the current run is terminated wherever it is, Service Bus will return the message to the queue after the timeout, and then when the Logic App is re-enabled, we'd re-process the original message from the Service Bus queue
Current in flight runs will finish, but the trigger will stop checking for new events and invoking new runs. You can cancel runs to stop ones that are in progress, but currently is a separate gesture to just disable.
I am implementing an Apple notification push service and am processing an internal queue.
I would like to know if PushSharp notifications always raise the "NotificationSent" or "NotificationFailed" events (one or the other - at least one of them).
Also if the notification does successfully send, doe the NotificationSent event always fire for each successful notification sent or can there be circumstances where this does not occur even though it sent successfully?
I've been working with PushSharp (latest lib v2.0.4) and all my messages have either triggered NotificationFailed() or NotificationSent(). But this is no guarantee that the messages will reach the end user (device). Apple or Google are sending an ACK that their servers have received the notification successfully (or not) from my push service. Then it's in their hands to send on to the final device.
Furthermore, how are you closing your push services? If you call StopAllServices(true), the service will wait for all ACKS to be received before shutting down. If called as StopAllServices(false) then it shuts down not waiting for acks and therefore the events NotificationFailed() or NotificationSent() will not be triggered.
Hope this helps.
I’m stuck at one particular requirement in camel , I’m processing a set of files and when any exception occurs i send a message to an exception queue , and from the exception queue im sending an email about the failure , the functionality is working fine but I end up sending many mails, like if 10 files fail im sending 10 emails, is there a way to send only one mail , like I would want to wait for the entire route to finish , then go look the exception queue and send a single mail stating what has failed (by processing the exception queue )
I'm open for suggestions.
I had to do this scenario once (inversed though - mail on success). I had a handy MySQL database configured and ready, so I just added each event from the queue to the database. Then once every now and then, extracted all info (and deleted it)- simply select * from events; delete from events; from the database and created a mail.
You could process the error queue with the aggregator pattern, it is very nice for these tasks. http://camel.apache.org/aggregate-example.html . You still need to know WHEN the aggregator should fire off a message. If you can, trigger a "finish, send mail" event such as in the example in the link above.
The most simple way would be to time schedule these mail notifications. Take a look at: http://camel.apache.org/simplescheduledroutepolicy.html . You can set it to run your route for some good choice of time, then when it fires off, you set the aggreator to complete upon timeout, and make the timeout good enough to empty any reasonable queue size of errors, but not too large.
At least that's my suggestions to your issue