Hi all!
We are playing with Event Registry and build a prototype of a process which communicates with other our systems via RabbitMQ. Event Registry looks very promising, we really like it! But we discovered couple of strange things.
The process we created works well, while we have only one task listening to events in particular queue.
A sends a message to the queue Requests and waits for the reply from the Queue Responces. After deployment of this process we see that one channel is created and it works as expected.
As soon as we are adding an additional task B immediately after the first one, which is configured to send another messages to the same queue Requests and wait for the answer on the Responces queue, things are getting worse.
We see that there are two channels are created and they do compete for consuming messages. For example:
message is sent from the task A into Requests queue
the recipient process it and send a reply to the Responses queue
A got the reply and transition to B is taken
B sends the request to the Requests queue
the recipient gets the message and puts the reply to Responses queue
Now there is a possibility, that channel dedicated to the task A will get the message before B. Then weļl see that it tries to process the message, but as soon as it realizes that there is no active task, it will release the message. Unfortunately, it will get the message back from RMQ. As a result, the process will stuck in B.
Probably, it is time to mention that we are not using .channel and .event descriptors, we are trying to get things done using only properties specified in the BPMN. So the first question is - would described behaviour change if .event and .channel files will be available?
The other aspect which looks like a bug, is that after stopping the process and deleting the deployment, the channel description will remain in the flowable database and flowable will continue to listen to the queues. This leads us to the second question, which, probably will not be answered but I shall ask it anyway - how close you are to releasing 6.5.1? We built one experimental feature, taking into account peculiarities found, and whish to put it into production. It looks like the safe way of doing it is to create one more flowable instance dedicated to new functionality, which uses Event Registry. Please suggest how to approach this situation.
Use Correlation Parameters to distinguish Inbound message belongs to which Event (event/ channel files).
Let’s say if one of the response parameters have “nextTask” : “A/B”, which can be set as Correlation Parameter matching.
Redesign the Workflow, as both tasks using same response queue
Start Event => A (Send Event Task) => B (Service Task) => X (Exclusive Gateway, Default Transition) => End Event
Start Event => A (Send Event Task) => B (Service Task) => X (Exclusive Gateway, Conditional Transition) => A (Send Event Task)
B (Service Task) should set a Boolean Flag goBackToA to be used in Conditional Transition to evaluate Exclusive Gateway
Conditional Transition ${goBackToA} will go back to A (Send Event Task) when it evaluates to true, otherwise chooses Default Transition to go to End Event
We tried Correlation Parameters, didn’t help. We got an impression that correlation takes place on the engine side.
We actually found another workaround, simply started to use different queues for different tasks. But we would use Event Registry broader, therefore understanding of base functionality is a must. Thats why Im asking
Let me try to describe briefly how it works here. Inbound channels are independent than any BPMN process. They are not dedicated to any task. For example an inbound channel is a channel listening on the Responses queue. Whenever, a message the engine checks for all registered activities which are listening for this message. All activities which are listening for this message will get triggered.
With your example if you have a single Responses queue then you will have one channel which listens on this queue. Whenever a new message comes in, based on the defined correlation parameters it will look for all tasks, boundary events that match them and trigger them. The correlation parameters are defined on the task level. For example you can have a task that doesn’t use them, this would mean that this would be triggered every time a message comes in. Or a task might use only a single parameter, so it will be invoked when a message contains a correlation parameter with that value.
In your example if you have 2 channel definitions linked with different event definitions then they will race for messages. I would advise using dedicated .event and .channel files for this.
The reason for that is because the event and channel definitions are deployed to the event registry engine. You’ll have to find and delete the deployments in that engine that have the process engine deployment as a parent.
Have a look at the answer here. tl;dr we don’t have a date for the next release yet.
