When I run tests in Play 2.6.x that are using the WsTestClient like:
WsTestClient.withClient { client => ...
I see in the logs:
[info] p.a.t.WsTestClient$SingletonWSClient - createNewClient: name = ws-test-client-1
Which I believe is coming from this line
Why is it logging as Info if it's set at log-level warn? Can I silence the noise somehow?
Related
There's an oft-asked question about changing the HTTP port to which a Play application will bind. James Ward's answer is generally accepted as the most complete, but it involves overriding the default by setting a http.port system property. However, is it possible to change this default without having to manually add it to the run command at development time, tweak the environment, or package an override in a runtime configuration?
This can be accomplished by setting the playDefaultPort key, as follows:
import PlayKeys._
playDefaultPort := 9123
Afterwards, you'll be able to run and testProd without needing to remember the desired port.
This works in both development:
$ sbt run
[info] Loading project definition from /Users/michaelahlers/Projects/MyApp/project
[info] Set current project to MyApp (in build file:/Users/michaelahlers/Projects/MyApp/)
--- (Running the application, auto-reloading is enabled) ---
[info] p.c.s.NettyServer - Listening for HTTP on /0:0:0:0:0:0:0:0:9123
(Server started, use Ctrl+D to stop and go back to the console...)
And production modes:
$ sbt testProd
[info] Loading project definition from /Users/michaelahlers/Projects/MyApp/project
[info] Set current project to MyApp (in build file:/Users/michaelahlers/Projects/MyApp/)
[info] Packaging /Users/michaelahlers/Projects/MyApp/target/scala-2.11/MyApp_2.11-1.0.0-SNAPSHOT-web-assets.jar ...
[info] Done packaging.
(Starting server. Type Ctrl+D to exit logs, the server will remain in background)
2016-04-08 13:09:45,594 [info] a.e.s.Slf4jLogger - Slf4jLogger started
2016-04-08 13:09:45,655 [info] play.api.Play - Application started (Prod)
2016-04-08 13:09:45,767 [info] p.c.s.NettyServer - Listening for HTTP on /0:0:0:0:0:0:0:0:9123
I am starting out with ReactiveMongo, and while log level is set to debug
I see the following print to the log:
application - ReactiveMongoApi starting...
reactivemongo.api.MongoDriver - No mongo-async-driver configuration found
application - ReactiveMongoApi successfully configured with DB 'mydb'! Servers:
[mongodb:27017]
The question is: Do I have anything to be concerened about with that no async driver found? and why is it beeing printed.
The ReactiveMongo package is looking for some configuration. it doesn't mean that the driver operation will not be async because no configuration was found.
To get rid of the error, you can add configuration in the application.conf
Example:
mongo-async-driver {
akka {
loggers = [ "akka.event.slf4j.Slf4jLogger" ]
loglevel = DEBUG
}
}
I want to start using actors with heavy rate messages . actor's last state is very important
I was following the persistence example shown at here http://doc.akka.io/docs/akka/2.3.9/scala/persistence.html#event-sourcing
I tried to send a heavy load of messages
for (i <-0 to 100000){
persistentActor ! Cmd("foo"+i)
}
and using the persistAsync like this
val receiveCommand: Receive = {
case Cmd(data) =>
persistAsync(Evt(s"${data}-${numEvents}"))(updateState)
case "snap" => saveSnapshot(state)
case "print" => println(state)
}
before shutdown I added Thread.sleep(150000) to make sure that all persists . at first all seems to be ok , however re-running the app shows that some are going to dead-letter
> [INFO] [02/03/2015 15:35:18.187]
> [example-akka.actor.default-dispatcher-3]
> [akka://example/user/persistentActor-4-scala] Message
> [java.lang.String] from Actor[akka://example/deadLetters] to
> Actor[akka://example/user/persistentActor-4-scala#1206460640] was not
> delivered. [1] dead letters encountered. This logging can be turned
> off or adjusted with configuration settings 'akka.log-dead-letters'
> and 'akka.log-dead-letters-during-shutdown'. [INFO] [02/03/2015
> 15:35:18.192] [example-akka.actor.default-dispatcher-3]
> [akka://example/user/persistentActor-4-scala] Message
> [akka.persistence.Recover] from
> Actor[akka://example/user/persistentActor-4-scala#1206460640] to
> Actor[akka://example/user/persistentActor-4-scala#1206460640] was not
> delivered. [2] dead letters encountered. This logging can be turned
> off or adjusted with configuration settings 'akka.log-dead-letters'
> and 'akka.log-dead-letters-during-shutdown'.
or getting something like :
----------
[INFO] [02/03/2015 15:54:32.732] [example-akka.actor.default-dispatcher-11] [akka://example/user/persistentActor-4-scala] Message [akka.persistence.JournalProtocol$ReplayedMessage] from Actor[akka://example/deadLetters] to Actor[akka://example/user/persistentActor-4-scala#-973984210] was not delivered. [1] dead letters encountered. This logging can be turned off or adjusted with configuration settings 'akka.log-dead-letters' and 'akka.log-dead-letters-during-shutdown'.
[INFO] [02/03/2015 15:54:32.735] [example-akka.actor.default-dispatcher-3] [akka://example/user/persistentActor-4-scala] Message [akka.persistence.JournalProtocol$ReplayedMessage] from Actor[akka://example/deadLetters] to Actor[akka://example/user/persistentActor-4-scala#-973984210] was not delivered. [10] dead letters encountered, no more dead letters will be logged. This logging can be turned off or adjusted with configuration settings 'akka.log-dead-letters' and 'akka.log-dead-letters-during-shutdown'.
A fatal error has been detected by the Java Runtime Environment:
SIGSEGV (0xb) at pc=0x00007fa2a3e06b6a, pid=18870, tid=140335801857792
JRE version: Java(TM) SE Runtime Environment (7.0_71-b14) (build 1.7.0_71-b14)
Java VM: Java HotSpot(TM) 64-Bit Server VM (24.71-b01 mixed mode linux-amd64 compressed oops)
Problematic frame:
V [libjvm.so+0x97bb6a] Unsafe_GetNativeByte+0xaa
Failed to write core dump. Core dumps have been disabled. To enable core dumping, try "ulimit -c unlimited" before starting Java again
An error report file with more information is saved as:
/home/tadmin/projects/akka-sample-persistence-scala/hs_err_pid18870.log
If you would like to submit a bug report, please visit:
http://bugreport.sun.com/bugreport/crash.jsp
========================================================================
how can I persist a state of an actor that should handle heavy rate of messages ?
I suspect that the default database, levelDB, is the problem, and is most certainly what is core dumping. Are you by any chance writing to the db with more than one actor concurrently? In my experience, I've seen it core dump in that scenario. You could try it in shared mode, but I just plugged in a different database and the problems went away. In my case I used Cassandra.
I would try an in-memory journal plugin for akka-persistence. It is very easy to swap in. If the problems go away, then you know that levelDB is the problem. If so, go with a different database.
Trying to use sbt with
Keys.fork := true
With this option all messages from slf4j logger shown as error-message
It looks like
[error] 0 [main] INFO test - Test
Without fork it looks like
1 [run-main] INFO test - Test
sbt version: 0.13
This is documented at http://www.scala-sbt.org/0.13.2/docs/Detailed-Topics/Forking.html , in the “Configuring output” section:
By default, forked output is sent to the Logger, with standard output logged at the Info level and standard error at the Error level. This can be configured with the outputStrategy setting,
I have a class with a custom logger. Here's a trivial example:
package models
import play.Logger
object AModel {
val log = Logger.of("amodel")
def aMethod() {
if (! log.isInfoEnabled) log.error("Can't log info...")
log.info("Logging aMethod in AModel")
}
}
and then we'll enable this logger in application.conf:
logger.amodel=DEBUG
and in development (Play console, use run) this logger does indeed log. But in production, once we hit the message
[info] play - Application started (Prod)
loggers defined like the above logger fail to log any further and instead we go through the error branch. It seems their log level has been changed to ERROR.
Is there anyway to correct this undesirable state of affairs? Is there special configuration for production logs?
edit
Play's handling of logs in production is a source of difficulty to more than a few people... https://github.com/playframework/playframework/issues/1186
For some reason it ships its own logger.xml which overrides application.conf.