Bug 5777 - GRAM2 audting: database connection times out
: GRAM2 audting: database connection times out
Status: RESOLVED DUPLICATE of bug 6400
: GRAM
general
: 4.0.5
: Open Science Grid (OSG) Linux
: P3 blocker
: 4.0.7
Assigned To:
:
:
:
:
  Show dependency treegraph
 
Reported: 2008-01-11 14:13 by
Modified: 2009-03-19 09:48 (History)


Attachments


Note

You need to log in before you can comment on or make changes to this bug.


Description From 2008-01-11 14:13:58
Database: MySql 4.1.22

In GRAM4, after a period of inactivity (i.e., no service/job requests), it
appears the database connection times out.  I have not pinned down the
exact length of time before the connection is lost. In this one instance, it
was from 16:00 one afternoon to 08:00 the next morning.

The GRAM auditing was working at 16:00.

At 08:00 I submitted the following job:
  globusrun-ws -submit -F gratiax31.fnal.gov:9443 -Ft Condor -c /usr/bin/whoami

The job ran successfully.
The log messages with 'org.globus.exec.util.audit=DEBUG' set in the log4j file,
the same log messages appeared as when the database was updated successfully
the
night before. However, the there are no additional records in the database
gram_audit_table table for the job just run.

There are no error messages in the MySql logs.

When I do a 'show processlist' in mysql, I see only the rft connection and
my client connection.

mysql> show processlist;
+------+------+-----------------+---------------+---------+------+-------+------------------+
| Id   | User | Host            | db            | Command | Time | State | Info
            |
+------+------+-----------------+---------------+---------+------+-------+------------------+
| 1730 | rft  | localhost:50645 | rft_database  | Sleep   |    0 |       | NULL
            |
| 1862 | root | localhost       | auditDatabase | Query   |    0 | NULL  | show
processlist |
+------+------+-----------------+---------------+---------+------+-------+------------------+


If I restart the container, the connection is not immediately made 
(which is not necessarily a problem).

When the first job/service is requested (same globusrun-ws as shown above),
the connection is made and kept open for some period. The account the container
runs as is 'globus' below.  The database is updated with the audit information
for that job.

mysql> show processlist;
+------+--------+-----------------+---------------+---------+------+-------+------------------+
| Id   | User   | Host            | db            | Command | Time | State |
Info             |
+------+--------+-----------------+---------------+---------+------+-------+------------------+
| 1862 | root   | localhost       | auditDatabase | Query   |    0 | NULL  |
show processlist |
| 1866 | rft    | localhost:58323 | rft_database  | Sleep   |   18 |       |
NULL             |
| 1867 | globus | localhost:37386 | auditDatabase | Sleep   |  840 |       |
NULL             |
+------+--------+-----------------+---------------+---------+------+-------+------------------+

An item to note: As I manually ran the mysql 'show processlist' command, I
noticed that the rft user 'pinged' the database at 60 second intervals to keep
the connection open.   The 'Time' would always reset to zero after 59 while the
'Command' stayed at 'Sleep'.

Another item to note: there is not message in the log indicating the update
was unsuccessful.  Or successful for that matter.
------- Comment #1 From 2008-02-12 10:21:11 -------
*** Bug 5863 has been marked as a duplicate of this bug. ***
------- Comment #2 From 2009-03-19 09:48:31 -------

*** This bug has been marked as a duplicate of bug 6400 ***