This surely solves the concurrency issue, however I'm failing to see how i can prioritize among the different tasks.
I've been playing around with TearDownReceiverGroup(), to allow for "only" search message dispatching. It seems that the TearDown happens after all items in the queue has been handled. For instance..if the queue contains 10 adds, and 5 delete, while a new search
message enters the queue, how can I setup my statemachine so that the search message is dispatched before the others messages already in the queue.
I'm working on a problem that seems to be perfect for the CCR. The task at hand is concurrency and coordination against a very picky search index. The index axcepts several different operations, such as search, add, delete, optimize and so on. However, these
operations has to be coordinated according to priority, concurrency rules and available resources.
Priority: Search typically requires a fast response.
Concurrency rules. There is a matrix defining which operations that can execute at the same time. Search + Add is ok, Add+Delete is not.
Resources: The resourcelevel may at any time change, resulting in (for instance) a full stop in none search operations.
Obviously this can be done with some sort of object queue, and some sort of traditinal control unit that, i'm guessing, will have to do a lot of work (and most likely will have some issues). What i'm looking for is a way of implementing my queue fast, and as
flexible as possible. My first thought when i read about ccr was that i can get a lot of what i want for free. Am i right?
I'm guessing that the right solution is to implement my own port, which supports my set of index operations. What i'm not to sure about is how i can create a receiver that at any time know which queue items to dispatch (according to the concurrency matrix,