One feature that would help to prevent this problem in the future is a
configuration parameter in the service engine that would set the maximum
number of jobs the poller would process at a time. Right now the poller
reads the JobSandbox and gets every job that has a status of Pending. Then
it
I find that anything not time based does not work when, like you said
the numbers get large.
I added the createtime to the conditions currently set in the milliseconds.
Brett Palmer sent the following on 7/14/2011 5:35 AM:
One feature that would help to prevent this problem in the future is a
I should add that the environment also has a lot to o with this.
In this area I have changed to Solid State Drives for Storage and 32gb
SDHC for Swap files.
BJ Freeman sent the following on 7/14/2011 8:09 AM:
I find that anything not time based does not work when, like you said
the numbers
the key is Transaction timeout
this could be the job length
could be the database connection
please specify the version of ofbiz since earlier transaction problems
were taken care of by changing code that deals with transactions.
Josh Jacobson sent the following on 7/13/2011 11:48 AM:
Hello
Josh,
I've also seen this problem if the JobSandbox table has too many rows to
process. I ran into a similar problem when I tried to run 10,000 Async
batch processes. The time it took for the JobPoller to process all the
records was too long and the transaction would time out.
I had a patch to
BJ,
I am running 10.04.
On Wed, Jul 13, 2011 at 12:00 PM, BJ Freeman bjf...@free-man.net wrote:
the key is Transaction timeout
this could be the job length
could be the database connection
please specify the version of ofbiz since earlier transaction problems
were taken care of by
Brett,
Can you please explain what you mean by archiving the current JobSandbox first?
Do you mean somehow removing the current pending jobs, applying you
patch and the copying them back again?
Thanks,
On Wed, Jul 13, 2011 at 12:08 PM, Brett Palmer brettgpal...@gmail.com wrote:
Josh,
I've
Ok so you have the latest code.
what is the eviorment you working with.
OS
Memory
CPU speed
Josh Jacobson sent the following on 7/13/2011 12:12 PM:
BJ,
I am running 10.04.
On Wed, Jul 13, 2011 at 12:00 PM, BJ Freeman bjf...@free-man.net wrote:
the key is Transaction timeout
this could
I meant removing finished jobs. If you have thousands of pending jobs then
you will have the same problem I mentioned in my first email. One
resolution will be to increase the job poller transaction time. In the
ofbiz version I was using there was not a way to configure the poller
transaction
Currently I am running:
Red Hat Enterprise Linux Server release 5.5
6 CPUs, 16384MB RAM
It was very recently upgraded from 2 CPUs and 8GB of RAM because we
were having performance issues (lots of swap memory being used). It's
on one of those cloud servers. Now it's running without using any
On Wed, Jul 13, 2011 at 12:31 PM, Brett Palmer brettgpal...@gmail.com wrote:
I meant removing finished jobs. If you have thousands of pending jobs then
you will have the same problem I mentioned in my first email. One
resolution will be to increase the job poller transaction time. In the
On Wed, Jul 13, 2011 at 12:51 PM, Josh Jacobson
josh.s.jacob...@gmail.com wrote:
On Wed, Jul 13, 2011 at 12:31 PM, Brett Palmer brettgpal...@gmail.com wrote:
I meant removing finished jobs. If you have thousands of pending jobs then
you will have the same problem I mentioned in my first email.
You now know why I don't recommend cloud configuration for realtime
operations, unless your running over dedicate lines not part of the
internet.
to summarize you environment caused the problem not ofbiz
Now you have jobs cued that should have been run but have piled up.
you need a way to get the
Thanks for the pointers. I'll take a look.
There is one more piece of information: The purgeOldJobs service is in
a crashed status. Do you think that is significant?
Thanks,
On Wed, Jul 13, 2011 at 4:32 PM, BJ Freeman bjf...@free-man.net wrote:
You now know why I don't recommend cloud
it means it will not purge job done so you will get a build up
you can do a run service to start it again
Josh Jacobson sent the following on 7/13/2011 4:41 PM:
Thanks for the pointers. I'll take a look.
There is one more piece of information: The purgeOldJobs service is in
a crashed
Thanks, that is what I figured. First things first though: I need to
get those jobs running somehow.
Thanks for the help.
On Wed, Jul 13, 2011 at 4:46 PM, BJ Freeman bjf...@free-man.net wrote:
it means it will not purge job done so you will get a build up
you can do a run service to start it
Brett,
Before I start trying to run the jobs manually, I want to give your
suggestion a try. I think I know where to configure the job polling
transaction time (I believe it's the poll-db-millis=2 value on
the framework/service/config/serviceengine.xml.
However, I still don't know what to
That configuration is for the frequency of job polls. There isn't any ability
to specify the transaction timeout via configuration so you'll need to modify
the code directly:
JobManager.java (line 148):
beganTransaction = TransactionUtil.begin();
needs to be changed to use
Scott,
Thanks! That is very precise advise. Do you have a suggestion on
interval time? 60 seconds? 120?
Thanks,
On Wed, Jul 13, 2011 at 5:34 PM, Scott Gray scott.g...@hotwaxmedia.com wrote:
That configuration is for the frequency of job polls. There isn't any
ability to specify the
As best I can tell there shouldn't be any need to increase the interval between
polls since the interval timer doesn't actually start until the previous poll
has completed (see JobPoller.run()) so I can't see how a small interval would
cause any backlog problems.
I'm guessing if there is any
Thanks again. I actually meant a suggestion for the transaction
timeout. In any case I am grateful for your explanation.
On Wednesday, July 13, 2011, Scott Gray scott.g...@hotwaxmedia.com wrote:
As best I can tell there shouldn't be any need to increase the interval
between polls since the
Ah okay, that is entirely dependent on the number of jobs and the speed the
server can process them. As a side note I would keep a close eye on the
purgeOldJobs service, when it starts falling over (transaction timeout again)
then the number of rows in the table will increase quickly which in
Josh,
I'm attaching the patch I used to work around this issue. This is based on
an older version of ofbiz so I would compare your current files carefully.
The following files were patched:
service-config.xsd
serviceengine.xml
JobManager.java
JobPoller.java
The patch allowed for a new
I tried 60 seconds for timeout but that didn't work. I guess Ill
double it now and keep trying.
I have about 260,000 pending jobs, and nothing is getting done.
I know what you mean about purgeOldjobs. That service is crashed now
and I deleted old jobs from the database by hand. I was up to 2.6
Not sure what db you're using but it probably wouldn't hurt to run a vacuum on
the table to speed up processing.
By the way, I'm pretty sure the default timeout is 60 seconds so you might want
to try something a little larger :-)
Regards
Scott
On 14/07/2011, at 2:58 PM, Josh Jacobson wrote:
Vacuum has been run, (took quite a while). Yeah, I see now that the
JobManager actually tries to update all the JobSandbox rows in the
transaction, so 60 seconds was pretty low.
I am trying 10 minutes now and see how that goes.
I am using postgress by the way.
Thanks for the help, I really
you going to run into this from time to time or one reason or another.
the approach I took was to spread the jobs out so they are not lumped
together.
take a look at how the jobs are Marshalled to be run.
Josh Jacobson sent the following on 7/13/2011 8:35 PM:
Vacuum has been run, (took quite a
27 matches
Mail list logo
