Posted by
Brett on
URL: http://ofbiz.116.s1.nabble.com/Users-JOB-SANDBOX-tp137182p137207.html
Andrew,
Sorry I didn't respond sooner, but it has been a while since we worked
on the problems with the job_sandbox. Our system admin currently runs
the SQL archival commands manually when the job_sandbox gets too big.
The community has responded with some good solutions for manually
removing records from the job_sandbox. Here are some things we look
for:
1. Records that have a status_id="SERVICE_FINISHED" are easy to
remove. We usually remove this if they are a month old.
2. Records that have a status_id="SERVICE_RUNNING" but the
start_date_time is very old. These services were probably killed
during a shutdown or something else and have no chance of completing.
For example:
delete from job_sandbox where status_id='SERVICE_RUNNING' and
start_date_time < '2005-12-31';
3. Change services that frequently fail to have a max-retry. We
currently use a max-retry 3 but some may want a higher threshold. As
I mentioned, most of our services that fail are E-mail notifications
and if they fail once they usually always fail.
4. Automated service: We don't have an automated service right now
but there is an example of an automated service in ofbiz. You could
use it as an example of how to create "autoDeleteJobSandboxServices"
services.
In the order/data/OrderScheduledServices.xml the
"autoCancelOrderItems" is scheduled to run each day. This service is
then defined in the order/servicedef/services.xml file and is
implemented in the
org.ofbiz.order.order.OrderServices.cancelFlaggedSalesOrders.java
file. The service doesn't do a delete but you could write a similar
service that does deletes in the job_sandbox entity per your own
specifications.
If you have more specific questions let me know.
Brett
On 2/2/06, Andrew Dupa <
[hidden email]> wrote:
> 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
> > > guess about what records to delete, if someone can give me a definitive
> > > 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>
>
_______________________________________________
Users mailing list
[hidden email]
http://lists.ofbiz.org/mailman/listinfo/users