On 3-4-2008 8:50, Joel Poloney wrote:
Is your "kill"-message on every call? Or is that only when you manually interrupt it? I'm wondering if you changed the Stomp-implementation such that if you've consumed all of the messages (and it's waiting for a new message to come through), it automatically dies. Or is it part of your "clean kill" that would make sure it finishes what it was doing, and then properly shuts down.
My consumer just consumes a message, processes it and then goes on waiting for another one. So if that message happens to be a 'kill'-message, it dies (if the message was sent after the consumer started).
When I shutdown those consumers using their init.d-scripts, the init.d-scripts sends both a normal sigint and one of those kill-messages to make sure the script gets interrupted anytime soon. For the million-messages consumer, that isn't really necessary, but for the few-hundred consumer it is quite usefull to wake it up, so it can die right away.
In my particular application, I would most likely have an internal queue in the consumer that would basically consume messages until it hit some number (say 100) and then batch process all 100 of them at once. Then it would go back to trying to consume messages again and filling up the internal queue. It's better for me to batch process 100 messages at once rather than 1 at a time. That's why I was asking about the memory leak issues.
One of the reasons to start using these consumers was indeed to facilitate batch processing, although I haven't implemented such a feature yet. But I wouldn't worry too much about memory leaks, as long as you clean up the data afterwards and maybe keep away from using too fancy resources and too complex object trees. I would however add some more clean-kill stuff, so the current internal list is processed cleanly, prior to dieing.
Best regards, Arjen
