why setReturnCallback executes before the setConfirmCallback ideally setConfirmCallback callback method should execute before the return callback.
It's not clear what you are asking; if you mean the return callback is called before the confirm callback is called, that's simply the way the broker works.
It is important that it is executed that way. When you use CorrelationData we want to make sure the returned record is added to the CorrelationData before its Future is completed.
Related
I am fairly new with Commands and Queries in Spartacus. Let me ask with an example. Let's say I am calling this method
checkoutDeliveryAddressFacade.createAndSetAddress(address) which is returning an Observable<Unknown>. When the Observable emits, can I assume the operation completed on the backend? How do I know if the operation has succeeded or not? Do I need to call getDeliveryAddressState after calling createAndSetAddress?
From the description in the pika documentation, I can't quite get what add_callback_threadsafe() method does. It says, "Requests a call to the given function as soon as possible in the context of this connection’s thread". Specifically, which event does this callback get associated to? Since, add_callback_threadsafe() doesn't receive any "event" argument, how does pika know when to invoke that callback?
Also, in the official example, why do we even need to build the partial function and register the callback in the do_work() method? Could we not just call the ack_message() method after the time.sleep() is over?
The reason why the method exists:
How to add multiprocessing to consumer with pika (RabbitMQ) in python
If you use the same rabbit connection/channel with multiple threads/processes then you'll be prone to crashes. If you want to avoid that, you need to use that method.
Could we not just call the ack_message() method after the
time.sleep() is over?
No, you would be calling ack_message from a different thread than the main one, that's not thread safe and prone to crashes. You need to call ack_message from a thread-safe context, i.e., the add_callback_threadsafe().
We’re using Ninject.Extensions.Interception (LinFu if it matters) to do a few things and I want to know if its possible to return a value form the method being intercepted.
EG
A Call is made into one of our repository methods
Our Interceptor gets the BeforeInvoke event, we use this to look into the ASP.NET Cache to see if there is any relevant data
- Return the relevant data (this would cause the method to return immediately and NOT execute the body of the method
- Or Allow the method to run as per normal
Extra points if in the AfterInvoke method we take a peek at the data being returned and add it to the cache.
Has anybody done something similar before?
From your question I assume that you derive from SimpleInterceptor. This will not allow to return imediately. Instead you have to implement the Iinterceptor interface. You can decide to call the intercepted method by calling the Proceed method on the invocation or not.
My purpose is as follows: I want to create a deferred calling method. I might need to create a block for this, but I'm not sure. Can you explain me how to create a block for this?
This is the code:
- (IBAction)buyItem:(id)sender {
BOOL purchase = ... /*call purchase method use block*/
}
In this method I make a purchase and after the purchase has completed successfully I want to get result in my variable purchase.
To be more clear:
Step 1: Call the buyItem method.
Step 2: Wait for a response to the purchase (I've omitted the actual methods for the purchase)
Step 3: After the StoreKit object return a response about the purchase, write a value into the variable purchase.
Step 4: After writing the value into purchase, my method buyItem completes execution (go to the } and release).
My question is not about StoreKit specifically (meaning the StoreKit response method - this is an example only). The purchase variable is an example, too. For this variable I will use a data model and it will change after the deferred method executes.
Thanks all!
You do need a block, but maybe a different kind than you're thinking about. You don't need a 'closure', you need a function that will block until it receives the response from the store kit/server.
You can just write a normal buyItem method, but inside you either make a synchronous call to store kit, or if that's not possible, you use threading techniques to achieve what you want. For example, you could wait on a condition variable and then signal it when the store kit call returns.
For both cases, you'll want to perform the 'buyItem' call on a thread other than the UI thread, otherwise your UI will freeze. Given that constraint (if you're even dealing with a UI), I would say this entire approach doesn't make sense. Instead, you'll want to launch the store kit call, set some indicator or spinner or something in your UI, and then when the store kit call returns, unset the spinner or whatever. Make sense?
I'm wondering if I'm able to time a thread to be executed repeatedly (like when using the scheduledTimerWithTimeInterval method in NSTimer).. I have a view controller, where there is a method I want it to be executed either manually (by clicking a button), or automatically (by timing the method execution). The problem is that, this method will connect with a remote server, and it will update the result on the view, so I don't want it to block the main thread (the view controller thread).
I don't know what to use, so if there's anyone knows how, please let me know :)
Thanks in advance..
It sounds like you might be using an NSURLConnection, and if that's the case, then as joshpaul noted, it will act asynchronously by default. That is to say, when you start the connection, the NSURLConnection object will create a new thread, do its work on that thread, and return results to you on the original thread via the delegate methods, cleaning up the second thread afterwards. This means that the original thread, main or not, will not be blocked while the connection does its work. All you have to do, then, is have your timer's action create and run the connection.
In other cases, you have a couple of options. It's easy enough to set up a timer method that will call another method to be performed in the background:
- (void)periodicMethodTimerFire:(NSTimer *)tim {
[self performSelectorInBackground:#selector(myPeriodicMethod:)
withObject:myPeriodicArgument];
}
This can make it difficult to get results back from the other thread (because you need to pass a reference to the original thread to the method). However, since you seem to be on the main thread to begin with, you can use performSelectorOnMainThread:withObject:waitUntilDone: passing NO for the wait argument to get back.
The more complicated option is to set up your own background thread with a timer running on it, but I'd be surprised if that was really necessary.
If you're using NSURLConnection, it's asynchronous. That'll likely work for your needs.