Mailing List Archive

Cron <perlwww@daedalus> /home/perlwww/apache.org/modperl-docs/bin/site_build_index
----------------------------------------
File: /x1/home/perlwww/apache.org/modperl-docs/src/docs/2.0/user/handlers/handlers.pod
unterminated 'C<' starting at <input text> line 1068

---------------------------------------------------------------------
To unsubscribe, e-mail: docs-dev-unsubscribe@perl.apache.org
For additional commands, e-mail: docs-dev-help@perl.apache.org
Re: Cron <perlwww@daedalus> /home/perlwww/apache.org/modperl-docs/bin/site_build_index [ In reply to ]
Bill Moseley wrote:
> On 24 Feb 2003, Cron Daemon wrote:
>
>
>>err: Couldn't open the property file "index.swish-e.prop.temp": No
>>such file or directory .
>
>
> I wonder why this is reported every once in a while. Swish is reopening
> that .prop file in read mode for faster access on the last pass of
> indexing.

You should know better ;)

> But, that error should abort the indexing, yet the index looks like it was
> created.
>
> -rw-rw-r-- 1 perlwww perl 1441405 Feb 24 06:43 index.swish-e.prop
> -rw-rw-r-- 1 perlwww perl 4777362 Feb 24 06:43 index.swish-e

The cron runs several times a day, so may be it was successful on the next build.

> When swish indexes it writes to .temp files, then at the very end renames
> the files removing the .temp suffix.
>
>
> void DB_Reopen_PropertiesForRead_Native(void *db)
> {
> struct Handle_DBNative *DB = (struct Handle_DBNative *) db;
> int no_rename = 0;
> char *s = estrdup(DB->cur_prop_file);
>
> /* Close property file */
> DB_Close_File_Native(&DB->prop, &DB->cur_prop_file, &no_rename);
>
>
> if (!(DB->prop = openIndexFILEForRead(s)))
> progerrno("Couldn't open the property file \"%s\": ", s);
>
> DB->cur_prop_file = s;
> }
>
> progerrno() calls exit.

so, why the error?



__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com


---------------------------------------------------------------------
To unsubscribe, e-mail: docs-dev-unsubscribe@perl.apache.org
For additional commands, e-mail: docs-dev-help@perl.apache.org
Re: Cron <perlwww@daedalus> /home/perlwww/apache.org/modperl-docs/bin/site_build_index [ In reply to ]
Bill Moseley wrote:
> On 24 Feb 2003, Cron Daemon wrote:
>
>
>>err: Couldn't open the property file "index.swish-e.prop.temp": No
>>such file or directory .
>
>
> I wonder why this is reported every once in a while. Swish is reopening
> that .prop file in read mode for faster access on the last pass of
> indexing.

You should know better ;)

> But, that error should abort the indexing, yet the index looks like it was
> created.
>
> -rw-rw-r-- 1 perlwww perl 1441405 Feb 24 06:43 index.swish-e.prop
> -rw-rw-r-- 1 perlwww perl 4777362 Feb 24 06:43 index.swish-e

The cron runs several times a day, so may be it was successful on the next build.

> When swish indexes it writes to .temp files, then at the very end renames
> the files removing the .temp suffix.
>
>
> void DB_Reopen_PropertiesForRead_Native(void *db)
> {
> struct Handle_DBNative *DB = (struct Handle_DBNative *) db;
> int no_rename = 0;
> char *s = estrdup(DB->cur_prop_file);
>
> /* Close property file */
> DB_Close_File_Native(&DB->prop, &DB->cur_prop_file, &no_rename);
>
>
> if (!(DB->prop = openIndexFILEForRead(s)))
> progerrno("Couldn't open the property file \"%s\": ", s);
>
> DB->cur_prop_file = s;
> }
>
> progerrno() calls exit.

so, why the error?



__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com


