Dec 18th, 2012, 02:26 PM
DMLC maxMessagesPerTask causes inability to scale down
I was going to put in a bug/enhancement request, but decided to discuss here first. Keep in mind what started me down this path was I noticed that my DMLC was able to scale up fine, but it was never scaling back down. After digging through the source, I believe this is due to how maxMessagesPerTask is implemented which is somewhat out of line with the api documentation. I say somewhat is because it is mentioned in text for setIdleTaskExecutionLimit, but no mention of it in setMaxMessagesPerTask. Also the name of the property itself ends up being misleading.
The max is also a min. Unless the container is stopped, it will look for messages until it reaches maxMessagesPerTask. If you use the default (-1) it will look forever. A side effect of this is the check to scale down doesn't occur until after maxMessagesPerTask is reached, hence also a minimum. Again if you use the default maxMessagesPerTask settting (-1), it will never scale down! I don't think this is the intended behavior as the class documentation implies I should just be able to set maxConcurrentConsumers higher than concurrentConsumers to achieve dynamic scaling, which includes scaling down.
IMHO, what should happen is the task should be considered idle as soon as it doesn't receive a message. Once it doesn't receive a message, then it should check idleTaskExecutionLimit. Of course if maxMessagesPerTask is > 0, then it needs to check that after every receive call.
Am I off base here?
Last edited by bbohl; Dec 19th, 2012 at 09:26 AM.