As part of the conformance test performed by our FIX provider on the connector application we have developed should automatically re-connect and re-subscribe to the quote session, after experiencing an abrupt disconnection across all sessions.
Since we use QuickfixJ, the client app automatically reconnects and re-login successfully when any disruption happens to the Quote session and by default resets the Sequence numbers to start from 1. But, after re-login, our app is not receiving any quote messages even though the counterparty is continuously sending the subscribed Quotes prior to disruption(this what our counterparty says). We see nothing in the logs also except successful Heartbeat messages.
Do we have to send again a fresh QuoteRequest after re-login? or do we have to send a ResendRequest?
I think we can't send a ResendRequest here because the sequence numbers are already reset during logon.
If we have to send a fresh QuoteRequest, does it cause any error at the counterparty as it has not stopped sending the previously subscribed Quotes?
Could you please suggest us a solution. Thanks in Advance.
Do we have to send again a fresh QuoteRequest after re-login?
This answer is counterparty-specific. The FIX protocol does not answer this. You really need to ask your counterparty. My gut says that the answer is probably "yes", but you should confirm with them.
FIX gives a default set of application-level messages and fields, but does not describe how they must be used. Therefore, every counterparty does things a little differently.
or de we have to send a ResendRequest?
Heavens, no! ResendRequest is a transport-layer message; the QF/j engine will send this automatically when it's needed. You should not send it manually (just like you shouldn't send a Heartbeat manually).
Related
1) With a Free Gmail account were unable to get the MessageLabelsChanged event to fire. We're assuming this should occur when you take a gmail message and add or remove a label from it.
At the same time, we ARE able to get the Idle, CountChanged, MessageExpunged and MessageFlagsChanged events working..
We are calling it on the Service.Inbox object.
We found this link https://github.com/jstedfast/MailKit/issues/208 about wrong event raised. Our labels are very uniquely named, therefore we believe, they should not be confused with events?
2) What is the ImailFolder.Subscribed method do? Should this be called to solve issues #1???
Many thanks Jeffrey!
I should probably remove the LabelsChanged event from ImapFolder because GMail is not very good about sending those notifications to the client (in fact, I'm unable to get GMail's IMAP server to send them either).
I've mostly kept it for completeness in case GMail's IMAP is ever fixed to reliably send those notifications.
In our design we have something of a paradox. We have a database of projects. Each project has a status. We have a REST api to change a project from “Ready” status to “Cleanup” status. Two things must happen.
update the status in the database
send out an email to the approvers
Currently RESTful api does 1, and if that is successful, do 2.
But sometimes the email fails to send. But since (1) is already committed, it is not possible to rollback.
I don't want to send the email prior to commit, because I want to make sure the commit is successful before sending the email.
I thought about undoing step 1, but that is very hard. The status change involves adding new records to the history table, so I need to delete them. And if another person make other changes concurrently, the undo might get messed up.
So what can I do? If (2) fails, should I return “200 OK” to the client?
Seems like the best option is to return “500 Server Error” with error message that says “The project status was changed. However, sending the email to the approvers failed. Please take appropriate action.”
Perhaps I should not try to do 1 + 2 in a single operation? But that just puts the burden on the client, which is worse!
Just some random thoughts:
You can have a notification sent status flag along with a datetime of submission. When an email is successful then it flips, if not then it stays. When changes are submitted then your code iterates through ALL unsent notifications and tries to send. No idea what backend db you are suing but I believe many have the functionality to send emails as well. You could have a scheduled Job (SQL Server Agent for MSSQL) that runs hourly and tries to send if the datetime of the submission is lapsed a certain amount or starts setting off alarms if it fails as well.
If ti is that insanely important then maybe you could integrate a third party service such as sendgrid to run as a backup sending mech. That of course would be more $$ though...
Traditionally I've always separated functions like this into a backend worker process that handles this kind of administrative tasking stuff across many different applications. Some notifications get sent out every morning. Some get sent out every 15 minutes. Some are weekly summaries. If I run into a crash and burn then I light up the event log and we are (lucky/unlucky) enough to have server monitoring tools that alert us on specified application events.
I am running into an issue with NotificationHubs where occasionally notifications silently fail to get delivered to an iOS client.
My Notification Hub is setup to use token authentication with APNS (as opposed to the legacy certificate authentication).
I updated my notification hub pricing tier to standard so I could get some more information about it. Most of the time (over 95%) notifications go through correctly. I added logging to track the NotificationId of each push notification that was queued with Notification Hubs. Then, when I was alerted of a failure, I went and looked up the details for that specific notification via the following method:
var details = await notificationHub.GetNotificationOutcomeDetailsAsync("<notification id>");
Inspecting the details I noticed that while the State was "Completed" (meaning NotificationHubs had received and processed the operation) the PnsErrorDetailsUri had a non-null value, indicating there was an issue delivering the notification:
Navigating to the value of the PnsErrorDetailsUri in a browser caused the following file to be downloaded:
In here, I noticed that the NotificationSystemError says there was an "InvalidToken". This token seems like it should be related to some "under the covers" communication between Azure and APNS. It is definitely NOT due to the device token registered in NotificationHubs being invalid. I verified that the registrationId was still in notification hubs, and that it pointed to the correct device. In addition, grabbing the raw NotificationBody from the details and re-submitting it with the same tag causes the new notification to be delivered successfully.
Does anyone know what the InvalidToken may be referring to, or what could be the cause of these intermittent NotificationHub delivery failures?
UPDATE:
I have found mention of the different NotificationSystemErrors here, one of them being my InvalidToken error. However, I can't find a description of what the actual causes of these errors are.
I never really got a definitive answer why the error was happening, but I appear to have been able to resolve my issue.
We have 2 separate notification namespace/hub, one for apple production notifications and one for the apple sandbox notifications. We have a switch in place so devices register with the correct hub. I investigated all of our registrations, and they all looked to be in the correct location.
However, during this inspection I noticed that many devices had a large number of registrations. Each of these registrations had the SAME apple PNS identifier (which was a valid token), but it seemed odd to me that there were dozens (in one case hundreds) of the same PNS token registered. Each RegistrationID was the same, except it has a hyphenated incremented number after it (for instance, 1231231231235396312-6910179870480973035-1, 1231231231235396312-6910179870480973035-2, 1231231231235396312-6910179870480973035-3, etc.). It looks like each time I call NotificationHubClient.CreateAppleNativeRegistrationAsync, it is adding a new entry without de-duping. Clearing out these duplicate items seems to have resolved the issue I was encountering. Seems like NotificationHubs was getting confused sometimes with too many registrations being linked to a device.
I ended up adding some code on my end to attempt to filter out duplicates for the time being. However, I would expect that NotificationHubs should be handling this for me...
using IPN Simulator, my listener (in sandbox) is working fine.
then I submit the order by the html form.
I noticed that all the IPN messages were "queued" (from the IPN history)
what make this happen? And How can I solve this?
I read some old threads that same case was caused by Paypal Server. Can anyone help to advise on this? Thanks!
This shouldn't happen often, but it could be that the IPN server is simply backed up so the IPNs are waiting in the queue and will be sent as soon as the servers catch up.
Another thing that could cause it, though, is if you have lots of failures happening with your IPN script. In such cases PayPal may place you on a slower queue because they don't want to waste server resources if you're failing a lot. You should get notifications about that if this sort of thing is happening, though, and eventually they would just turn IPN off altogether until you get it fixed and re-enable it.
I need to get the Id of a msmq message inside of my handler so I can write that Id to a log.
When a message is sent to the error queue an email is sent informing us of a failed message. Once the error that caused the message is resolved we need to use the 'ReturnToSourceQueue' NServiceBus tool to try that message again. Without logging that Id, it would be difficult to track down which message is which when looking through the message queues.
Every where I've looked suggests that Bus.CurrentMessageContext.Id will give me the same Id that's in the Message ID column when looking at the queues in ComputerManagement->Services and Applications->Message Queuing->[Some Queue]->Queue messages. However, those ids don't seem to be the same.
What am I missing?
The reason that the message ID that you see in MMC plugin or Queue Explorer is different is that when the message is "moved" to the error queue, what actually happens is that a new MSMQ message is created with the same body and headers and that is sent to the error queue.
Also, when the processing a message fails, NServiceBus already logs this for you and includes the ID of the message, so that's already done for you.
If you take the ID that was logged and pass that to the ReturnToSourceQueue tool, everything will just work.
The last piece of the puzzle for you is sending an email when a message fails. Now, I'm not sure that that is the wisest idea as you may end up spamming your ops team when a database goes offline or a 3rd party webservice becomes unresponsive. Still, if that's what you want to do, then I'd suggest using an email appender for when errors are logged.
Finally, let me say that we're in the process of building this kind of notification functionality into the Particular Service Platform around NServiceBus. We've got a UI showing errors and allowing messages to be reprocessed coming as a beta in November '13 and the notification functionality will probably be ready towards the end of the year.
It's really a question of whether you want to wait or to build this yourself.
Just create an instance of your bus in your handler:
public IBus Bus { get; set; }
Then use that to get the message id:
this.Bus.CurrentMessageContext.Id
The Bus instance will be injected when the handler is called.
EDIT
Now that I have actually read the question...
The CurrentMessageContext.Id returns what's in the message header under the CorrId field. This can be seen in the Label column in Server Management.
The Message ID displayed in the MessagId column is the message ID as it existed on the sending computer. I am not sure how to access this value from CurrentMessageContext but you should not need to do this to find a local message.