> Thanks - that's great brett. I knew someone would get it. Thanks your reply
> is exactly what I was after.
>
> Couple more questions.
>
> On the 1st point do you by chance still have the SQL to manually delete
> these jobs records as part of your regular achive stratergy? If your
> solution worked I'd like to use that than roll my own.
>
> Also I'm interested in setting up the custom service to delete these old
> records. Are you able to provide some detailed instructions as to how to do
> this? It would help greatly if you provided some pointers.
>
> Thanks,
> Andrew
>
>
> On 2/2/06, Brett Palmer <
[hidden email]> wrote:
> >
> > Andrew,
> >
> > See comments below:
> >
> > On 2/1/06, Andrew Dupa <
[hidden email]> wrote:
> > > I'll stick to the facts -
> > >
> > > 1st problem
> > > Webtools admin screen around scheduled jobs doesn not work due to the
> large
> > > amount of data in the database. to get around this probem how I would
> like
> > > to delete the old un-used records. i would like to understand or hear
> form
> > > someone who has this problem before how to best go about it. I don't
> want to
> > > answer than great.
> > >
> >
> > Yes, we have seen the same problem on our production boxes when the
> > job_sandbox table is large. This is a limitation in the
> > implementation that should be fixed. We have worked around it by
> > creating custom services to remove failed jobs. We have also manually
> > deleted these records through the database as part of our regular
> > archival strategy. I agree that these are not the best solutions, but
> > fixing the webtools application has not been a priority for us.
> >
> > > 2nd problem
> > > I have scheduled jobs that are failing but are reschedlued to run later,
> > > they have no hope of runing sucessfully so I would like to
> > > cancel/stop/delete them. again I can't do this thru the admin screen in
> > > webtools because it doens't work (because there's a lot of records in
> the
> > > database) if someone could tell me how to stop the scheduled jobs, i.e.
> not
> > > stop important ones but just the ones i identify as problem jobs I would
> > > appreciate that. remember the admin tools provided don't work because of
> the
> > > large amount of data in the database. So I can log in to the databse and
> do
> > > it thru SQL if someone can describe the data model or what to look for.
> > >
> >
> > We aso had problems with failed services continually retrying. For
> > example, email notifications that had an incorrect E-mail address
> > would continually attempt to send and fail. Services by default run
> > forever. We changed these services to have a max-retry of 3. This
> > prevented the run-away condition we saw with failed services that had
> > no chance of correcting themselves. Here is a sample service
> > definition with the max-retry set:
> >
> > <service name="someService" engine="java"
> > location="SomeService"
> invoke="sendEmailNotification"
> > use-transaction="false"
> require-new-transaction="false"
> > max-retry="3">
> > <attribute name="sendTo" type="String" mode="IN" optional="false"/>
> > <attribute name="sendFrom" type="String" mode="IN"
> optional="false"/>
> > <attribute name="sendBcc" type="String" mode="IN" optional="true"/>
> > <attribute name="subject" type="String" mode="IN" optional="false"
> />
> > </service>
> >
> >
> > Hope that sounds somewhat intelligent.
> >
> >
> > Brett
> >
> > _______________________________________________
> > Users mailing list
> >
[hidden email]> >
http://lists.ofbiz.org/mailman/listinfo/users> >
>
>
>
> _______________________________________________
> Users mailing list
>
[hidden email]>
http://lists.ofbiz.org/mailman/listinfo/users>
>