Project

General

Profile

Bug #5239

Difficulties configuring and viewing Metacat replication log file

Added by Duane Costa over 8 years ago.

Status:
New
Priority:
Normal
Assignee:
Category:
metacat
Target version:
Start date:
11/12/2010
Due date:
% Done:

0%

Estimated time:
Bugzilla-Id:
5239

Description

While working with Chad to restore replication between KNB and LTER, I encountered issues with configuring and viewing the replication log file. As detailed in the email exchanges below, I configured a replication log directory and file name in the following three places:

1. Metacat administrative interface, 'Metacat Properties Configuration' page:

Replication Log Directory  /home/tcat/local/metacat_data/metacat/logs
[The directory where replication log should be located.]

2. metacat.properties file

replication.logdir=/home/tcat/local/metacat_data/metacat/logs

3. log4j.properties file
log4j.appender.replication.File=/home/tcat/local/metacat_data/metacat/logs/metacatreplication.log

However, Metacat seems to ignore these configuration values and instead sends the output to the Tomcat log file, 'catalina.out'.


In an email to Chad Berkley on 2010-11-12, Duane Costa wrote:

Hi Chad,
.
.
.
There's still a problem with the replication log file. I configured it
exactly as described below, but the file has still not been touched since
4/26/2010. There is, however, a bunch of replication output in the Tomcat
catalina.out file. Apparently, Metacat is ignoring my configuration
settings and sending the output to the default location of catalina.out.
This is a fairly minor issue, but I'll open a Bugzilla bug report on it so
that it can be recorded.
Thanks,
Duane

In an email to Duane Costa on 2010-11-10, Chad Berkley wrote:

On 11/10/10 2:19 PM, Duane Costa wrote:

Ours is configured as follows:

log4j.appender.replication.File = ${replication.logfile.name}

On the other hand, the metacat.properties file has:

replication.logdir=/home/tcat/local/metacat_data/metacat/logs

And the Metacat administrative interface displays the following:

Replication Log Directory /home/tcat/local/metacat_data/metacat/logs
[The directory where replication log should be located.]

This raises a few questions. You don't have to try to answer them. I'm
just trying to point out that the current situation is confusing, and
hopefully this can be simplified in future versions of Metacat.

1. Do we configure a directory name or a file name? (A file name
according to the first setting; a directory name according to the next
two.)

I'm not sure of the original intent here. It would be nice if we just gave it a directory and all of the log files are just put there.

2. There used to be two different replication output files:
'metacatreplicationerror.log', 'metacatreplication.log'. Is there now
only one?

Again, not sure. Seems like there should really only be one.

3. If log4j.properties now controls where the replication output is
sent, are the other two settings no longer used by the system?

It's always controlled the output, I just think that there's something wrong with the token system that isn't updating the log4j file. I think there's a bug in the admin interface where it's not updating the log4j.properties file as well as the metacat.properties file. I think that token is supposed to be replaced by the actual path to the file.

4. Should '${replication.logfile.name}' in log4j.properties be manually
edited, or is 'replication.logfile.name' the name of a property that is
being set somewhere else? If the latter, where is it being controlled? I
don't see it in either build.properties or metacat.properties.

It's safe to manually edit it. I just did and it worked fine.

For now I will explicitly set the value in log4j.properties to the
following:

log4j.appender.replication.File=/home/tcat/local/metacat_data/metacat/logs/metacatreplication.log

Yep, that should work.

I'm seeing a bunchof files coming from lter now, unfortunately there are also a lot of errors, but I'm not sure if they're critical. Here's an example:

knb 20101110-14:42:45: [ERROR]: ReplicationHandler.handleSingleXMLDocument - Failed to write doc knb-lter-gce.113.11 into db because The file you are trying to write already exists in metacat. Please update your version number. [ReplicationLogging]

It might just be trying to get all of your files and using that exception to handle the "already exists" case, but I'm not exactly sure. Lets see if it mirrors correctly when it's done.

chad

Thanks,
Duane

On 11/10/2010 4:43 PM, Chad Berkley wrote:

Check your webapps/knb/WEB-INF/log4j.properties file. It should show
you where the output for replication is going. I've attached the
log4j.properties file from knb for reference. By default, all logs
will be sent to catalina.out in tomcat/logs. If you configure the
replication log, it will go to whatever file you configure
(/var/metacat/logs/metacatreplication.log in the attached file).

chad

History

#1 Updated by Redmine Admin about 6 years ago

Original Bugzilla ID was 5239

Also available in: Atom PDF