On Sat, Jan 19, 2013 at 3:09 AM, Claus Ibsen <[email protected]> wrote: > Hi > > We could possible enhance scheduled poll consumer to allow people to > set a max number of polls > http://camel.apache.org/polling-consumer.html > > The timer component has a "repeatCount" option for that kind of use-case. > This will though still let the consumer be started and running, it > just prevents any further polling. >
The thing is, you don't want the scheduler to start, initially, otherwise, it will poll once, find no data, then nothing. You want it to poll when the data has been inserted into the database, so you need the other route to signal that fact, which is why I implemented that custom PollingConsumerPollStrategy the way I did, although, now that I think about it, a better way to signal the JPA consumer would be via a message rather then explicit method calls on the JpaConsumer. It's kind of a hack because we're trying to use the EIP pattern, "Polling Consumer", but kludging it to behave as EIP pattern "Even Driven Consumer", which is really what we need in this use case. There are some other details that need to be addressed to make this fully flexible, if you don't want to consume-delete, nor update a field to "mark as processed" via @Consumed. For example, you may want a separate table to keep a tally of primary keys of consumed entities, or maybe you want to just indicate that a timestamp field value older then some value means the entity is consumed, or too old to be a candidate for consumption, etc. E.g. maybe have some sort of pluggable IndicateConsumedStrategy and provide a few strategies, per the suggestions, above. -Chris > > On Sat, Jan 19, 2013 at 1:42 AM, Chris Wolf <[email protected]> wrote: >> On Fri, Jan 18, 2013 at 12:01 PM, Gershaw, Geoffrey >> <[email protected]> wrote: >>> Hello once more, >>> >>> >>> >>> >>> >>> So I read in the documentation that the jpa component polls the db. >>> Kinda a poor man's queue. I had hoped that this behavior would be >>> configurable. I don't want to poll. I just want to retrieve the entities >>> 1 time. I would think the jpa component could do this. >>> >>> >>> >>> It doesn't appear so. Am I correct? >>> >>> >>> >>> I guess I shall create a custom bean to do the retrieval? >>> >> >> You don't need to. I created an alternative >> PollingConsumerPollStrategy implementation, >> "OneShotPollingConsumerStrategy" (attached). >> >> The way it works is that you configure your JPA consumer endpoint with >> the options, >> "pollStrategy=#oneshotPoller&startScheduler=false" and make sure this >> route has it's >> id set. When you create an instance of >> OneShotPollingConsumerStrategy, pass this >> route id string in the singel arg constructor, or call >> setDefaultRouteId(id) on the instance. >> >> To signal the JPA consumer route to perform it's >> one-time reading of the DB, change the route you want to drive this, >> by appending: >> >> .beanRef("oneshotPoller", "resumeJpaConsumer"); >> >> ...to the end, so that when that route's processing completes, it will >> signal the >> JPA consuming route to read once. This works by >> OneShotPollingConsumerStrategy.commit >> calling JpaConsumer.suspend(). >> >> Upon the very first invocation of >> OneShotPollingConsumerStrategy.resumeJpaConsumer(), it >> will actually merely just start the scheduler, which stays running >> from then, on. The second >> ans subsequent invocations of >> OneShotPollingConsumerStrategy.resumeJpaConsumer() will >> just call JpaConsumer.resume() and do nothing with the scheduler. >> >> There could be unintended consequences of calling >> JpaConsumer.suspend(), so I can't guarantee >> this solution is robust at this point. >> >> Sorry for the rough and lazy explanation. If anyone finds it useful, >> I can document it better. >> >> Regards, >> >> -Chris. > > > > -- > Claus Ibsen > ----------------- > Red Hat, Inc. > FuseSource is now part of Red Hat > Email: [email protected] > Web: http://fusesource.com > Twitter: davsclaus > Blog: http://davsclaus.com > Author of Camel in Action: http://www.manning.com/ibsen
