I'm calling the Sidekiq delay on a class method like:
Class.delay.some_method()
This works well except when there are errors because I cannot set the retries to false. Any advice on this?
The documentation shows retries for non-class methods (worker): https://github.com/mperham/sidekiq/wiki/Error-Handling
How do I set the retries to false for a class method without needing to convert it to a worker?
You can actually do this
Class.delay(:retry => false).some_method()
Documentation here
Related
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().
I am trying to implement the Hystrix into our micro-services project. To keep the question simple and concise, I will describe the scenario below:
(a) A call to a backend service which is performing slow at times (e.g. Payment Service)
(b) I have annotated the method with #Hystrix (from where I am making the call to the payment service). Also, I have implemented the corresponding fallback method.
(c) Below is the code snippet for the same.
#HystrixCommand(fallbackMethod = "fallbackProcessPayment")
public String processPayment(User user) throws Exception
{
// Call the payment service (which is slow in nature) to process the payment for the user....
}
public String fallbackProcessPayment(User user){
// This is the fallback method for processPayment....
// Gracefully handle the processPayment
}
In the config.properties file timeout is configured as
hystrix.command.getUseCase1.execution.isolation.thread.timeoutInMilliseconds=2000
Current Behavior - As soon as call to the backend Payment service is made from processPayment(..) method, it takes longer (~ 4000 ms) than what I have set in the hystrix.command.getUseCase1.execution.isolation.thread.timeoutInMilliseconds (2000 ms)
and hence Hystrix calls the fallbackProcessPayment (...) but what I also see is the fact that backend Payment service also gets executed albeit slowly.
This is undesired behaviour as Payment is being processed in the background as I also notify the user (through the fallback method) that we are not able to process the payment (because the call was timed out as paymentService took 4 secs to respond whereas Hystrix expected the response in 2 secs (based on timeoutInMilliseconds configuration).
Is there are any configuration which I am missing to make it work properly ???
Any pointer into this would be of great help.
Thanks for your time
Well. This is the expected behaviour of hystrix. You have couple of options.
1. Either increase the timeout
2. In your fallback method check what is the reason for the method to fail. i.e. on which exception. (You can get to know this by adding a argument to your fallback method of type Throwable which will have the exception for which fallback method is triggered). If the failure is due to timeout then you can write a piece of code to check if the previous process completed or not before returning the response.
But the second approach isn't feasible because, If you have set your threshold as 5 and if 5 requests fail due to timeout in succession then the 6th request will directly go to your fallback method. Where checking if previous process completed or not doesn't make sense.
I'm implementing a Twilio-powered Call Center and I'm currently using Enqueue to hold calls until an operator can answer them. I'd like to use StatusCallback to warn operators that a call that was on hold is now "completed" (caller terminated the call) but StatusCallback seems only to work with a "Client" verb. I'd want to use it with along with "Enqueue" or a "Gather" in the WaitURL.
Am I missing something?
I found that setting the StatusCallback endpoint in the Application configuration in the Twilio Dashboard globally solves this.
I know how to use the FileSystemWatcher class, and I know how to send the message I want to send. What I can't figure out is where to initialize the FileSystemWatcher.
I'm assuming that there's some place to initialize an Endpoint where I could set this up, but I'm not certain where that would be.
Seems like this would be a common use-case; I'm a little surprised that Udi hasn't built this into NServiceBus!
Yes that is built into NServiceBus.
You need to implement a class that derives from IWantToRunWhenBusStartsAndStops.
See http://docs.particular.net/nservicebus/the-nservicebus-host#custom-initialization-and-startup for more info.
I'm going to try the following and tell you if it worked:
Create a FileWatcher class with
a. a static boolean variable 'keepChecking'
b. a static method watchFiles() which initiates the FileSystemWatcher and then stays alive with a loop that tests the keepChecking
b. the OnChange etc. FileSystemWatcher event handlers
- which upon being triggered by the FileSystemWatcher, presumably send out NServiceBus events
To start the watcher (in my NSB Host program) You run the WatchFiles() method in a separate thread in a starter class which inherits from IWantToRunWhenBusStartsAndStops.
To stop the watcher you first set the watcher.EnableRaisingEvents to false then set the keepWatching to false so the loop ends.
A similar approach in this StackOverflow question with code:
NServicebus with File System Watcher from Tylor Day.
Except that he unified the starter class with the filewatcher class and its (non-static) creation method running in the same thread. Interestingly it works without the need for a keepalive loop, since the FileSystemWatcher event-subscription is defined as static.
He was told that this is not the best way to go and was given two suggestions: a. To use a "satellite class" or b. To move the whole thing to a separate class, making the fileWatcher itself static. No mention of a keepalive loop. I'll try that too.
I've got Resque set up in my Rails 3.2 app and have an after hook which successfully calls
Resque.enqueue(SomeJob, self.class.name, id)
I can see the job getting fired off, but no methods in my SomeJob class are getting executed. I've got a logger set up confirming the SomeJob gets executed but the log statement inside my self.perform block never gets called.
def self.perform
log.debug("working")
end
So far I've tried methods named self.work, work, self.perform, perform and nothing seems to get called. The Resque documentation seems to be geared towards a pending 2.0.0 release but I can't quite get this to work even with 1.24.1 or 1.22.
What is the magic method that gets called in Resque? Is there any way to explicitly call it in Resque.enqueue?
At first glance it looks like you're passing in two arguments (self.class.name and id), but the self.perform method isn't able to accept them, so it could be silently failing with an invalid argument error.
My suggestion would be to change the self.perform method to the following:
def self.perform(class_name, id)
log.debug("working: class_name=#{class_name} id=#{id}")
end