| Steve's Networked Programming Newsletter
|
Making Nets Work
July
2008
|
|
Dear Steve,
Thank you for subscribing to my newsletter. This
month I have a helpful article about how to use a custom
logging back end in ACE.
My May newsletter asked for your thoughts on ACE vs.
asio. A number of people took time to share some
insightful things with me, and I review these as
well.
As always, be sure to forward this note to other
people you work with to be sure they know what's
happening in the world of networked application
development.
|
How to Create a Custom Logging Back
End for ACE
|
ACE's logging features
(described in APG and in
back issues
of this newsletter) allow you to do a wide variety of
things such as filter on severity, redirect output to
various sinks, log over the network, etc. But logging is
an area that is just never complete enough for
everyone's needs and wishes. Some things I've been asked
for advice on are:
- Storing log records in a database
- Converting log records to XML for storage or
transmission
- Redirecting some severities to one file and other
severities to another file
There always
seems to be a new place to direct output to, or a
special format to log with that just isn't possible with
the "out of the box" ACE logging features. Sometimes you
just need to roll your own.
APG describes the ACE
logging callback facility, but that's a per-object
(usually per thread) facility, and it's a pain to use
logging callbacks when you really want all of a
process's logging to be handled in a special way.
Fortunately, ACE provides just the hook you need to
adapt ACE's logging features to your requirements: a
custom logging back end. It's not terribly hard to
create a logging back end, but the process for doing so
hasn't been documented in one place before. Here are the
steps needed to implement and use a custom logging back
end in ACE:
- Derive a class from ACE_Log_Msg_Backend. There are four
virtual methods your new class must implement: open(),
close(),
reset(),
and log().
See the reference page for ACE_Log_Msg_Backend for complete
details.
- Specify a pointer to an object of your new back
end's class to ACE_Log_Msg.
- Open ACE_Log_Msg specifying CUSTOM as one of the
flags values.
Easy! Here are a few more
details.
-
At program start time, call ACE_Log_Msg::msg_backend()
to specify a pointer to an object of your new class.
The object must remain valid until after it is removed
from ACE_Log_Msg, typically at program shutdown.
-
When calling ACE_Log_Msg::open(),
add ACE_Log_Msg::CUSTOM
to the flags value passed to ACE_Log_Msg::open().
-
Your back end class's open()
method will be called from ACE_Log_Msg::open().
The logger_key
parameter will be passed to your open()
method. You can use this to specify some run-time
information. Your open()
method should return 0 for success. If it returns -1,
it will not be used for any logging.
- For each log operation at run-time, your class's
log()
method will be called. An ACE_Log_Record object will be passed.
It contains a completely formatted logging record. The
output string as well as priority, etc., are available
in order to handle any special needs.
There is
an example of using a custom logging back end in the ACE
source kit. Check out the
ACE_wrappers/tests/Log_Msg_Backend_Test.cpp
file.
Are there any other things you've wondered
how to do with ACE? I'd love to hear about it. I'll use
your ideas and questions in future newsletter articles
and gratefully acknowledge your
contribution.
|
| Feedback from May's Article About
ACE and Boost asio |
May's
newsletter article about ACE and Boost
asio generated some insightful comments from
readers. I think these comments are representative of
what I've heard while working with and talking to other
developers as well.
Garth Lancaster, Manager:
EDI/Automation Support at MBF Australia Limited, agreed
that it's important to choose the right tool for the
job. Although "... what you can achieve with ICE, asio,
RCF etc you can achieve with ACE, because ACE really is
the lowest level most comprehensive framework" it isn't
always best to try. As Garth said, "it comes down to a
few factors, right tool, good design, time vs $$/buy vs
build, familiarity with each of the offerings,
flexibility etc."
Use the best tool. So where
does ACE fit in MBF Australia's work? Garth summed it up
as "I don't think it's by coincidence that our solution
and the solution being used by one of our major trading
partners uses ACE for high-speed realtime messaging - I
still think ACE is a reasonable knowledge investment,
and am yet to see a 100% replacement for
it."
Yauheni Akhotnikau, Chief Developer at
Intervale, echoed another sentiment that sets ACE apart
as a useful tool for many projects and teams: it's
understandable and useful for those of us mere mortals
who have a difficult time following many layers of
template assembly when trying to debug code. Yauheni put
it as many developers I work with would: "So I see Boost
as a good sandbox for future standard C++ libraries
(like those in TR1). But I prefer to use old good ACE
for my production code. Because ACE is mature with
very-very rich functionality, has rather good
documentation, has big community and ACE is
understandable."
|
| Do You Need Help Designing Your
Next System? |
Nobody has to tell you that
designing a well-formed, efficient, maintainable
networked application is hard. You've had to deal with
it. The problem is that networking functionality is
usually in a supporting role to your system's main
purposes, and your skills and experience are much better
used to focus on specific business and technology
issues. It may make more sense to bring in seasoned
expertise to help design a solid networking base in your
next system.
I've helped many companies get great
networked applications built - I may be able to help you
as well. Let's talk and see if I can help take care of
the networking, and let you focus on applying your
expertise and experience to the business features
that'll really help your system stand out.
Call
me at 508-541-9180 or email me at shuston@riverace.com.
| |
|
| |
