You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Jesque allows to set a custom exception handler to the worker if one chooses to. I don't see a way of doing this in the plugin when the workers are configured externally and started automatically. Would it make sense to expose this as an option?
The reason is that currently the jesque-grails plugin works with the default exception handler. This exception handler does not have any logging and for JedisDataExceptions, the worker is terminated. The main problem with this pattern is that you don't really know if your worker has been terminated.
The text was updated successfully, but these errors were encountered:
I agree, we've seen some of the same issues. I actually made a grails-jesque 0.5.1 with some logging, but forgot to push it to github. I had to submit a pull request to Jesque (gresrun/jesque#26) to support what I wanted to do. That's there now in Jesque 1.3.0, but there are separate issues (#24) preventing an upgrade for now. I've submitted a pull request and will start working on the changes locally to support setting an exception handler.
Could you tell me a little bit more about how you've configure grails-jesque? Are you running your workers entirely by convention (i.e. just job classes with not config), or do you have some of your config in config.groovy? I have some ideas about how to do it, but some options would not work in certain configs.
Jesque allows to set a custom exception handler to the worker if one chooses to. I don't see a way of doing this in the plugin when the workers are configured externally and started automatically. Would it make sense to expose this as an option?
The reason is that currently the jesque-grails plugin works with the default exception handler. This exception handler does not have any logging and for JedisDataExceptions, the worker is terminated. The main problem with this pattern is that you don't really know if your worker has been terminated.
The text was updated successfully, but these errors were encountered: