What are the best practices for implementing a processor that needs to
maintain some kind of state?

I'm thinking of a processor that executes on a timer and pulls data from
somewhere, but needs to know where it left off for the next execution, and
I was hoping to not involve an external data store here.

>From looking at processors like GetJMS and GetKafka, I noticed the use of
BlockingQueue<> where poll() is called at the beginning of onTrigger(), and
then the object is put back in the queue in a finally block.

As far as I could tell it looks like the intent was to only have one object
in the queue, and use the queue as the mechanism for synchronizing access
to the shared object, so that if another thread called onTrigger it would
block on poll() until the previous execution put the object back in the
queue.

Is that the general approach?

Thanks,

Bryan

Reply via email to