Job prioritization is committed in r1857071, thanks everyone who provided
their thoughts.
Regards
Scott
On Sat, 16 Mar 2019, 22:30 Scott Gray, wrote:
> Patch available at https://issues.apache.org/jira/browse/OFBIZ-10865
>
> Reviews welcome, I probably won't have time to commit it for a few
Patch available at https://issues.apache.org/jira/browse/OFBIZ-10865
Reviews welcome, I probably won't have time to commit it for a few weeks so
no rush.
By the way I was amazed to notice that jobs are limited to 100 jobs per
poll with a 30 second poll time, seems extremely conservative. They
+1
Jacques
Le 25/02/2019 à 21:15, Mathieu Lirzin a écrit :
Hello Scott,
Scott Gray writes:
I'm working on implementing the priority queue approach at the moment for a
client. All things going well it will be in production in a couple of
weeks and I'll report back then with a patch.
Hello Scott,
Scott Gray writes:
> I'm working on implementing the priority queue approach at the moment for a
> client. All things going well it will be in production in a couple of
> weeks and I'll report back then with a patch.
Sounds great!
--
Mathieu Lirzin
GPG: F2A3 8D7E EB2B 6640 5761
Hi Jacques,
I'm working on implementing the priority queue approach at the moment for a
client. All things going well it will be in production in a couple of
weeks and I'll report back then with a patch.
Regards
Scott
On Tue, 26 Feb 2019 at 03:11, Jacques Le Roux
wrote:
> Hi,
>
> I put this
Hi,
I put this comment there with OFBIZ-10002 trying to document why we have 5 as hardcoded value of /max-threads/ attribute in /thread-pool/ element
(serviceengine.xml). At this moment Scott already mentioned[1]:
/Honestly I think the topic is generic enough that OFBiz doesn't need to
Hello Scott,
On a customer project we use massively the job manager with an average
of one hundred thousand job per days.
We have different cases like, huge long jobs, async persistent job, fast
regular job. The mainly problem that we detect has been (as you
notified) the long jobs that
Hi Taher,
I say that it isn't a drop-in replacement solely because it is unbounded
whereas the current implementation appears to depend on the queue being
bounded by the number set in the serviceengine.xml thread-pool.jobs
attribute.
The main concern I have about an unbounded queue is the
On Wed, Jan 30, 2019 at 8:59 PM Scott Gray
wrote:
> [...]
2. The advice on the number of threads to use doesn't seem good to me, it
> assumes your jobs are CPU bound when in my experience they are more likely
> to be I/O bound while making db or external API calls, sending emails etc.
> [...]
Hi Scott,
It seems we have some issues currently with our job scheduler [1]
which seems to be some sort of memory leak. We are also experiencing
some performance issues and other anomalies. It seems like a good time
to perhaps revisit the whole thing.
Are you suggesting to replace
[1] https://issues.apache.org/jira/browse/OFBIZ-9233
-邮件原件-
发件人: Scott Gray [mailto:scott.g...@hotwaxsystems.com]
发送时间: 2019年1月31日 3:48
收件人: dev@ofbiz.apache.org
主题: JobManager/JobPoller issues
Hi folks,
Just jotting down some issues with the JobManager over noticed over the
last f
Hi folks,
Just jotting down some issues with the JobManager over noticed over the
last few days:
1. min-threads in serviceengine.xml is never exceeded unless the job count
in the queue exceeds 5000 (or whatever is configured). Is this not obvious
to anyone else? I don't think this was the
12 matches
Mail list logo