---------------------------------------------------------------------
To unsubscribe, e-mail: docs-dev-unsubscribe@perl.apache.org
For additional commands, e-mail: docs-dev-help@perl.apache.org
Re: Cron <perlwww@daedalus> /home/perlwww/apache.org/modperl-docs/bin/site_build_index [ In reply to ]
On Tue, 25 Feb 2003, Stas Bekman wrote:

> > -rw-rw-r-- 1 perlwww perl 1441405 Feb 24 06:43 index.swish-e.prop
> > -rw-rw-r-- 1 perlwww perl 4777362 Feb 24 06:43 index.swish-e
>
> The cron runs several times a day, so may be it was successful on the next build.

The error message has this as a date:

Date: 24 Feb 2003 14:43:26 -0000

so it seems like the same run.

>
> > When swish indexes it writes to .temp files, then at the very end renames
> > the files removing the .temp suffix.
> >
> >
> > void DB_Reopen_PropertiesForRead_Native(void *db)
> > {
> > struct Handle_DBNative *DB = (struct Handle_DBNative *) db;
> > int no_rename = 0;
> > char *s = estrdup(DB->cur_prop_file);
> >
> > /* Close property file */
> > DB_Close_File_Native(&DB->prop, &DB->cur_prop_file, &no_rename);
> >
> >
> > if (!(DB->prop = openIndexFILEForRead(s)))
> > progerrno("Couldn't open the property file \"%s\": ", s);
> >
> > DB->cur_prop_file = s;
> > }
> >
> > progerrno() calls exit.
>
> so, why the error?

The error said

err: Couldn't open the property file "index.swish-e.prop.temp": No such file or directory

so it doesn't really make sense. Get an abort message at 14:43, but
there's index files created at 14:43 anyway. Happen only once in a while.
Any chance that there's two cron entries? Seems very unlikely, but only
thing I can think of.

--
Bill Moseley moseley@hank.org



---------------------------------------------------------------------
To unsubscribe, e-mail: docs-dev-unsubscribe@perl.apache.org
For additional commands, e-mail: docs-dev-help@perl.apache.org
Re: Cron <perlwww@daedalus> /home/perlwww/apache.org/modperl-docs/bin/site_build_index [ In reply to ]
Bill Moseley wrote:
> The error said
>
> err: Couldn't open the property file "index.swish-e.prop.temp": No such file or directory
>
> so it doesn't really make sense. Get an abort message at 14:43, but
> there's index files created at 14:43 anyway. Happen only once in a while.
> Any chance that there's two cron entries? Seems very unlikely, but only
> thing I can think of.

I doubt that there are run away jobs, as the crons run every 6 hours. I guess
we could add a locking mechanism, but it may cause more damage than help.

__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com


---------------------------------------------------------------------
To unsubscribe, e-mail: docs-dev-unsubscribe@perl.apache.org
For additional commands, e-mail: docs-dev-help@perl.apache.org
Re: Cron <perlwww@daedalus> /home/perlwww/apache.org/modperl-docs/bin/site_build_index [ In reply to ]
Bill Moseley wrote:
> On Wed, 9 Apr 2003, Stas Bekman wrote:
>
>
>>Cron Daemon wrote:
>>
>>>Magic number checking on storable file failed at blib/lib/Storable.pm (autosplit into blib/lib/auto/Storable/_retrieve.al) line 315, at /x1/home/perlwww/apache.org/modperl-docs/bin/../lib/DocSet/Cache.pm line 51
>>
>>probably a corrupted storable object. I've rebuilt all the cache files from
>>scratch. Also updated Storable while I was at it. Hopefully the problem is
>>resolved now.
>
>
> Is that something that can be trapped and force a cache purge?

So far I was doing a manual purge:
find apache.org/modperl-docs -name "cache*dat" | xargs rm

but you are right that this can be done by docset automatically. I'm going to
try the following patch, so when bin/build -f is used the cache files are
nuked. This should solve the problem with Storable binary incompatibility.

