For some reason the emails are taking around 8 seconds to send, and it makes the website feel like nothing is happening.
client.Send(message);
client.Disconnect(true);
I am wondering if SendAsync would fix the issue, but would the following code cause any issues in the future:
client.SendAsync(message);
client.Disconnect(true);
I feel like the client could attempt to disconnect before the email is fully sent since the program won't wait for SendAsync.
Is there a better way to do this? I couldn't find an example in the documentation.
You would need to await the SendAsync() or you could end up disconnecting before the message has been sent.
That said, asynchronous methods, depending on how your application is designed, could be the right solution to making your app not "hang".
Related
I use expressjs for my server. A user hits a proxy service that hits mine. The proxy service is telling me that mine has given a 503. In this case, I can't really be logging that it happened since it seems express just error'ed out. All I know is that this other service receives a 503. Nowhere in my code do I set this up. I couldn't find anything when searching around, and if it weren't the proxy I wouldn't know the 503s are happening. In hundreds of thousands of requests, this happened just under 100 times.
I'm not expecting anyone to have the direct answer, however any clues would be much appreciated and any clue that gets to the answer will be marked as the answer with my comment below. Hoping some comments will help me give this question better information!
Well, one thing that comes to mind is server overload. If the route (s) you're checking are performing synchronous tasks, and you're sending alot of requests at once, you might end up blocking your server. Express recommend that every route handler you have should be async, so the server won't get blocked even if a lot of requests are happening.
I don't know if that's your case, but it's worth a check.
The solution relates to Envoy & Node. A coworker suggested server timeouts and I found https://github.com/envoyproxy/envoy/issues/1979.
In my case I added this: server.keepAliveTimeout = 0;
You can see docs over at https://nodejs.org/docs/latest-v10.x/api/http.html#http_server_keepalivetimeout.
I don't work on the infrastructure side of things so it took a bit for me to figure it was in that layer with folks on the teams who implemented the usage of Envoy.
When Envoy gets ECONNRESET it sends back a 503
Hello I am trying to create a simple push-notification system similar to this common use case:
1. The user gets a chest and can either watch an ad to skip the wait time or wait one hours for the chest to open. The app sends an upstream request which sets up a downstream push notification that shall be delivered in one hour to let the user know the chest is ready.
2a. The user then waits an hour, gets a push notification (outside of the app) to open their chest and they do!
or
2b. They wait 20 minutes then decide to watch the ad. The app sends an upstream request which cancels the pending push notification which would have otherwise been delivered in 40 minutes.
Okay awesome so that is the problem and I am having a hard time understanding how to do this. I have looked over the documentation for each of these programs but they seem designed for downstream push notifications. It just seems odd there is no built-in support for this use case. It seems like such a common use case.
I so far found 3 solutions that will integrate into my cross-platform Unity setup and provide services for free or super-cheap:
Amazon Simple Notification Service (SNS)
Google Firebase Cloud Messaging (FCM)
OneSignal
Amazon seems to group clients into "Topics" so I guess I would be setting up a one-device-topic and essentially. I can subscribe and unsubscribe from them but it doesn't seem to support a topic with a 60 minute delay.
2a. Create a topic: https://docs.aws.amazon.com/sns/latest/dg/sns-tutorial-create-topic.html (it would just include the current device)
2b. Subscribe to it
2c. Send a message to it https://docs.aws.amazon.com/sns/latest/dg/sns-tutorial-publish-message-with-attributes.html
So basically I can add attributes to my message but it would seem I need to implement the server-side code to read a delay attribute then somehow queue a message for delay. Maybe I am missing something?
For Firebase I pretty much see the same thing as Amazon. There are topics https://firebase.google.com/docs/cloud-messaging/android/topic-messaging and a means to send upstream messages https://firebase.google.com/docs/cloud-messaging/android/send-with-console but with the messages I don't see anyway here to get the time delay https://firebase.google.com/docs/cloud-messaging/unity/topic-messaging I see conditions towards the bottom of that article but I don't know if it is meant for this use case.
OneSignal has the easiest to scroll-through API. I'll refer to some strings that you can CTRL-F by using the format ("Create Notif") because everything is on this one page: https://documentation.onesignal.com/reference
So basically I can ("Send to Specific Devices") which I guess would be the sending device, then I can ("Schedule notification for future delivery.") using the send_after parameter. And finally, if need be, I can ("Cancel notification"). So this appears to be everything I need. I'm currently looking at this option and trying to figure out how to actually get this working.
So there is my progress over the last few hours researching each of these options. I am hoping you can help me better understand how I may be misunderstanding the above options as this seems to me a very common use-case. Perhaps I am just not googling the question correctly. Any help appreciated.
Whenever there's a likelihood that you'll need to cancel a significant percent of the notifications you send, you should use local notifications. That way you can easily schedule and cancel them locally without making any network requests. Also, this solution works for offline devices which is great for games (played on planes, etc...)
I'm new to NServiceBus, so maybe I'm asking something pretty silly here, but is there a way to make NServiceBus not stop sending any messages that are sent in response to a message whose handler fails?
Let me explain with a simple example.
Suppose I have an OrderPaidEvent that has a handler that does the following:
Look for the customer
Start a DB transaction
Update the customer to a good customer
Send an CustomerUpgradedToGoodCustomerEvent message
Commit the DB transaction
Fairly straightforward, all is well in the world. Now a few months later someone else figures that an email would be nice when an order is paid and thus adds another handler to the OrderPaidEvent to send an email.
Unfortunately, now whenever the mailserver has an issue, this second handler will fail with an error which will however prevent the original CustomerUpgradedToGoodCustomerEvent message from being sent (step 4). But because the DB transaction was already committed (step 5) the customer has already been upgraded to a good customer in the database.
This means that even if the OrderPaidEvent handler is retried the customer no longer changes and thus the CustomerUpgradedToGoodCustomerEvent message is never sent. Worse yet, this is all because of a change to the code that has nothing to do with the original message handler and will thus be difficult to detect.
This seems like a massive flaw and since I'm new to this I'm certain there's something I'm doing wrong, but I can't seem to figure out what it is.
Any help from you fine people would be great.
Thanks in advance.
How about breaking down your procedural code into separate handlers?
Thereafter each logical operation will either be done or will not be done based on successful completion of each granular task.
If you add a Saga to the mix then you can make business decisions based on the completed steps in your Saga.
Also maybe read more about transactions and NServiceBus here
First of all I would send out the CustomerUpgradedToGoodCustomerEvent after the commit. At that point you are sure that the event actually took place.
And in response to your question: You could handle the email in some 'SendEmail' command that is raised after the db commit and before the event is published. If that command fails it will not hurt the handling of the OrderPaid event. When mail is up again, the command can be retried and handled normally.
Going through the logs generated by my 'CoreBluetooth' state machine and have noticed on occasions a didDisconnectPeripheral is being called while the peripheral is in CBPeripheralStateConnecting and before a didConnectPeripheral. The code is immune to this strangeness however I would like to understand what is happening.
Anyone else experienced this or anything similar? I cannot find any logical explanation.
in iOS6 when CoreBluetooth was rather less mature I adopted the connection strategy of requesting a connection, if connection didn't result in the next 2 seconds, I would then call cancelPeripheralConnection and then issue another connectPeripheral this cycle would continue 3 further times before terminating and informing the user that something is wrong.
It would appear that the calls to didDisconnectPeripheral, even when not first connected, were a result of the intermediate calls to cancelPeripheralConnection.
Now with the stability of iOS7 and having learned that connectPeripheral never times out I have removed the complexity of intermediate cancelPeripheralConnection & connectPeripheral calls and just wait for the connection, with a timeout.
No more mystery didDisconnectPeripheral calls!
I have fully working duplex messaging solution for Silverlight application. Now I would like to add one feature to it. When user leaves the application I want to notify the server about that by sending the last message before exit.
I have tried to send duplex message during Application Exit event, but DuplexServiceClient is already in CommunicationState.Faulted state.
I've also tried to establish new connection and send the message. Everything seemed to be okay on the client side, but no message has been send at all. I checked that twice by using Fiddler.
App.Current.Exit += (s, e) =>
{
var dsc = new DuplexServiceClient(_binding, new EndpointAddress("../Services/MyService.svc"));
dsc.SendToServiceAsync(new UserLeave());
};
Crucial thing is, that I need to notify the server immediately after user leaves the application, so timeouts or similar workarounds are not good enough for me in this situation.
Does anybody have a working solution?
I found similar topic here in SO. Aliostad's answer made me think about this once more. You can never be sure you will get the signal from client that he's leaving. So I ended up with timeout solution.