Bug #17457

Message fields not being filled in

Added by Eric Flumerfelt over 3 years ago. Updated over 3 years ago.

Target version:
Start date:
Due date:
% Done:


Estimated time:
8.00 h
Spent time:


I'm using MessageFacility v2_00_02, and trying to debug its interaction with the Message Facility Viewer in mf-extensions. I have noticed that the following fields are not being filled in messages from artdaq:


From what I can tell, these were filled in in the file, which has been removed from the repository (most likely due to code restructuring). The find . -type f|xargs grep -i setHostname command shows that the setters for these fields are still defined, but never called:

[eflumerf@ironwork messagefacility]$ find . type f|xargs grep -i setHostname
./Utilities/ mf::ErrorObj::setHostName(std::string const& hostname)
./Utilities/ myXid.setHostname(hostname);
./Utilities/ void MessageFacilityMsg::setHostname(std::string const& hostname)
./Utilities/ ep
./Utilities/ELextendedID.h: void setHostname(std::string const & hostname);
./Utilities/ELextendedID.h:mf::ELextendedID::setHostname(std::string const & hostname)
./Utilities/ErrorObj.h: virtual void setHostName ( const std::string & hostname );
./Utilities/MessageFacilityMsg.h: void setHostname (std::string const& hostname);

[eflumerf@ironwork messagefacility]$ find . type f|xargs grep -i setHostname
./MessageService/ a
./MessageService/ if ( updateHostName ) msg.setHostName ( a->hostname() );
./MessageService/ if ( updateHostName ) msg.setHostName ( "" );
./Utilities/ void ErrorObj::setHostName(std::string const& hostname)
./Utilities/ void MessageFacilityMsg::setHostname(std::string const& hostname)
./Utilities/ ep->setHostName(hostname);
./Utilities/ErrorObj.h: virtual void setHostName ( const std::string & hostname );
./Utilities/MessageFacilityMsg.h: void setHostname (std::string const& hostname);

Please advise.

Associated revisions

Revision f459abc6 (diff)
Added by Chris Green over 3 years ago

Fix and regression test for issue #17457.


#1 Updated by Christopher Green over 3 years ago

  • Tracker changed from Bug to Support
  • Status changed from New to Feedback
  • Assignee set to Christopher Green

Hi Eric,

I'm pretty sure this was discussed as part of our meeting and associated correspondence back in March: it was explained (I think) that ErrorLog was just convenience functions for a likely set of calls to the context updating routines, which, as you note, still exist. I seem to remember, although my memory is very sketchy at the best of times, that the advice was to put calls to the individual context update routines where you need them -- I don't even think ErrorLog is something you want to appropriate for yourselves (although that would be perfectly fine).

These four items you mention are only useful in an inter-process / inter-node context, and as such we believe it is appropriate for artdaq code to set the context where appropriate.

If you have trouble working out where to plug in the appropriate calls, or there are other issues, we'd be happy to get together and discuss them. I'll put the issue into feedback mode to facilitate that; otherwise, please let us know how you proceeded so we can resolve the ticket.

#2 Updated by Kyle Knoepfel over 3 years ago

  • Tracker changed from Support to Bug
  • Status changed from Feedback to Assigned
  • Estimated time set to 8.00 h

We will add interface to allow you to set this information.

#3 Updated by Christopher Green over 3 years ago

  • Status changed from Assigned to Resolved

#4 Updated by Christopher Green over 3 years ago

  • Target version set to 2.09.00

Resolved with commit f459abc.

The default application name, hostname, hostaddr and pid have been restored to the message.

In addition to mf::MessageLoggerQ::setApplication(), one may now invoke mf::MessageLoggerQ::setHostName(), mf::MessageLoggerQ::setHostAddr() or mf::MessageLoggerQ::setPID() anytime after the call to StartMessageFacility (e.g. the constructor of any destination).

N.B.: if the application (or anyone else) calls any of the above functions directly or indirectly (like the free function mf::SetApplicationName, for exampele), then calls from a destination's constructor will be overridden as these happen as a result of the call to StartMessageFacility(). To avoid this, your application should call StartMessageFacility with an optional second std::string argument indicating the initial application name. Art relies on the default setting of the application name, so this should not be an issue.

See the test code at source:messagefacility/test/Integration/ for an example of calling these functions from a destination's constructor, although since the old defaults are now set and honored once more this may not be necessary for you.

Note also that any of the items in an xid may be overridden in the destination on a per-message basis if you require.

#5 Updated by Christopher Green over 3 years ago

  • % Done changed from 0 to 100

#6 Updated by Kyle Knoepfel over 3 years ago

  • Status changed from Resolved to Closed

Also available in: Atom PDF