+++ lib/DocSet/Cache.pm 2003/04/09 04:38:43
@@ -11,7 +11,7 @@
my %attrs = map {$_ => 1} qw(toc meta order child_cache_path);

sub new {
- my($class, $path, $update) = @_;
+ my($class, $path, $update, $purge) = @_;

die "no cache path specified" unless defined $path;

@@ -19,9 +19,15 @@
path => $path,
dirty => 0,
}, ref($class)||$class;
- $self->read();

- if ($update) {
+ if ($purge) {
+ $self->purge();
+ }
+ else {
+ $self->read();
+ }
+
+ if ($purge || update) {
# we will reconstruct the ids order to make sure to reflect the
# changes in added and removed items (and those who have changed
# their order)
@@ -43,6 +49,13 @@
$self->{path};
}

+sub purge {
+ if (-e $self->{path}) {
+ note "!!! Removing cache file $self->{path}";
+ unlink $self->{path};
+ }
+}
+
sub read {
my($self) = @_;

@@ -102,10 +115,6 @@
return $self->{cache}{$id}{$attr};
}
}
-
-
-
-

# check whether a cached entry exists
sub is_cached {
Index: lib/DocSet/DocSet.pm
===================================================================
RCS file: /home/stas/cvs/modules/DocSet/lib/DocSet/DocSet.pm,v
retrieving revision 1.25
diff -u -r1.25 DocSet.pm
--- lib/DocSet/DocSet.pm 2002/11/14 17:35:02 1.25
+++ lib/DocSet/DocSet.pm 2003/04/09 04:38:43
@@ -68,11 +68,18 @@
$self->rebuild(1);
}

+ my $purge = 0;
+
# rebuild forces all objects to be rebuilt
- $self->rebuild(1) if DocSet::RunTime::get_opts('rebuild_all');
+ if DocSet::RunTime::get_opts('rebuild_all') {
+ $self->rebuild(1);
+ $purge = 1;
+ }

# create the new cache object for updates
- my $cache = DocSet::Cache->new($cache_file, 1);
+ my $update = 1;
+
+ my $cache = DocSet::Cache->new($cache_file, $update, $purge);
$self->cache($cache); # store away

# cleanup the cache or rebuild

__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com


---------------------------------------------------------------------
To unsubscribe, e-mail: docs-dev-unsubscribe@perl.apache.org
For additional commands, e-mail: docs-dev-help@perl.apache.org
Re: Cron <perlwww@daedalus> /home/perlwww/apache.org/modperl-docs/bin/site_build_index [ In reply to ]
Looks like Brian has updated Storable:

Brian Behlendorf wrote:
> On Tue, 8 Apr 2003, Rodent of Unusual Size wrote:
>
>>bugger.. well, HTML::Entities can do it -- except the version on
>>the asf machines is tres ancient. would some rootish person be
>>kind enough to cpan up the latest version of that module?
>
>
> I've updated the p5-HTML-Parser port to 3.27 on both icarus and daedalus,
> I think that updated HTML::Entities.

> Bill Moseley wrote:
>
>> On Wed, 9 Apr 2003, Stas Bekman wrote:
>>
>>
>>> Cron Daemon wrote:
>>>
>>>> Magic number checking on storable file failed at
>>>> blib/lib/Storable.pm (autosplit into
>>>> blib/lib/auto/Storable/_retrieve.al) line 315, at
>>>> /x1/home/perlwww/apache.org/modperl-docs/bin/../lib/DocSet/Cache.pm
>>>> line 51
>>>
>>>
>>> probably a corrupted storable object. I've rebuilt all the cache
>>> files from scratch. Also updated Storable while I was at it.
>>> Hopefully the problem is resolved now.
>>
>>
>>
>> Is that something that can be trapped and force a cache purge?

Ah, I haven't addressed this one. I'll try to have this feature working asap.

__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com


---------------------------------------------------------------------
To unsubscribe, e-mail: docs-dev-unsubscribe@perl.apache.org
For additional commands, e-mail: docs-dev-help@perl.apache.org