Not backward compatible with sidekiq and active-support about karafka HOT 4 CLOSED

Hello @VishalRam, glad that you like it! :)

Unfortunately we're locked to at least 0.17 because we want to be up to date when 1.0 is released. If it goes about Sidekiq, we could be backward compatible with 3.4.1 (same api, etc), however isn't it just easier to upgraded to 4.0 for you, since it 100% compatibility? You can always use older revision of Karafka (we will be shipping via rubygems soon) - we locked those version few commits ago.

from karafka.

@mensfeld - I have certain dependency on Sidekiq 3.4.1. I use a gem Sidekiq-throttled which works only for Sidekiq <4.0.0 versions

from karafka.

They are looking to update it to work with sidekiq 4. Maybe you should wait a couple of weeks for this or you can help with a PR.

I don't think the fix will be very easy, personally I'm using sidekiq-limit_fetch, and the change for sidekiq 4.0 was not trivial:

deanpcmad/sidekiq-limit_fetch@206e022

from karafka.

@VishalRam I think I've found a compromise solution for you: you can use Karafka only as a proxy server for your logic making it a separate app that will just have same worker names. Meanwhile you can use your app workers (and everything else) the way you use it (as long as none of your sidekiq extensions changes the perform_async method):

• Create a new Karafka application (based on readme)
• Create controllers for topics on which you want to listen
• Assign custom workers (that way you won;t have to have the #perform method and logic in it)
• Run bundle exec karafka server to start listening
• Create "full" proper workers with the same queues names (or leave default) in your "full" application
• Start workers from your "full" application

from karafka.