Hi again,
I have isolated a single specimen of an infinite job cycle on my wiki.
The details are attached (I hope the attachment makes it to the list as
well). In short, the loop is triggered by an update job on a redirect
page. For some reason, the update job creates another instance of a new
update job of the same page.
The SMW tables do not contain correct information about the redirect
page: it has data stored about itself and is not marked as a redirect. I
do not know if this is the cause of the problem or a side effect.
However, since the page was stored with a #REDIRECT on it, this regular
storing of the data should already have created correct data -- this
should not depend on any update job.
The file also contains a sample of a job queue that I had at first,
where one of the indestructible jobs has two more copies of itself. They
were never modified during my tests, but this might explain why a job
queue can get longer and longer in such a case (new job instances,
whereever they come from, are protected by their indestructible copies).
The wrong SMW data might be the deeper issue here, but in any case it
should be able to make the UpdateJob execution robust against this kind
of cycle to address the main problem. Maybe the UpdateJob would (if
successful) actually fix the data, though it can hardly be its cause.
Regards,
Markus
On 25.09.2014 00:02, James HK wrote:
Hi,
I have executed runJobs several times and the job_attempts remains at 1 for
those five jobs. We were thinking of doing a database backup today, then
I'm curious about the "job_attempts" field as I would have expected to
see an increment for when the job (actually there has been an attempt
to execute and not only display a line on command shell) and to see
whether the job actually gets execute when running `runJobs`, just add
a simple `var_dump( 'hello world' )` line to [0] and verify a
`SMW\UpdateJob` activity.
[0]
https://github.com/SemanticMediaWiki/SemanticMediaWiki/blob/master/includes/src/MediaWiki/Jobs/UpdateJob.php#L118
Cheers
On 9/25/14, Daren Welsh <darenwe...@gmail.com> wrote:
I have executed runJobs several times and the job_attempts remains at 1 for
those five jobs. We were thinking of doing a database backup today, then
delete those five jobs from the table, then run the SMW "repair and
upgrade" via the admin special page.
Even if this clears the job queue, we'd like to understand what caused this
in the first place. I realize that's a very open-ended question :)
Daren
On Wed, Sep 24, 2014 at 4:30 PM, James HK <jamesin.hongkon...@gmail.com>
wrote:
Hi,
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.
Just to make sure that I interpret the meaning of "stuck" correctly,
after finishing `runJobs` those four jobs (five with the
`refreshLinks` jobs) are still visible in the job table with an
"job_attempts" of 1. When running `runJobs` again the same four
`SMW\UpdateJob` (same as in the same title and same Id) jobs are
executed and increment the "job_attempts" to 2?
If you empty the job table and execute `runJobs` does the same five
jobs appear again after the run with "job_attempts" = 1?
Cheers
On 9/25/14, Daren Welsh <darenwe...@gmail.com> wrote:
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
--
__________________
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
I'll show what happens with the job table on each job execution. The two pages
involved are:
* Forschungsgruppen (regular page)
* Forschungsfelder (redirect to "Forschungsgruppen")
The redirect was created by overwriting an existing page and placing a redirect
there (no
move). There seems to be a problem with this redirect (I print relevant SMW
table data below)
but let me first show you what happens with the jobs.
== Symptoms ==
Initial contents of job table (should be readable if your window is wide
enough):
+--------+---------------+---------------+-------------------+----------------+------------+------------+--------------+-----------+---------------------+---------------------------------+
| job_id | job_cmd | job_namespace | job_title | job_timestamp |
job_params | job_random | job_attempts | job_token | job_token_timestamp |
job_sha1 |
+--------+---------------+---------------+-------------------+----------------+------------+------------+--------------+-----------+---------------------+---------------------------------+
| 20362 | SMW\UpdateJob | 0 | Forschungsfelder | 20141013085404 |
| 737028253 | 0 | | NULL |
jf2ywb2bzwnkom3u204paku40vzn4o3 |
| 20363 | SMW\UpdateJob | 0 | Forschungsgruppen | 20141013085404 |
| 1094089627 | 0 | | NULL |
fhsokbevxk0fbtj1255y2oz7ddehefi |
+--------+---------------+---------------+-------------------+----------------+------------+------------+--------------+-----------+---------------------+---------------------------------+
2 rows in set (0.01 sec)
$ php showJobs.php
2
$ php runJobs.php --maxjobs=1
2014-10-13 08:57:01 SMW\UpdateJob Forschungsgruppen STARTING
2014-10-13 08:57:01 SMW\UpdateJob Forschungsgruppen t=217 good
+--------+---------------+---------------+------------------+----------------+------------+------------+--------------+-----------+---------------------+---------------------------------+
| job_id | job_cmd | job_namespace | job_title | job_timestamp |
job_params | job_random | job_attempts | job_token | job_token_timestamp |
job_sha1 |
+--------+---------------+---------------+------------------+----------------+------------+------------+--------------+-----------+---------------------+---------------------------------+
| 20362 | SMW\UpdateJob | 0 | Forschungsfelder | 20141013085404 |
| 737028253 | 0 | | NULL |
jf2ywb2bzwnkom3u204paku40vzn4o3 |
+--------+---------------+---------------+------------------+----------------+------------+------------+--------------+-----------+---------------------+---------------------------------+
1 row in set (0.00 sec)
$ php showJobs.php
1
$ php runJobs.php --maxjobs=1
2014-10-13 08:57:43 SMW\UpdateJob Forschungsfelder STARTING
2014-10-13 08:57:43 SMW\UpdateJob Forschungsfelder t=95 good
+--------+---------------+---------------+-------------------+----------------+------------+------------+--------------+-----------+---------------------+---------------------------------+
| job_id | job_cmd | job_namespace | job_title | job_timestamp |
job_params | job_random | job_attempts | job_token | job_token_timestamp |
job_sha1 |
+--------+---------------+---------------+-------------------+----------------+------------+------------+--------------+-----------+---------------------+---------------------------------+
| 20364 | SMW\UpdateJob | 0 | Forschungsfelder | 20141013085743 |
| 988344474 | 0 | | NULL |
jf2ywb2bzwnkom3u204paku40vzn4o3 |
| 20365 | SMW\UpdateJob | 0 | Forschungsgruppen | 20141013085743 |
| 456885984 | 0 | | NULL |
fhsokbevxk0fbtj1255y2oz7ddehefi |
+--------+---------------+---------------+-------------------+----------------+------------+------------+--------------+-----------+---------------------+---------------------------------+
2 rows in set (0.00 sec)
$ php showJobs.php
2
$ php runJobs.php --maxjobs=1
2014-10-13 08:58:28 SMW\UpdateJob Forschungsgruppen STARTING
2014-10-13 08:58:29 SMW\UpdateJob Forschungsgruppen t=213 good
+--------+---------------+---------------+------------------+----------------+------------+------------+--------------+-----------+---------------------+---------------------------------+
| job_id | job_cmd | job_namespace | job_title | job_timestamp |
job_params | job_random | job_attempts | job_token | job_token_timestamp |
job_sha1 |
+--------+---------------+---------------+------------------+----------------+------------+------------+--------------+-----------+---------------------+---------------------------------+
| 20364 | SMW\UpdateJob | 0 | Forschungsfelder | 20141013085743 |
| 988344474 | 0 | | NULL |
jf2ywb2bzwnkom3u204paku40vzn4o3 |
+--------+---------------+---------------+------------------+----------------+------------+------------+--------------+-----------+---------------------+---------------------------------+
1 row in set (0.00 sec)
$ php showJobs.php
1
$ php runJobs.php --maxjobs=1
2014-10-13 08:59:01 SMW\UpdateJob Forschungsfelder STARTING
2014-10-13 08:59:01 SMW\UpdateJob Forschungsfelder t=100 good
+--------+---------------+---------------+-------------------+----------------+------------+------------+--------------+-----------+---------------------+---------------------------------+
| job_id | job_cmd | job_namespace | job_title | job_timestamp |
job_params | job_random | job_attempts | job_token | job_token_timestamp |
job_sha1 |
+--------+---------------+---------------+-------------------+----------------+------------+------------+--------------+-----------+---------------------+---------------------------------+
| 20366 | SMW\UpdateJob | 0 | Forschungsfelder | 20141013085901 |
| 200458240 | 0 | | NULL |
jf2ywb2bzwnkom3u204paku40vzn4o3 |
| 20367 | SMW\UpdateJob | 0 | Forschungsgruppen | 20141013085901 |
| 773946695 | 0 | | NULL |
fhsokbevxk0fbtj1255y2oz7ddehefi |
+--------+---------------+---------------+-------------------+----------------+------------+------------+--------------+-----------+---------------------+---------------------------------+
2 rows in set (0.00 sec)
And so on, to infinity.
== Further information ==
The relevant SMW id entries are as follows:
SELECT * FROM smw_object_ids WHERE smw_title="Forschungsfelder" LIMIT 10;
+--------+---------------+------------------+--------+----------------------------------------+------------------+-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
| smw_id | smw_namespace | smw_title | smw_iw | smw_subobject
| smw_sortkey | smw_proptable_hash
|
+--------+---------------+------------------+--------+----------------------------------------+------------------+-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
| 5887 | 0 | Forschungsfelder | |
| Forschungsfelder |
a:3:{s:11:"smw_fpt_ask";s:32:"1e67b057cd84815a9497ae8cc92fc132";s:12:"smw_fpt_inst";s:32:"20a41f683ced86a179c61dc746830003";s:12:"smw_fpt_mdat";s:32:"8284c03d3e8f0d0875fa2088db418d8a";}
|
| 5888 | 0 | Forschungsfelder | |
_QUERYd3dfee93de67f5e3af73fe30a24ff2a2 | Forschungsfelder | a:0:{}
|
+--------+---------------+------------------+--------+----------------------------------------+------------------+-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
2 rows in set (0.00 sec)
This is wrong. It should be a redirect but it has data. I can actually see the
data in Special:Browse, too.
Special:Browse also claims that there is a Category ("Seiten mit defekten
Dateilinks", the German version of the
SMW category for pages with problems in their property values). MediaWiki does
not show the page for this
category, but the smw_inst table contains the link.
There is no redirect data in smw_fpt_redi:
SELECT * FROM smw_fpt_redi WHERE s_title="Forschungsfelder" LIMIT 10;
Empty set (0.00 sec)
The SMW id entry for the regular page looks normal:
SELECT * FROM smw_object_ids WHERE smw_title="Forschungsgruppen" LIMIT 10;
+--------+---------------+-------------------+--------+----------------------------------------+-------------------+------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
| smw_id | smw_namespace | smw_title | smw_iw | smw_subobject
| smw_sortkey | smw_proptable_hash
|
+--------+---------------+-------------------+--------+----------------------------------------+-------------------+------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
| 1216 | 0 | Forschungsgruppen | |
| Forschungsgruppen |
a:2:{s:11:"smw_fpt_ask";s:32:"68313f0b2fe239b40cb9ec8ad322ae1c";s:12:"smw_fpt_mdat";s:32:"fb751d1d106331611e2ea3493dd55c92";}
|
| 8904 | 0 | Forschungsgruppen | |
_QUERY41ffdaf6bcccbcec8bf72f001ae8d503 | Forschungsgruppen |
a:4:{s:13:"smw_fpt_askde";s:32:"2d83699a944ee776da00fa953e22c651";s:13:"smw_fpt_asksi";s:32:"998f80c8c4942791ce7b81efbd1a4774";s:13:"smw_fpt_askfo";s:32:"ca744abe6401612dffa18850596aa241";s:13:"smw_fpt_askst";s:32:"da6c8617685193bb5e23d2c044fa3ef2";}
|
| 1217 | 0 | Forschungsgruppen | |
_QUERYd3dfee93de67f5e3af73fe30a24ff2a2 | Forschungsgruppen |
a:4:{s:13:"smw_fpt_askde";s:32:"24c274b41347ab9ea7f950d1c9bbe1ce";s:13:"smw_fpt_asksi";s:32:"c392385de652ecaf526206683356c279";s:13:"smw_fpt_askfo";s:32:"9beee60c4ca1752172d4fdbe45455a20";s:13:"smw_fpt_askst";s:32:"8c50632ff3e835b6be76ba30964deb4b";}
|
+--------+---------------+-------------------+--------+----------------------------------------+-------------------+------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
3 rows in set (0.00 sec)
SELECT * FROM smw_fpt_redi WHERE s_title="Forschungsgruppen" LIMIT 10;
Empty set (0.00 sec)
== Related case ==
Before I isolated this single job, I had a job table that showed duplicates.
Maybe it was just a coincidence or maybe
this issue is likely to arise in a cycle situation. If this continues, this
could be the reason for some of the very long
job queues that are reported.
+--------+---------------+---------------+---------------------+----------------+------------+------------+--------------+----------------------------------+---------------------+---------------------------------+
| job_id | job_cmd | job_namespace | job_title | job_timestamp
| job_params | job_random | job_attempts | job_token |
job_token_timestamp | job_sha1 |
+--------+---------------+---------------+---------------------+----------------+------------+------------+--------------+----------------------------------+---------------------+---------------------------------+
| 20317 | SMW\UpdateJob | 0 | Forschungsfelder/en | 20141013082615
| | 1069246779 | 1 | 9b9c6763d7d262c12e9748a512be838f |
20141013082615 | as8c01macq676or7yd181t1ozpga3tp |
| 20346 | SMW\UpdateJob | 0 | Forschungsfelder | 20141013082633
| | 1575847892 | 0 | |
NULL | jf2ywb2bzwnkom3u204paku40vzn4o3 |
| 20350 | SMW\UpdateJob | 0 | Forschungsfelder/en | 20141013082633
| | 1781265401 | 1 | b851e9dbb1117ca415551e4a0f0d2682 |
20141013082633 | as8c01macq676or7yd181t1ozpga3tp |
| 20352 | SMW\UpdateJob | 0 | Forschungsfelder/en | 20141013083633
| | 2130514466 | 0 | |
NULL | as8c01macq676or7yd181t1ozpga3tp |
+--------+---------------+---------------+---------------------+----------------+------------+------------+--------------+----------------------------------+---------------------+---------------------------------+
4 rows in set (0.00 sec)
In this case, too, I was not able to get below these 4 rows. The table cycled
between 4 and 6 (since there are two duplicate causing jobs now),
but never went above 6 in my tests either. In fact, the two copies that have a
non-empty job token were never used/changed at all.
------------------------------------------------------------------------------
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://p.sf.net/sfu/Zoho
_______________________________________________
Semediawiki-devel mailing list
Semediawiki-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/semediawiki-devel
