[CLOSED] Establish logging policy in cases of error and propagation of actual exceptions

[akka-ci]

Issue by jrudolph
Thursday Aug 21, 2014 at 12:03 GMT
Originally opened as akka/akka#15714

---

E.g. in HttpManager we react differently on network errors caused by Http.Connect and Http.Bind commands:

• an error during Http.Connect is DEBUG-logged and then it's reported to the commander containing the remote address in question
• an error during Http.Bind is WARNING-logged and the singleton BindFailedException is reported to the commander

In both cases, neither the actual exception nor the message are reported back to the commander. This means it isn't possible for the commander to actually take responsibility for handling or reporting the error and thus it's easy to get into the old Java double logging anti-pattern.

I would propose a scheme where errors/exceptions are generally reported to the commander including the underlying message and if they are logged then only with DEBUG-level, to let the commander decide what to do with them.

It's probably not too useful to also send the stacktraces/original exceptions around, but there should be at least some way to log the stacktraces somewhere before they are discarded for debugging purposes.

/cc @sirthias

[akka-ci]

Comment by rkuhn
Wednesday Sep 17, 2014 at 09:11 GMT

---

We need to give the user full control over the logging: the library shall not log by itself but allow everything to be logged at the user level. The principal approach here is to publish flows of log events, one for the binding and one for each connection. A log event contains:

• timestamp
• source identifier (bound address and/or peer address)
• structured message (case classes for different occurrences)

We will need to write adapters to SLF4J and the usual suspects in order to identify whether structured messages need to derive from some common parent type.

[akka-ci]

Comment by sirthias
Friday Oct 03, 2014 at 11:49 GMT

---

/cc @sirthias

[akka-ci]

Comment by jrudolph
Wednesday Feb 11, 2015 at 16:06 GMT

---

Also, see the suggestions in #16842, spray/spray#243 and https://groups.google.com/forum/?fromgroups#!forum/spray-user:

• ERROR for unexpected internal conditions
• WARN for remote peer triggered errors

[akka-ci]

Comment by ktoso
Thursday Sep 08, 2016 at 14:53 GMT

---

Ticket moved to github.com/akka/akka-http
Rationale for the move discussed here: akka/akka-meta#27
If you are interested in contributing or tracking this issue, please comment in akka-http instead from now on :-)