In the following document, event handlers are described as taking the place of logging http://akka.io/docs/akka/1.2/general/event-handler.html
There is an Event Handler which takes the place of a logging system in Akka:
akka.event.EventHandler
Specifically, this link provides an example of how to do this while using slf4j: http://akka.io/docs/akka/1.2/general/slf4j.html
My question is 'what advantages does this give? 'why would I do this instead of just using a logger using the standard pattern?'
import org.slf4j.Logger;
import org.slf4j.LoggerFactory;
...
private static Logger log = LoggerFactory.getLogger(MyActor.class);
...
log.info("doing something");
Is there some kind of underlying benefit I'd get, based on threading or dispatcher internals, by using an event-handler over the above logger pattern that I'm not seeing? If not, using an event-handler for logging feels like deviating from a familiar pattern for no clear reason.
Thanks for any input!
Logging generally means IO, which can slow down the operations of your code. In the context of an actor where each message must be processed single-file in your receive method, this overhead can, in some cases, make an order (or more) of magnitude difference in the time for that method to complete. It's already a common pattern within Erlang-based systems to move the logging outside of the flow of control of the thread (or process, in the Erlang sphere) that is running the receive block. If your actors are not heavily dependent on the timing of the receive block, you can always fall back to the standard logging pattern if that makes things easier for you, but it's probably a good idea to get used to the EventHandler-based approach.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With