xinix00
commented
7 years ago I will check your new version tomorrow and merge it, to create a pull request without the need of resolving conflicts.
My new version allows only one queue per worker (fires an exception when you use multiple inside one worker). This is due to the design using "BlockingCollection", it will wait till an item gets added to the queue and release the thread to go ahead and grab it.
Possible ways to make it work (adding multiple queues to a worker):
- Don't use a blockingcollection, but loop forever to see if something gets added to the queue
- This normally works with a Thread.Sleep(), but I wanted to keep it as fast as possible
- Use multiple threads, one for each queue, to await the "start" sign (the releasing of the thread by adding an item to the blockingcollection)
- In my opinion a worker is a single threaded object (in base) and should not use multiple threads (no matter what)
- Extra downside, it could receive 2 items at about the same time, which would give a single Worker 2 tasks to handle, or should readd one of the 2 items back to the queue it came from
- Rewrite FetchNextJob to use only one queue per worker
- Which eighter uses multiple subscribtions inside ravendb or should use one of the ideas above
Since I like the design using BlockingCollections to stop the thread and start as soon as an item gets added to the Queue, to me, I think it's a fair trade off to use: new Worker("queue_1"), new Worker("queue_2"),
Instead of: new Worker("queue_1", "queue_2")
Please let me know your thoughts
AustinWinstanley
Added: Hangfire/JobQueues index Changed: JobQueue to handle multiple queues correct. Each worker can have only one queue to monitor (by design) Changed: all queries to be handled by one of the two indexes Changed: Hangfire.Core to include 1.6.4 Changed: RavenDB.Client to include 3.0.30155 Bugfix: Add StartedAt for a RavenServer Bugfix: Remove RavenServers/ prefix from server names for gui to not show error "Server is probably offline" Removed: Double execution of Indexes