P.S. I forgot to mention that editing the redirect page again fixed some
data in SMW (no more property values stored) but it still did not set
the redirect marker set in smw_object_ids did not store the redirect in
smw_fpt_redi. I did not test if this update might have stopped the
cycle, but I
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
Thanks for the info James. I guess caching introduces a whole new dimension.
Cheers
Neill.
On 25/09/14 14:41, James HK wrote:
> Hi,
>
>> 1) What does "as of 1.9.2" mean exactly? Is this a change of behaviour
>> from older versions?
> By the time of the writing (which included SMW 1.9.2 therefore
Hi,
> 1) What does "as of 1.9.2" mean exactly? Is this a change of behaviour
> from older versions?
By the time of the writing (which included SMW 1.9.2 therefore "as of"
and all previous versions) SMW does not support a "real" auto update
mechanism for queries and with "real" auto update we thin
Hi.
Following [0] led me to this:
http://semantic-mediawiki.org/wiki/Automatic_query_update which states:
Currently Semantic MediaWiki (as of 1.9.2) does not support a "real"
auto update (aka "smart" queries) that would refresh the results of
pages that include the query results.
I want to ach
Hi,
A short summary of the current discussion. I further recommend to read
[0] which tries to explain as to when the `UpdateJob` is triggered.
Krabina Bernhard:
Using SMW 1.8.0.5 / MW 1.22 with "Suddenly, without anybody knowing
why, ~ 5000 have been done, but > 7000 are still sitting there ", "
Hi Bernhard.
Perhaps you are seeing the same issue as me. I have this logged on github:
https://github.com/SemanticMediaWiki/SemanticMediaWiki/issues/518#issuecomment-54269008
Please let me know if you think your issue may be the same as mine.
Best regards
Neill.
On 25/09/14 12:02, Krabina Bern
our problem is not only that we cannot get the hanging jobs to run, but that
even new jobs being created (by changing a template or CSV import with data
transfer) will not run
regards,
Bernhard
- Ursprüngliche Mail -
> I had the same issue a while ago after I restored a database.
>
I had the same issue a while ago after I restored a database.
I figured it was because when I ran the backup there where jobs in the queue
and after the restore they kept running over and over and etc.
I ran another backup from my production database after I cleared the runjobs,
and this worked
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
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
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 s
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
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
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,
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 th
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
17 matches
Mail list logo
