I might suggest posting the full code--or, even better, a minimal example that demonstrates the problem (almost always, when people try to create one of these, they discover whatever thr problem actually was and are able to fix it themselves). It's not clear to me which job you are referring to, but looking at thr log entries that I assume are supposed to demonstrate the problem, I don't see any method that runs and generates those entries, so I assume something is missing.
Also, I recall someone asking a similar question a while back and got a couple ideas there. I'd also suggest lookimg that thread and making sure it's not the same thing. The logs make it seem like it could be.
EDIT: found it! (Thought this might have been your question too, but it's not. But looks like the same issue, likely.)
Thanks the problem was the reschedule at the same time it was running.. so that it would immediately run again.. i will add a pause brefore rescheduling.. because just like the other case it was rescheduing the same minute it was running.. that is the real issue.. thanks again.
Yeah, the idea is that if it's 9:04 AM and you're running a cron job at that the that is, itself, (re)scheduling the same thing for 9:04 AM as part of its execution, it may run multiple times until the scheduler no longer thinks it should run. (I don't know the details of how Quartz, the scheduler here, works in these specific cases--like if you say 9:04 if it only means the top of the minute or any time during that minute, but both this behavior and the one in that thread sounds like it must be the latter.)
Glad you got it figured out!
PS - Not related to your problem, but FYI, width: on an input in a driver does not have any affect. This only applies to apps, where you have some control over the interface.