I'm struggling with Hiredis asynchronous API. I just want to write some key value pairs into Redis without waiting the reply. I dont need that, i'm not interesting that it was successfull or not. I just want to send SET commands in nonblocking mode.
I tried to use the async API of Redis but did not manage to get it work as I want.
Is it possible to use redisAsyncCommand(ctx, 0, 0, ) without event loop? Do I need to create a thread for this operation? But then what means async?
Thanks!
Related
I have a question regarding Flink and its timer service.
I have a keyBy stream which uses a timer,
When the timer is called I need to send an http request which might take time to respond.
My question is, should I make the http call async?
or flink is making the timer call already as a new thread with async per key?
Thanks in advance
You can use a ProcessFunction that stores the data required for the HTTP request, and that can have a timer. When it fires, you emit a record that has the request data, which a subsequent AsyncFunction will use to make the periodic request that you need.
If You are asking if the onTimer method is invoked in a separate thread for each key, then I am pretty sure that it is not. So, You would need to invoke the HTTP call asynchronously in this case.
But to be completely honest, I don't think this is a good idea, in general, to use the onTimer function to perform HTTP calls. I don't know anything about Your use-case, but I think You should consider using different mechanisms like creating side-output and then using the Flink Async operator. Using asynchronous calls inside the onTimer can be tricky, especially if You consider things like retries, timeouts and possible failures.
So according to comment the use-case is to make a call to service each X mins and then post something to Kafka. So, what You could do is to simply have a process function that schedules timers. Each time the timer is fired You then generate some output record with data needed for request if there is any data needed. Then You use the Async operator to actually perform the requests, parse the response and based on the response generate some output record that can be then saved to Kafka.
I have an application where the web ui (react) Cloud Function then runs and updates a completion value in the database.
How can I show a 'progress' indication and take it down when the Cloud Function has completed?
I initially thought I would do something like this pseudo code with Promises:
return updateDatabaseToTriggerFunctionExec()
.then listenForFunctionDoneEvent()
.then return Promise.resolve();
However, I'm not sure how to know when the function has finished and updated a value. What is the recommended way to detect when a triggered Cloud Function has completed?
You'll have to implement something like a command-response model using the database as a relay where you push commands into a location and the function pushes results out that can be listened to by the client that issued the command. The thing that makes this work is the fact that the locations of the commands and responses and known between the client and server, and they have a common knowledge of the push id that was generated for the client command.
I go over this architecture a bit during my session at Google I/O 2017 where I build a turn-based game with Firebase.
An alternative is to use a HTTP function instead, which has a more clearly-defined request-response cycle.
New to firebase and trying to understand how things work. I have an android app and plan to use the offline support and I'm trying to figure out whether or not I need to use callbacks. When I make a call like:
productNode.child("price").setValue(product.price)
Does that call to setValue happen synchronously on the main thread and the sync to the cloud happens asynchronously? Or does both execute asynchronously on a background thread?
The Firebase client immediately updates its local copy of the data with the new value. As part of this it fires any local (value, child_*) events that are needed.
Sending of the data to the database happens on a separate thread. If you want to know when this has completed, you can register a CompletionListener.
If the server somehow cannot complete the write operation (typically because the write violates a security rule), the client will fire any additional events that are needed to get the app back into the correct state. So in the case of a value listener it will then fire a second value event with the previous value.
What is the CPU costless between sending data to a client via publish/subscription and via Method calls?
My answer is going to assume that you simply want to send data to the client:
It depends on what you want to do. If you want realtime updates the subscriptions model is ideal when compares to call a server method each 5 seconds or so.
When you don't want reactive updates, simply pass the flag reactive:false in your find() query.
Methods are used when you want, for example, to return the results on an aggregation (because meteor doesn't support reactivity for aggregations), to get updates for unsupported operator ($where is not supported yet), etc.
Usually the bottlenecks exists in the application design/architecture.
I have a program in which it insert a raw in a table after certain operations. I wan to call a web service in code behind to do some special tasks by the using of info that there is in the inserted row.
How I can do that?
Is it good idea to invoke this web service from a stored procedure or not? What are the other options?
More Details: Actually, I have an operation in my web application that take a long time to be completed and it is seriously time consuming operation. I don't want client wait until this process finish. That is why I decide write a web service to do this process in the background.
Therefore, I think it may be a good idea that when client request receive I insert his request in a table and call a web service to handle it. Moreover, I do not want to wait until web service return the result, so I will aware client from its result through the report. I do not know what is the best solution to handle it.
I usually keep myself far away from table triggers(it sounds like you're about to use an on insert trigger for a table).
I don't know your specific situation but you could either :
Call the webservice before or after you call the stored procedure, this way the data layer(stored proc) only handles data and nothing more. You're logical layer will handle the logic of calling an extra webservice.
Write a service that will periodicly read a table and notify the webservice of the latest modifications. More messy but it resembles more the effect you're trying to achieve.
There are probably more solutions but i'd need more information on what it exactly is you're doing. Right now it's kinda vague :)
It is never a good idea to call webservice from Stored procs or other DB objects. You can call it from your code, just after you execute the insert and commit it.
The problem it sounds like is that you cannot guarantee that the web service will be called unless you call it before committing the transaction. However, it sounds like the web service needs to be called after commit. In this case, it sounds like you should use a message queue. You could either build one in your database or you could use one off the shelf (http://aws.amazon.com/sqs/ or http://www.windowsazure.com/en-us/home/features/messaging/).
The steps would be:
Insert message into queue (after this is success you can return the call, depending on what your contract with the caller is)
Read message
Insert into table
Call web service
Delete message
The downside is that you will need to make the operations (inserting into the table and calling the web service) idempotent.