I have a reminder functionality using signal R in asp.net mvc
I have userinterface to set the reminder time, If the current time matches the reminder time , it invokes a popup.
I successfully implemented this functionality with Signal R by checking the database once in every 30 seconds by using javascript timer. If current time does not match, it gives '0'.If it matches, it return '1' and the popup is shown across all browsers. But can this checking the db for every 30 seconds can be replaced by signal R ? is there any way to bring this whole thing to signal R?
You can use System.Threading.Timer to create a periodical method call to both client and server side. According to Sample project created for stocks
_timer = new Timer(UpdateStockPrices, null, _updateInterval, _updateInterval);
It creates and Event-Delegate and calls UpdateStockPrices event timely with period of __updateInterval.
In This event(code given below) you can broadcast the remainder message from server to all clients or clients who are associated with that remainder.
You can write code as :-
Clients.All.updateStockPrice(stock);
You can refer to Timer from link:-
http://msdn.microsoft.com/en-us/library/system.threading.timer.aspx
Yes, you can use Timer in the appdomain scope, application scope or at the hub level. Just get the sample from nuget, called "Microsoft.AspNet.SignalR.Sample". It implements stock timer that periodically broadcasts changes to all clients.
Related
Problem
I need to get a callback when at least X amount of time has passed since the date for the callback has been set.
Example 1:
This would have worked great, but it's possible to trigger an execution of the block by setting the date earlier than the correct time right now:
let responseDate = Date().advanced(by: 60) // 1 min
OperationQueue.current.schedule(after: .init(responseDate), {
print("the time is now!") // possible to set the current date 1 min before
}
On the other hand, the solution for getting a current uptime from this answer works great, but it requires timer constantly running to check if we're close to date.
Is it possible to combine these two approaches and somehow "attach" a callback to KERN_BOOTTIME, so that the OS will call my method when the boottime reaches a certain value?
I'm looking as well to alternative engineering solutions that satisfy two criterias:
It should not be possible to trigger the callback by resetting the device date to some arbitrary value in the past
If the device has been put to sleep (e.g. by pressing the on/off side button), the clock should still be "ticking", so that the method will be called back while the app is running in the background.
More details:
Backgrounding / app termination is out of scope
The main point is to prevent a bypass by switching the date backwards in the settings.
I have a rule chain in ThingsBoard that does a Create Alarm when temperature is outside threshold and does a Clear Alarm otherwise. I receive a message using a Telegram bot when these events occur. That all works fine.
However when the temperature is hovering around the threshold, I can get many notifications as it goes in and out of the threshold temperature. That is somewhat annoying.
I would like to have the Clear Alarm activity only trigger if it is more than 5 minutes (say) since the last Create Alarm event was triggered.
Any tips on how to achieve this?
I finally worked out how to do this.
I added some server attributes to my device that define the temperatures that trigger alarms. I have a rule chain for controlling these alarms with the following nodes:
Enrichment - originator attributes to add the relevant attributes into the metadata associated with this message
Filter - script to detect if the temperature is outside the expected range
Filter - script to detect if the delay period has expired since the last time the alarm was triggered
Action - create alarm when script detects that temp is out of range
Action - clear alarm when script detects that delay period has expired
Transformation - script to update last alarm time attribute
Action - save attributes to persist updated alarm time attribute
Transformation - script to create a message about alarm set or cleared
Rule chain to handle sending the message to a Telegram bot
As an example, here is the script for checking if the delay period has expired before clearing the alarm:
var alarmTime = Number(metadata.ss_lastWaterTempAlarmTime);
var alarmDelay = Number(metadata.ss_clearAlarmTimeDelay);
return metadata.ts >= alarmDelay + alarmTime;
ss is the prefix added for server side attributes that have been added to metadata.
You can see the complete rule chain json in my Aquamon repo.
Flux<Integer> shared = Flux.just(1, 2).share();
shared.subscribe(System.out::println);
shared.subscribe(System.out::println);
Since share() turns the flux into a hot one, I expect the first subscriber to get all values and the second one to get none, since the stream has completed at the time of subscription. But the output is the same as without share: 1 2 1 2, but it should be just 1 2.
When I replace share() with publish.autoconnect() it works as expected. Why is that?
The answer is simple, but it took me a while to figure it out.
share() is a shortcut for publish().refCount(). refCount() is like autoConnect() except for one additional feature: It disconnects when all subscribers have cancelled or - and that's the situation here - the stream has completed.
The first shared.subscribe creates a subscription (via share) to the original flux. All values are emitted immediately, the stream completes, the subscription is cancelled.
Since there is no subscription now, the second shared.subscribe again creates a subscription and the stream starts again, from the beginning.
autoConnect, however, does not cancel the subscription. If you use it instead of refCount the subscription to the original flux remains, but because the stream has completed, any additional subscriber won't receive any values.
I have a service bus queue in Azure and a service bus queue trigger function. When I first publish the function and send a message to the service bus queue the function gets triggered and runs ok.
But if I leave it alone and don't send any messages to the queue for say ~ 1 hour and then I send a message the function doesn't get triggered. I have to manually run the function again in the portal by pressing 'run' or I have to re-publish it to Azure.
How do I keep it running so I don't have to restart it every hour or so???
My app might not send a new message to the queue for a couple of hours or even days.
FYI - I read here that the function shuts down after 5 minutes, I can't use functions if this is the case and I don't want to use a timer trigger because then I'd be running the function more then I would want, wasting money! Right?
If my only, best, choice here is to run a timer function every 30 minutes throughout the day I might just have to suck it up and do it this way, but I'd prefer to have the function run when a message hits the message queue.
FYI2 - ultimately I want to hide the message until a certain date, when I first push it to the queue (ex. set to show 1 week from the time it's placed in the queue). What am I trying to accomplish? I want to send an email out to registered students after a class has ended, and the class might be scheduled 1-30 days in advance. So when the class is scheduled I don't want the function to run until after the class ends, which might be 1 week, 2 weeks 2 days, 3 weeks 3 days, etc after the class is initially scheduled in my app.
Here is the snippet from the function.json
{
"generatedBy": "Microsoft.NET.Sdk.Functions-1.0.0.0",
"configurationSource": "attributes",
"bindings": [
{
"type": "serviceBusTrigger",
"connection": "Yogabandy2017_RootManageSharedAccessKey_SERVICEBUS",
"queueName": "yogabandy2017",
"accessRights": "listen",
"name": "myQueueItem"
}
],
"disabled": false,
"scriptFile": "..\\bin\\PostEventEmailFunction.dll",
"entryPoint": "PostEventEmailFunction.Function1.Run"
}
Here is the function
public static class Function1
{
[FunctionName("Function1")]
public static void Run([ServiceBusTrigger("yogabandy2017", AccessRights.Listen, Connection = "Yogabandy2017_RootManageSharedAccessKey_SERVICEBUS")]string myQueueItem, TraceWriter log)
{
log.Info($"C# ServiceBus queue trigger function processed message: {myQueueItem}");
}
}
I've been asked to post my payment plan
I suspect you're using scenario 1 and 2 below - which will shutdown after a period of no activity.
The Function app on a Free/Shared App Service Plan. Always On is not available, so you'll have the upgrade your plan.
The Function App on a Basic/Standard/Premium App Service Plan. You'll need to ensure the Always On is checked in the function Application Setting
If the Function App using a Consumption Plan, this should work. It will wake up the function app on each request. For your scenario I would recommend this approach as it only utilises resources when required.
FYI1 - If you get the above working, you won't need the timer.
A Consumption Plan in the Application Settings will look like:
Please check your service plan by
1. Platform features
2. App Service plan
3. under Pricing Tier
Please provide you app name.
NSRunLoop has two apis:
- (BOOL)runMode:(NSString *)mode beforeDate:(NSDate *)limitDate
and
- (void)acceptInputForMode:(NSString *)mode beforeDate:(NSDate *)limitDate
I mean they are same except return value, or there are other differences?
As #DarkDust hints at, it used to have to do with timers. See Chris Kane's discussions on the Cocoa mailing list. At one point, runMode:beforeDate: was a wrapper around limitDateForMode: and acceptInputForMode:beforeDate: (since acceptInputForMode:beforeDate: didn't fire timers). My reading of the docs, headers, and crash stacks suggests that today, they behave identically (calling CFRunLoopRunInMode(), which does fire timers). But I haven't built a test app to confirm.
If you read the original NeXT ObjC manual, acceptInputForMode:beforeDate: used to explicitly not fire timers:
Blocks awaiting input from the ports in the port list for the input mode mode until the time specified by limitDate. Use the limitDateForMode: method to calculate limitDate. If input arrives, it is processed using the NSPort delegates. This method does not check the timers associated with mode, thus it does not fire timers even if their scheduled fire dates have passed.
Timers were explicitly handled as a side effect of limitDateForMode:
Polls mode's input sources for their limit date (if any) and returns the earliest limit date for this mode. Uses the NSPort delegate method limitDateForMode: to determine the limit dates of ports. Fires timers if their limit dates have passed. Polls ports for activities appropriate for mode. Returns nil if there are no input sources for this mode.
Which is why runMode:beforeDate: was added as a convenience (see NSRunloop.h):
#interface NSRunLoop (NSRunLoopConveniences)
- (void)run;
- (void)runUntilDate:(NSDate *)limitDate;
- (BOOL)runMode:(NSString *)mode beforeDate:(NSDate *)limitDate;
#if (TARGET_OS_MAC && !(TARGET_OS_EMBEDDED || TARGET_OS_IPHONE))
- (void)configureAsServer NS_DEPRECATED(10_0, 10_5, 2_0, 2_0);
#endif
See also from NeXT:
The method limitDateForMode: returns the earliest limit date of all the input sources for the mode NSDefaultRunLoopMode. acceptInputForMode:beforeDate: runs the loop until that date, processing any input it receives until that time. As a convenience, you can use runMode:beforeDate: instead. It invokes acceptInputForMode:beforeDate: and limitDateForMode: with the mode you supply.
So the short answer: history.