-
Notifications
You must be signed in to change notification settings - Fork 304
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
HPCC-30917 Avoid core when eclagent terminates due to span destruction #18084
Conversation
Signed-off-by: Gavin Halliday <[email protected]>
https://track.hpccsystems.com/browse/HPCC-30917 |
@@ -377,18 +377,24 @@ int CEspHttpServer::processRequest() | |||
|
|||
checkSetCORSAllowOrigin(thebinding, m_request, m_response); | |||
|
|||
if (thebinding!=NULL) | |||
if (thebinding && thebinding->isUnrestrictedSSType(stype)) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Moved this earlier so that the span could be created whether or not thebinding is set.
//which would remove the activeSpan when this function exits, use | ||
//setActiveSpan() | ||
//It is possible that using EspContextSpanScope would be better | ||
Owned<ISpan> serverSpan = m_request->createServerSpan(); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I changed this to create the span, but not set it in the context because there was no clean way to restore the span, and the HttpRequest class is used in other contexts than esp. For the moment I have left it using setActiveSpan, but it can now be changed to restore at the end of the function.
The correct behaviour may well be tied in with the behaviour of txsummary.
@rpastrana this is a blocker for tagging 9.4.14 gold, so please review. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@ghalliday - 2 minor comments, but looks good to merge.
|
||
// A variant of the class above that allows startSpan to be called after construction | ||
template <class CONTEXT> | ||
class DynamicContextSpanScopeImp |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I get why different, but I'd have probably combined into ContextSpanScopeImp, i.e. separate ctor etc.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes. I could revisit, but probably not for this PR.
//setActiveSpan() | ||
//It is possible that using EspContextSpanScope would be better | ||
Owned<ISpan> serverSpan = m_request->createServerSpan(); | ||
ctx->setActiveSpan(serverSpan); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Not necessary to remove the span for reasons commented,
but if it were coded to use scoped object, it would need less explanation and be more intuitive I think.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@ghalliday this seems like a suitable solution.
However it seems ContextSpanScopeImp is a function of IContextLogger rather than jtrace.
Also, even though there's scattered code comments, it feels like this needs a dedicated README entry to fully articulate the use cases.
Type of change:
Checklist:
Smoketest:
Testing: