Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Include Start/End time in logs for TPC transfer #1529

Closed
wants to merge 1 commit into from

Conversation

juztas
Copy link
Contributor

@juztas juztas commented Oct 6, 2021

@bbockelm
Copy link
Contributor

@abh3 - can I get you to provide advice on the best way to do timestamps here? The C code looks fine but I feel like there's some other wrapper around gettimeofday in the XRootD internal libraries already...

@abh3
Copy link
Member

abh3 commented Oct 15, 2021 via email

@abh3
Copy link
Member

abh3 commented Oct 26, 2021

In general, I am not in favor of putting this kind of detail in the log file (I think we already have a line with a timestamp when the transfer started and then another one when it ended). This (and the subsequent one) simply clutters the log file making even more difficult to find errors. In general, this kind of detail should be put into a HTTP-TPC specific monitoring stream (which the infrastructure can provide). While I will likely merge this, I think we really should open the discussion on how to move all of this (other failure messages) to a monitoring stream. Before I do merge, some of your thoughts on this as well, perhaps, Brian's would be appreciated.

@juztas
Copy link
Contributor Author

juztas commented Dec 8, 2021

@bbockelm Can you comment on this and can we get this finally merged, so it reaches 5.4 xrootd release?

@abh3 abh3 self-assigned this Jan 4, 2022
@@ -779,13 +786,16 @@ int TPCHandler::ProcessPullReq(const std::string &resource, XrdHttpExtReq &req)
}


void TPCHandler::logTransferEvent(LogMask mask, const TPCLogRecord &rec,
void TPCHandler::logTransferEvent(LogMask mask, TPCLogRecord &rec,
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Changing this to non-const is bad and actually winds up not solving anything. See my comment later.


connDone.tv_sec = 0; connDone.tv_usec = 0;
gettimeofday( &connDone, 0 );
rec.eTOD = connDone;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

No one uses eTOD outside of logging and it gets reset on every call. So, there is no reason to have it in TPCLogRecord and hence no need to make it non-const which is generally a bad idea. This is especially true because eTOD eally is misleading. This is actually the time the message was issued not when the request ended.

std::stringstream ss;
ss << "event=" << event << ", local=" << rec.local << ", remote=" << rec.remote;
ss << ", stTime=" << rec.sTOD.tv_sec << ", enTime=" << rec.eTOD.tv_sec;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

As per previous comment "enTime" is not really end time. It is merely the time the message was issued. So, I would suggest calling it what it really is.

@@ -53,6 +53,8 @@ private:
streams( 1 ),
bytes_transferred( -1 )
{
sTOD.tv_sec = 0; sTOD.tv_usec = 0;
eTOD.tv_sec = 0; eTOD.tv_usec = 0;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

As per my previous comments, sTOD makes sense but eTOD as it is being haled does not.

@abh3
Copy link
Member

abh3 commented Dec 16, 2022

OK, we have asked for changes and none were forthcoming to the point that we now have conflicts with the original pull request. I think we need to start over. So, I am closing this pull request.

@abh3 abh3 closed this Dec 16, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants