We currently have five jobs that are "stuck". All of them have 1 for
job_attempts.
One has job_cmd of refreshLinks in job namespace 10 and it is for a
template page.
The other four have job_cmd of SMW\UpdateJob in job namespace 0 and are for
"standard" pages. These pages do not seem to be related based on category
or template.
On Wed, Sep 24, 2014 at 3:37 PM, James HK <jamesin.hongkon...@gmail.com>
wrote:
> Hi,
>
> > runJobs.php will literally run forever. After the non-offending jobs are
> > cleared it's easy to see which are the offenders. Thus far I think all
> > offenders have been of type SMW::UpdateJob.
>
> I don't think the problem is with the `SMW\UpdateJob` because it does
> a simple "shallow update" of the store while the management of job
> status (including how many attempts, id's etc.) are done by the MW
> JobQueue (which has first change in 1.22 and then again in 1.23).
>
> It does beg the question whether all `SMW\UpdateJob`'s are "stuck" or
> only certain jobs belonging to a group of pages or single page?
>
> > runJobs.php, but for some reason they keep attempting to run over and
> over.
>
> How do you know that the same job is run over and over again because
> based and above discussion ("job_attempts") a job with too many
> attempts is retired after some time.
>
> If the same job is run over and over again, what is displayed for the
> "job_attempts" counter?
>
> [0] went into SMW 2.0 to counteract any possible job duplicates for
> the same `root title`.
>
> [0] https://github.com/SemanticMediaWiki/SemanticMediaWiki/pull/307
>
> Cheers
>
> On 9/25/14, James Montalvo <jamesmontal...@gmail.com> wrote:
> > I'm not sure if this is related, but on my wiki I'm occasionally getting
> > "stuck" jobs. I've only noticed this since upgrading to MW 1.23 and SMW
> 2.0
> > from 1.22/1.8.0.5.
> >
> > What I mean by "stuck" is that the jobs don't get executed when I do
> > runJobs.php, but for some reason they keep attempting to run over and
> over.
> > runJobs.php will literally run forever. After the non-offending jobs are
> > cleared it's easy to see which are the offenders. Thus far I think all
> > offenders have been of type SMW::UpdateJob.
> >
> > Is there some way to debug runJobs.php so I can provide better info?
> >
> > --James
> > On Sep 24, 2014 10:55 AM, "Yaron Koren" <ya...@wikiworks.com> wrote:
> >
> >> I certainly hope so too - or that there's some other standard way to get
> >> previously-attempted jobs to be run again. I only know that I tried that
> >> SQL trick once, and it worked. Perhaps this is another reason why the
> >> question should have instead been sent to the mediawiki-l mailing list.
> >> :)
> >>
> >> On Wed, Sep 24, 2014 at 11:35 AM, James HK <
> jamesin.hongkon...@gmail.com>
> >> wrote:
> >>
> >> > Hi,
> >> >
> >> > > column is greater than 0 for all the rows in the table; I think if
> >> > > you
> >> > just
> >> > > go into the database and call something like "UPDATE job SET
> >> > job_attempts =
> >> > > 0", they will get run again.
> >> >
> >> > In case this solves the issue, I sincerely hope there is a different
> >> > way (a more standard way) to reset the "job_attempts" field other than
> >> > by using a SQL statement to manipulate the job table.
> >> >
> >> > Cheers
> >> >
> >> > On 9/25/14, Yaron Koren <ya...@wikiworks.com> wrote:
> >> > > Hi,
> >> > >
> >> > > I believe the issue is the "job_attempts" field in the "job" table.
> I
> >> > > believe each job is only attempted a certain number of times before
> >> > > MediaWiki basically just gives up and ignores it. My guess is that
> >> > > that
> >> > > column is greater than 0 for all the rows in the table; I think if
> >> > > you
> >> > just
> >> > > go into the database and call something like "UPDATE job SET
> >> > job_attempts =
> >> > > 0", they will get run again.
> >> > >
> >> > > -Yaron
> >> > >
> >> >
> >>
> >>
> >>
> >> --
> >> WikiWorks · MediaWiki Consulting · http://wikiworks.com
> >>
> >>
> ------------------------------------------------------------------------------
> >> Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer
> >> Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports
> >> Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper
> >> Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer
> >>
> >>
> http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk
> >> _______________________________________________
> >> Semediawiki-user mailing list
> >> semediawiki-u...@lists.sourceforge.net
> >> https://lists.sourceforge.net/lists/listinfo/semediawiki-user
> >>
> >
>
>
> ------------------------------------------------------------------------------
> Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer
> Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports
> Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper
> Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer
>
> http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk
> _______________________________________________
> Semediawiki-devel mailing list
> Semediawiki-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/semediawiki-devel
>
--
__________________
http://mixcloud.com/darenwelsh
http://www.beatportfolio.com
------------------------------------------------------------------------------
Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer
Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports
Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper
Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer
http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk
_______________________________________________
Semediawiki-devel mailing list
Semediawiki-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/semediawiki-devel
