[akka-user] system.scheduler.scheduleOnce consumes Heap over time
I thought there was something specific I was doing wrong in an application I have deployed in development, which eventually needs to be production ready. Over time, the Akka actor system slowly consumes all available memory. I assumed it was a memory leak that I introduced, but as it turns out, even the sample Typesafe hello-akka app demonstrates the same heap consumption. http://www.typesafe.com/activator/template/hello-akka If you let the sample application above run for a very long, the heap usage slowly grows, and is never released. Although, it is Very Slow Since it is set to send a message to the greeter only every 1 second, this isn't very apparent. I simplified the pattern I am using in an actual application, that demonstrates the same issue, but at an accelerated rate. This is modeled after the Scheduling Periodic Messages pattern described here: http://doc.akka.io/docs/akka/snapshot/scala/howto.html The full sample code to recreate the memory consumption, with heap usage logging is available at the gist below. (note: if you start with the hello-akka sample application, and replace HelloAkkaScala.scala with this gist below, you can reproduce. You will need to add to your build.sbt the following (as mentioned in the comments at the top of the gist) com.kenshoo %% metrics-play % 2.3.0_0.1.9 https://gist.github.com/jeffsteinmetz/bbccb4815858620ab5a2 You may need to let it run for about 1 to 2 minutes before you see the initial bump in heap usage. After that, you will see it slowly climb and never back down. Note - the metrics calls are not required, and do not cause the memory leak - you can watch system memory without this library and see the same issue. I've tried a few versions of Akka, with the same results. In production, a similar (real world) application eventually consumes all memory. Hoping for a little insight on the Akka internals, and potential solution. J -- Read the docs: http://akka.io/docs/ Check the FAQ: http://doc.akka.io/docs/akka/current/additional/faq.html Search the archives: https://groups.google.com/group/akka-user --- You received this message because you are subscribed to the Google Groups Akka User List group. To unsubscribe from this group and stop receiving emails from it, send an email to akka-user+unsubscr...@googlegroups.com. To post to this group, send email to akka-user@googlegroups.com. Visit this group at http://groups.google.com/group/akka-user. For more options, visit https://groups.google.com/d/optout.
Re: [akka-user] Re: About ⇒ operator
another side note; we don't use ⇒ in documentation, so if you find one there it is a bug and a pull request is welcome On Tue, May 12, 2015 at 7:34 AM, Martynas Mickevičius martynas.mickevic...@typesafe.com wrote: Hi Bill, ⇒ is treated by the scala compiler the same as =. Try the following in the scala repl: scala val myFunc = (x: Int) ⇒ x + 1 myFunc: Int = Int = function1 scala myFunc(1) res12: Int = 2 The scalariform sbt plugin that akka project uses converts = to ⇒ automatically before the code is compiled using sbt. PS. As a side note, please do not double post between akka-dev and akka-user. On Tue, May 12, 2015 at 8:02 AM, BillZhang jingege...@gmail.com wrote: e.g. https://github.com/akka/akka/blob/master/akka-actor/src/main/scala/akka/dispatch/Mailbox.scala#L143 On Tuesday, May 12, 2015 at 12:50:21 PM UTC+8, BillZhang wrote: I found ⇒ operator in akka's source. Why they don't use = instead? Where ⇒ defined? thx for ur answer! -- Read the docs: http://akka.io/docs/ Check the FAQ: http://doc.akka.io/docs/akka/current/additional/faq.html Search the archives: https://groups.google.com/group/akka-user --- You received this message because you are subscribed to the Google Groups Akka User List group. To unsubscribe from this group and stop receiving emails from it, send an email to akka-user+unsubscr...@googlegroups.com. To post to this group, send email to akka-user@googlegroups.com. Visit this group at http://groups.google.com/group/akka-user. For more options, visit https://groups.google.com/d/optout. -- Martynas Mickevičius Typesafe http://typesafe.com/ – Reactive http://www.reactivemanifesto.org/ Apps on the JVM -- Read the docs: http://akka.io/docs/ Check the FAQ: http://doc.akka.io/docs/akka/current/additional/faq.html Search the archives: https://groups.google.com/group/akka-user --- You received this message because you are subscribed to the Google Groups Akka User List group. To unsubscribe from this group and stop receiving emails from it, send an email to akka-user+unsubscr...@googlegroups.com. To post to this group, send email to akka-user@googlegroups.com. Visit this group at http://groups.google.com/group/akka-user. For more options, visit https://groups.google.com/d/optout. -- Patrik Nordwall Typesafe http://typesafe.com/ - Reactive apps on the JVM Twitter: @patriknw -- Read the docs: http://akka.io/docs/ Check the FAQ: http://doc.akka.io/docs/akka/current/additional/faq.html Search the archives: https://groups.google.com/group/akka-user --- You received this message because you are subscribed to the Google Groups Akka User List group. To unsubscribe from this group and stop receiving emails from it, send an email to akka-user+unsubscr...@googlegroups.com. To post to this group, send email to akka-user@googlegroups.com. Visit this group at http://groups.google.com/group/akka-user. For more options, visit https://groups.google.com/d/optout.
Re: [akka-user] Akka with org.apache.log4j.MDC
Thanks Nils, I am planning to use this approach now, but how do you keep
context between actors if you are using third party lib actors? I can't
modify them to include the context in their messages.
class RequestHandler() extends Actor with akka.actor.DiagnosticActorLogging{
override def mdc(currentMessage: Any): MDC = {
currentMessage match {
case req: TraitWithRequestId = Map(requestId - req.id)
case _ = Map()
}
}
def receive: Receive = {
case req: TypeA =//TypeA extends
TraitWithRequestId
log.debug(RECEIVE req typeA) //logged with
correct [requestId - someRandom]
val thirdPartyA = context.ActorOf(thirdPartyA.props)
thirdPartyA ! req
case thirdPartyResponse = //cant modify 3rd
party to extend TraitWithRequestId
log.debug(RECEIVE third party response)//no value [requestId
- ]
val actorA = context.ActorOf(ActorA.props)
val messageToActorA = (thirPartyResponse.param1, requestId)
actorA ! messageToActorA
}
}
On Friday, May 8, 2015 at 2:31:03 PM UTC+8, nil...@gmail.com wrote:
I have struggled a lot with the same challenge. The MDC feature of the
logging frameworks need a little more manual intervention when operating
in an asynchronous runtime like Akka. MDC is tightly coupled to a thread,
but communication with and between Actors happen in different threads.
Hence, the MDC is not propagated automatically when sending messages
between your actors. Basically, you need to pass the context you wish to
log along with the messages in your system. So if you want to trace a
requestId in a conversation between your actors, you need to pass the
requestId along in the message, and then put it back in the MDC in the
receiving actor.
Regards,
Nils-Helge Garli Hegvik
On Thursday, May 7, 2015 at 10:27:59 AM UTC+2, byse...@gmail.com wrote:
Hi √,
I want to have MDC logging so I can organize my logs, for example
according to requestId.
I am tried out the example in
http://doc.akka.io/docs/akka/2.3.10/scala/logging.html#MDC_values_defined_by_the_application
.
It works fine for a single actor, but If I'm sending a message to
another Actor, the MDC values are not log on the other Actors.
class RequestHandler() extends Actor with
akka.actor.DiagnosticActorLogging{
override def mdc(currentMessage: Any): MDC = {
currentMessage match {
case req: TypeA = Map(requestId - req.id)
case _ = Map()
}
}
def receive: Receive = {
case req: TypeA =
log.debug(RECEIVE req typeA) //logged with
correct [requestId - someRandom]
val actorA = context.ActorOf(ActorA.props)
actorA ! req //logs in actorA
are do not have value on requestId (how to log them?)
}
}
class ActorA() extends Actor with akka.actor.DiagnosticActorLogging
{...} //logs of helperActors called by ActorA are not also logged with
correct requestId (how to log them?)
Is it possible with AKKA MDC to log all codeLogs (including logs from
dependency libs) for a certain requestId with correct MDC map values?
I also set akka logger to sl4fj on my application.conf
akka {
loggers = [akka.event.slf4j.Slf4jLogger]
logging-filter = akka.event.slf4j.Slf4jLoggingFilter
On Monday, April 27, 2015 at 3:30:47 PM UTC+8, √ wrote:
Hi Anindita,
It would be great for us to know what is lacking in the MDC sections of
the Akka Logging documentation,
please don't hesitate to contribute.
Thanks!
On Mon, Apr 27, 2015 at 8:09 AM, Anindita Ghatak anindi...@gmail.com
wrote:
Hi,
How can I use Akka with org.apache.log4j.MDC ?
Thanks Regards,
Anindita
--
Read the docs: http://akka.io/docs/
Check the FAQ:
http://doc.akka.io/docs/akka/current/additional/faq.html
Search the archives:
https://groups.google.com/group/akka-user
---
You received this message because you are subscribed to the Google
Groups Akka User List group.
To unsubscribe from this group and stop receiving emails from it, send
an email to akka-user+...@googlegroups.com.
To post to this group, send email to akka...@googlegroups.com.
Visit this group at http://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.
--
Cheers,
√
--
Read the docs: http://akka.io/docs/
Check the FAQ:
http://doc.akka.io/docs/akka/current/additional/faq.html
Search the archives: https://groups.google.com/group/akka-user
---
You received this message because you are subscribed to the Google Groups Akka
User List group.
To unsubscribe from this group and stop receiving emails from it, send an email
to akka-user+unsubscr...@googlegroups.com.
To post to this group, send email to akka-user@googlegroups.com.
Visit this
Re: [akka-user] Akka with org.apache.log4j.MDC
another alternative is to use http://kamon.io/
Use a trace context instead of MDC, and the trace context is propagated:
http://kamon.io/integrations/akka/automatic-trace-context-propagation/
Then, in your log configuration, use converter to access the data you put
in the trace context:
http://kamon.io/integrations/logback/trace-token-converter/
Le mar. 12 mai 2015 à 08:18, bysen...@gmail.com a écrit :
Thanks Nils, I am planning to use this approach now, but how do you keep
context between actors if you are using third party lib actors? I can't
modify them to include the context in their messages.
class RequestHandler() extends Actor with akka.actor.
DiagnosticActorLogging{
override def mdc(currentMessage: Any): MDC = {
currentMessage match {
case req: TraitWithRequestId = Map(requestId - req.id)
case _ = Map()
}
}
def receive: Receive = {
case req: TypeA =//TypeA extends
TraitWithRequestId
log.debug(RECEIVE req typeA) //logged with
correct [requestId - someRandom]
val thirdPartyA = context.ActorOf(thirdPartyA.props)
thirdPartyA ! req
case thirdPartyResponse = //cant modify 3rd
party to extend TraitWithRequestId
log.debug(RECEIVE third party response)//no value [requestId
- ]
val actorA = context.ActorOf(ActorA.props)
val messageToActorA = (thirPartyResponse.param1, requestId)
actorA ! messageToActorA
}
}
On Friday, May 8, 2015 at 2:31:03 PM UTC+8, nil...@gmail.com wrote:
I have struggled a lot with the same challenge. The MDC feature of the
logging frameworks need a little more manual intervention when operating
in an asynchronous runtime like Akka. MDC is tightly coupled to a thread,
but communication with and between Actors happen in different threads.
Hence, the MDC is not propagated automatically when sending messages
between your actors. Basically, you need to pass the context you wish to
log along with the messages in your system. So if you want to trace a
requestId in a conversation between your actors, you need to pass the
requestId along in the message, and then put it back in the MDC in the
receiving actor.
Regards,
Nils-Helge Garli Hegvik
On Thursday, May 7, 2015 at 10:27:59 AM UTC+2, byse...@gmail.com wrote:
Hi √,
I want to have MDC logging so I can organize my logs, for example
according to requestId.
I am tried out the example in
http://doc.akka.io/docs/akka/2.3.10/scala/logging.html#MDC_values_defined_by_the_application
.
It works fine for a single actor, but If I'm sending a message to
another Actor, the MDC values are not log on the other Actors.
class RequestHandler() extends Actor with
akka.actor.DiagnosticActorLogging{
override def mdc(currentMessage: Any): MDC = {
currentMessage match {
case req: TypeA = Map(requestId - req.id)
case _ = Map()
}
}
def receive: Receive = {
case req: TypeA =
log.debug(RECEIVE req typeA) //logged with
correct [requestId - someRandom]
val actorA = context.ActorOf(ActorA.props)
actorA ! req //logs in
actorA are do not have value on requestId (how to log them?)
}
}
class ActorA() extends Actor with akka.actor.DiagnosticActorLogging
{...} //logs of helperActors called by ActorA are not also logged with
correct requestId (how to log them?)
Is it possible with AKKA MDC to log all codeLogs (including logs from
dependency libs) for a certain requestId with correct MDC map values?
I also set akka logger to sl4fj on my application.conf
akka {
loggers = [akka.event.slf4j.Slf4jLogger]
logging-filter = akka.event.slf4j.Slf4jLoggingFilter
On Monday, April 27, 2015 at 3:30:47 PM UTC+8, √ wrote:
Hi Anindita,
It would be great for us to know what is lacking in the MDC sections of
the Akka Logging documentation,
please don't hesitate to contribute.
Thanks!
On Mon, Apr 27, 2015 at 8:09 AM, Anindita Ghatak anindi...@gmail.com
wrote:
Hi,
How can I use Akka with org.apache.log4j.MDC ?
Thanks Regards,
Anindita
--
Read the docs: http://akka.io/docs/
Check the FAQ:
http://doc.akka.io/docs/akka/current/additional/faq.html
Search the archives:
https://groups.google.com/group/akka-user
---
You received this message because you are subscribed to the Google
Groups Akka User List group.
To unsubscribe from this group and stop receiving emails from it, send
an email to akka-user+...@googlegroups.com.
To post to this group, send email to akka...@googlegroups.com.
Visit this group at http://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.
--
Cheers,
√
--
Read the docs: http://akka.io/docs/
Check the FAQ:
http://doc.akka.io/docs/akka/current/additional/faq.html
Search the archives:
[akka-user] Akka 2.3.11 Released!
*Dear hAkkers,*
We—the Akka committers—are pleased to be able to announce the availability
of Akka 2.3.11. This is the eleventh maintenance release of the 2.3 branch.
This release contains a few important fixes:
- a fix for BatchingExecutor (#16327
https://github.com/akka/akka/issues/16327; symptom is a requirement
failure when using blocking{} in Future callbacks)
- a fix for a performance regression caused by a previous bugfix in IO (
#17391 https://github.com/akka/akka/issues/17391)
- a revert of a performance optimization in 2.3.9 that caused actor
starvation when multiple dispatchers were involved (#17341
https://github.com/akka/akka/issues/17341; critical)
This release also adds an additional configuration parameter
https://github.com/akka/akka/issues/17274 for ForkJoinPool as well as a
fix for a wrong setting path https://github.com/akka/akka/issues/17316 in
Pinned Dispatcher configuration.
Akka 2.3.11 is released for Scala 2.10.4 and 2.11.5. This release is
backwards binary compatible with all previous 2.3.x versions which means
that the new JARs are a drop-in replacement for the old one (but not the
other way around) as long as your build does not enable the inliner
(Scala-only restriction). Always make sure to use at least the latest
version required by any of your project’s dependencies.
Migrating from Older Relases
When migrating an existing project from Akka 2.2.x please have a look at
the migration guide
http://doc.akka.io/docs/akka/2.3.11/project/migration-guide-2.2.x-2.3.x.html
.
Additional Release Details
The artifacts comprising this release have been published to
https://oss.sonatype.org/content/repositories/releases/ and also to Maven
Central. In addition, we adopted the sbt standard of encoding the Scala
binary version in the artifact name, i.e. the core actor package’s
artifactId is “akka-actor_2.10” or “akka-actor_2.11”, respectively.
The complete list of closed tickets can be found in the 2.3.11 github
issues milestone https://github.com/akka/akka/issues?q=milestone%3A2.3.11.
Credits
commits added removed
581 73 Patrik Nordwall
2 175 133 Endre Sándor Varga
1 1 1 Konrad Malawski
143 22 hepin
133 6 Roland Kuhn
*Happy hAkking!*
--
Martynas Mickevičius
Typesafe http://typesafe.com/ – Reactive
http://www.reactivemanifesto.org/ Apps on the JVM
--
Read the docs: http://akka.io/docs/
Check the FAQ:
http://doc.akka.io/docs/akka/current/additional/faq.html
Search the archives: https://groups.google.com/group/akka-user
---
You received this message because you are subscribed to the Google Groups Akka
User List group.
To unsubscribe from this group and stop receiving emails from it, send an email
to akka-user+unsubscr...@googlegroups.com.
To post to this group, send email to akka-user@googlegroups.com.
Visit this group at http://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.
Re: [akka-user] Akka 2.3.11 Released!
Cool thanks
On 12 May 2015 at 09:01, Giovanni pino.o...@gmail.com wrote:
wonderful!
On Tue, May 12, 2015 at 3:14 PM, Martynas Mickevičius
martynas.mickevic...@typesafe.com wrote:
*Dear hAkkers,*
We—the Akka committers—are pleased to be able to announce the
availability of Akka 2.3.11. This is the eleventh maintenance release of
the 2.3 branch. This release contains a few important fixes:
- a fix for BatchingExecutor (#16327
https://github.com/akka/akka/issues/16327; symptom is a requirement
failure when using blocking{} in Future callbacks)
- a fix for a performance regression caused by a previous bugfix in
IO (#17391 https://github.com/akka/akka/issues/17391)
- a revert of a performance optimization in 2.3.9 that caused actor
starvation when multiple dispatchers were involved (#17341
https://github.com/akka/akka/issues/17341; critical)
This release also adds an additional configuration parameter
https://github.com/akka/akka/issues/17274 for ForkJoinPool as well as a
fix for a wrong setting path https://github.com/akka/akka/issues/17316 in
Pinned Dispatcher configuration.
Akka 2.3.11 is released for Scala 2.10.4 and 2.11.5. This release is
backwards binary compatible with all previous 2.3.x versions which means
that the new JARs are a drop-in replacement for the old one (but not the
other way around) as long as your build does not enable the inliner
(Scala-only restriction). Always make sure to use at least the latest
version required by any of your project’s dependencies.
Migrating from Older Relases
When migrating an existing project from Akka 2.2.x please have a look at
the migration guide
http://doc.akka.io/docs/akka/2.3.11/project/migration-guide-2.2.x-2.3.x.html
.
Additional Release Details
The artifacts comprising this release have been published to
https://oss.sonatype.org/content/repositories/releases/ and also to
Maven Central. In addition, we adopted the sbt standard of encoding the
Scala binary version in the artifact name, i.e. the core actor package’s
artifactId is “akka-actor_2.10” or “akka-actor_2.11”, respectively.
The complete list of closed tickets can be found in the 2.3.11 github
issues milestone
https://github.com/akka/akka/issues?q=milestone%3A2.3.11.
Credits
commits added removed
581 73 Patrik Nordwall
2 175 133 Endre Sándor Varga
1 1 1 Konrad Malawski
143 22 hepin
133 6 Roland Kuhn
*Happy hAkking!*
--
Martynas Mickevičius
Typesafe http://typesafe.com/ – Reactive
http://www.reactivemanifesto.org/ Apps on the JVM
--
Read the docs: http://akka.io/docs/
Check the FAQ:
http://doc.akka.io/docs/akka/current/additional/faq.html
Search the archives: https://groups.google.com/group/akka-user
---
You received this message because you are subscribed to the Google Groups
Akka User List group.
To unsubscribe from this group and stop receiving emails from it, send an
email to akka-user+unsubscr...@googlegroups.com.
To post to this group, send email to akka-user@googlegroups.com.
Visit this group at http://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.
--
Knowledge is knowing a tomato is a fruit.
Wisdom is not putting it into a fruit salad.
A person is just about as big as the things that make him angry.
Be cheerful while you are alive.
-- Phathotep, 24th Century B.C.
Anyone can become angry -- that is easy; but to be angry with the right
person, to the right degree, at the right time, for the right purpose
and in the right way -- that is not easy.
-- Aristotle
--
Read the docs: http://akka.io/docs/
Check the FAQ:
http://doc.akka.io/docs/akka/current/additional/faq.html
Search the archives: https://groups.google.com/group/akka-user
---
You received this message because you are subscribed to the Google Groups
Akka User List group.
To unsubscribe from this group and stop receiving emails from it, send an
email to akka-user+unsubscr...@googlegroups.com.
To post to this group, send email to akka-user@googlegroups.com.
Visit this group at http://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.
--
[image: --]
Filippo De Luca
[image: http://]about.me/FilippoDeLuca
http://about.me/FilippoDeLuca?promo=email_sig
--
Read the docs: http://akka.io/docs/
Check the FAQ:
http://doc.akka.io/docs/akka/current/additional/faq.html
Search the archives: https://groups.google.com/group/akka-user
---
You received this message because you are subscribed to the Google Groups Akka
User List group.
To unsubscribe from this group and stop receiving emails from it, send an email
to akka-user+unsubscr...@googlegroups.com.
To post to this group, send email to akka-user@googlegroups.com.
Visit this group at http://groups.google.com/group/akka-user.
For more
Re: [akka-user] using Akka with Kamon...
On OSX using Docker. Running the container using Kitematic. I have tried
with VM IP and the port
My Kamon dashboard that launches
has http://192.168.99.100:32768/#/dashboard/db/welcome
I see Actor metrics using LogReporter. However on the dashboard, I just see
'No datapoints'
My statsd settings are
kamon{
statsd {
hostname = 192.168.99.100
port = 32768
flush-interval = 2 second
max-packet-size = 1024 bytes
includes {
actor = [ user/myActor* ]
trace = [ * ]
dispatcher = [ * ]
}
report-system-metrics = true
}
On Tuesday, May 12, 2015 at 5:31:09 AM UTC-7, Ivan Topolnjak wrote:
Hello TS!
May I ask what operating system are you using? Please remember that if you
are running on Windows or OSX then the Docker image is not really started
in your localhost but rather on a Virtualbox VM, you will need to find the
IP address of that machine and poing tha kamon-statsd module to that IP..
regards!
On Mon, May 11, 2015 at 10:50 PM TS test.te...@gmail.com javascript:
wrote:
Diego, Thanks,
I have installed the docker container for grafana/graphite/statsd.
However netstat does not show port 8125 to be open. Tried without host and
port for statsd.
However, I do see these messages while starting
2015-05-11 20:49:50,357 INFO supervisord started with pid 1 2015-05-11
20:49:51,360 INFO spawned: 'statsd' with pid 8 2015-05-11 20:49:51,362
INFO spawned: 'graphite-webapp' with pid 9 2015-05-11 20:49:51,365 INFO
spawned: 'nginx' with pid 10 2015-05-11 20:49:51,367 INFO spawned:
'carbon-cache' with pid 11 2015-05-11 20:49:51,369 INFO spawned:
'elasticsearch' with pid 13 2015-05-11 20:49:51,373 INFO spawned:
'dashboard_loader' with pid 14 2015-05-11 20:49:52,428 INFO success:
statsd entered RUNNING state, process has stayed up for than 1 seconds
(startsecs) 2015-05-11 20:49:52,428 INFO success: graphite-webapp
entered RUNNING state, process has stayed up for than 1 seconds
(startsecs) 2015-05-11 20:49:52,428 INFO success: nginx entered RUNNING
state, process has stayed up for than 1 seconds (startsecs) 2015-05-11
20:49:52,428 INFO success: carbon-cache entered RUNNING state, process has
stayed up for than 1 seconds (startsecs) 2015-05-11 20:49:52,428 INFO
success: elasticsearch entered RUNNING state, process has stayed up for
than 1 seconds (startsecs) 2015-05-11 20:49:52,428 INFO success:
dashboard_loader entered RUNNING state, process has stayed up for than 1
seconds (startsecs)
I can see the dashboard, However no metrics are shown. It says no data
points. Any help is appreciated.
I have this in my configuration
kamon {
#log-reporter {
#need this as a placeholder
#}
metrics {
filters = [
{
actor {
includes = [ user/* ]
excludes = [ system/* ]
}
},
{
trace {
includes = [ * ]
excludes = []
}
}
]
tick-interval = 1 second
}
# ~~
statsd {
hostname = 127.0.0.1
port = 8125
flush-interval = 1 second
max-packet-size = 1024 bytes
includes {
actor = [ * ]
trace = [ * ]
dispatcher = [ * ]
}
report-system-metrics = true
}
On Saturday, May 9, 2015 at 1:58:00 AM UTC-7, Diego Parra wrote:
Hi,
you can try with:
kamon {
...
statsd {
...
report-system-metrics = true
...
}}
Cheers,
Diego.
On Fri, May 8, 2015 at 10:27 PM, TS test.te...@gmail.com wrote:
Never mind. I was missing some configuration.
I do see
kamon.logreporter.LogReporterSubscriber : No user metrics reported
I need to get the kamon configuration for actorCount etc.
On Friday, May 8, 2015 at 6:16:44 PM UTC-7, TS wrote:
OK.
Good news: Using 2.3.10, no errors.
However, I am using kamon log reporter. I do not see any actor metrics
on my logs. Should I enable something on application.conf?
On Friday, May 8, 2015 at 4:40:14 PM UTC-7, Ivan Topolnjak wrote:
Oh, that can be a problem! We have not tested Kamon with 2.4 yet and
probably the issue you are facing is due to Kamon's bytecode being liked
to
certain Akka internals that changed between 2.3 and 2.4. Is it possible
for
you to use Akka 2.3? I will let you know when we get ready to support
Akka
2.4, regards!
On Sat, May 9, 2015 at 1:20 AM TS test.te...@gmail.com wrote:
BTW, I am using akka 2.4-SNAPSHOT
On Friday, May 8, 2015 at 3:54:41 PM UTC-7, TS wrote:
This is what I have in the pom
dependency
groupIdio.kamon/groupId
artifactIdkamon-core_2.11/artifactId
version0.3.5/version
/dependency
dependency
groupIdio.kamon/groupId
artifactIdkamon-log-reporter_2.11/artifactId
version0.3.5/version
/dependency
plugin
Re: [akka-user] Announcement: Opinionated RabbitMQ library using Akka / Reactive Streams
Unfortunately, Joseph, I think the answer here is no; this library will not reduce dependencies on any of the services you specify. It helps Scala applications integrate with RabbitMQ. On Monday, May 11, 2015 at 8:53:57 PM UTC-6, Joseph Mansigian wrote: Hello Tim, I saw your post about the library you developed and wonder if it can help me with a problem. I have a Java/Akka project that is now run from the command line. Currently anyone who wants to see what it can do has to install/already have: - git - java - scala - akka - yamlbeans I think that it is a barrier to go from a synopsis to being able to actually run the code if all of the above has to be in place as foundation. So I am thinking that what is needed is a Web based implementation that only requires you to have a browser. You can manipulate the application entirely by data ( all specific intelligence is modeled in data ) so forms would work. I am thinking of something like the W3C Try It kind of thing. With little time investment people could see if they are interested. My question is can your library help to realize the goal of giving my project an online presence? Or help in another way. A synopsis of my project can be found at: http://jcmansigian.webfactional.com/aed-abstract.html The project source is available on GitHib: git clone https://github.com/aed-project/aspire aspire-emergent-design Thanks, Joe Mansigian at 10:53 pm On Mon, May 11, 2015 at 12:23 AM, Tim Harper timch...@gmail.com javascript: wrote: I have developed a high-level library for efficiently setting up resilient, fault-tolerant RabbitMQ consumers using Akka and Akka Reactive Streams. Some of the features: - Recovery: - Consumers automatically reconnect and subscribe if the connection is lost - Messages published can optionally - Integration - Connection settings pulled from Typesafe config library - Asyncronous, concurrent consumption using Scala native Futures or the new Akka Streams project. - Common pattern for serialization allows easy integration with serialization libraries such play-json or json4s - Common pattern for exception handling to publish errors to Airbrake, Syslog, or all of the above - Modular - Composition favored over inheritance enabling flexible and high code reuse. - Modeled - Queue binding, exchange binding modeled with case classes - Publishing mechansims also modeled - Reliability - Builds on the excellent [Akka RabbitMQ client]( https://github.com/thenewmotion/akka-rabbitmq) library for easy recovery. - Built-in consumer error recovery strategy in which messages are re-delivered to the message queue and retried (not implemented for akka-streams integration as retry mechanism affects message order) - With a single message, pause all consumers if service health check fails (IE: database unavailable); easily resume the same. - Graceful shutdown - Consumers and streams can immediately unsubscribe, but stay alive long enough to wait for any messages to finish being processed. - Tested - Extensive integration tests The source is available here: https://github.com/SpinGo/op-rabbit We have been using the library internally at SpinGo for a year and I am working towards a 1.0.0 release candidate. We're using the streaming integration as the foundation for a billing system which is heavily based on reliable message-order, and at-least-once-delivery guarantees. I'm rather excited to share it with the world, and would be grateful for feedback. I plan on creating an Activator project to help people learn the library quickly. Some examples are on the github page. More examples can be found in the tests. Feedback, is of course, appreciated. Tim -- Read the docs: http://akka.io/docs/ Check the FAQ: http://doc.akka.io/docs/akka/current/additional/faq.html Search the archives: https://groups.google.com/group/akka-user --- You received this message because you are subscribed to the Google Groups Akka User List group. To unsubscribe from this group and stop receiving emails from it, send an email to akka-user+...@googlegroups.com javascript:. To post to this group, send email to akka...@googlegroups.com javascript:. Visit this group at http://groups.google.com/group/akka-user. For more options, visit https://groups.google.com/d/optout. -- Read the docs: http://akka.io/docs/ Check the FAQ: http://doc.akka.io/docs/akka/current/additional/faq.html Search the archives: https://groups.google.com/group/akka-user --- You received this message because you are subscribed to the Google Groups Akka User List group. To unsubscribe from this group and stop receiving emails from it, send an email to akka-user+unsubscr...@googlegroups.com. To post to this group, send email to akka-user@googlegroups.com. Visit this group at
Re: [akka-user] system.scheduler.scheduleOnce consumes Heap over time
Hi Jeff, Thank you for reporting! I opened a ticket: https://github.com/akka/akka/issues/17459 Let's move further investigation and discussion there. -Endre On Tue, May 12, 2015 at 7:38 AM, Jeff Steinmetz jeffrey.steinm...@gmail.com wrote: I thought there was something specific I was doing wrong in an application I have deployed in development, which eventually needs to be production ready. Over time, the Akka actor system slowly consumes all available memory. I assumed it was a memory leak that I introduced, but as it turns out, even the sample Typesafe hello-akka app demonstrates the same heap consumption. http://www.typesafe.com/activator/template/hello-akka If you let the sample application above run for a very long, the heap usage slowly grows, and is never released. Although, it is Very Slow Since it is set to send a message to the greeter only every 1 second, this isn't very apparent. I simplified the pattern I am using in an actual application, that demonstrates the same issue, but at an accelerated rate. This is modeled after the Scheduling Periodic Messages pattern described here: http://doc.akka.io/docs/akka/snapshot/scala/howto.html The full sample code to recreate the memory consumption, with heap usage logging is available at the gist below. (note: if you start with the hello-akka sample application, and replace HelloAkkaScala.scala with this gist below, you can reproduce. You will need to add to your build.sbt the following (as mentioned in the comments at the top of the gist) com.kenshoo %% metrics-play % 2.3.0_0.1.9 https://gist.github.com/jeffsteinmetz/bbccb4815858620ab5a2 You may need to let it run for about 1 to 2 minutes before you see the initial bump in heap usage. After that, you will see it slowly climb and never back down. Note - the metrics calls are not required, and do not cause the memory leak - you can watch system memory without this library and see the same issue. I've tried a few versions of Akka, with the same results. In production, a similar (real world) application eventually consumes all memory. Hoping for a little insight on the Akka internals, and potential solution. J -- Read the docs: http://akka.io/docs/ Check the FAQ: http://doc.akka.io/docs/akka/current/additional/faq.html Search the archives: https://groups.google.com/group/akka-user --- You received this message because you are subscribed to the Google Groups Akka User List group. To unsubscribe from this group and stop receiving emails from it, send an email to akka-user+unsubscr...@googlegroups.com. To post to this group, send email to akka-user@googlegroups.com. Visit this group at http://groups.google.com/group/akka-user. For more options, visit https://groups.google.com/d/optout. -- Read the docs: http://akka.io/docs/ Check the FAQ: http://doc.akka.io/docs/akka/current/additional/faq.html Search the archives: https://groups.google.com/group/akka-user --- You received this message because you are subscribed to the Google Groups Akka User List group. To unsubscribe from this group and stop receiving emails from it, send an email to akka-user+unsubscr...@googlegroups.com. To post to this group, send email to akka-user@googlegroups.com. Visit this group at http://groups.google.com/group/akka-user. For more options, visit https://groups.google.com/d/optout.
[akka-user] mapConcat
First of all: Impressive work, guys! Though I have some questions: Why does FlowOps.mapConcat expects a Seq and not a Traversable? (Say I want to pass a SortedSet.) And concerning the Seq: Why restricted to scala.collection.immutable.Seq and not scala.collection.Seq? -- Read the docs: http://akka.io/docs/ Check the FAQ: http://doc.akka.io/docs/akka/current/additional/faq.html Search the archives: https://groups.google.com/group/akka-user --- You received this message because you are subscribed to the Google Groups Akka User List group. To unsubscribe from this group and stop receiving emails from it, send an email to akka-user+unsubscr...@googlegroups.com. To post to this group, send email to akka-user@googlegroups.com. Visit this group at http://groups.google.com/group/akka-user. For more options, visit https://groups.google.com/d/optout.
Re: [akka-user] mapConcat
Hi Peter, On Tue, May 12, 2015 at 1:30 PM, Peter Schmitz petrischm...@gmail.com wrote: First of all: Impressive work, guys! Though I have some questions: Why does FlowOps.mapConcat expects a Seq and not a Traversable? (Say I want to pass a SortedSet.) Good question. I think it could be an Iterable (I would avoid Traversable though). I added a ticket. And concerning the Seq: Why restricted to scala.collection.immutable.Seq and not scala.collection.Seq? We always prefer immutable collections in our APIs In this case this is probably overkill, but at least it allows safe closing over of an existing collection in mapConcat from an external scope (since it is immutable). I don't think we will change it. -Endre -- Read the docs: http://akka.io/docs/ Check the FAQ: http://doc.akka.io/docs/akka/current/additional/faq.html Search the archives: https://groups.google.com/group/akka-user --- You received this message because you are subscribed to the Google Groups Akka User List group. To unsubscribe from this group and stop receiving emails from it, send an email to akka-user+unsubscr...@googlegroups.com. To post to this group, send email to akka-user@googlegroups.com. Visit this group at http://groups.google.com/group/akka-user. For more options, visit https://groups.google.com/d/optout. -- Read the docs: http://akka.io/docs/ Check the FAQ: http://doc.akka.io/docs/akka/current/additional/faq.html Search the archives: https://groups.google.com/group/akka-user --- You received this message because you are subscribed to the Google Groups Akka User List group. To unsubscribe from this group and stop receiving emails from it, send an email to akka-user+unsubscr...@googlegroups.com. To post to this group, send email to akka-user@googlegroups.com. Visit this group at http://groups.google.com/group/akka-user. For more options, visit https://groups.google.com/d/optout.
Re: [akka-user] Akka with org.apache.log4j.MDC
Thanks a lot Yann! This is super cool :D. I'm still browsing the documents,
would it be possible to use other conversionRule aside from *traceToken*
conversionRule conversionWord=traceToken
converterClass=kamon.trace.logging.LogbackTraceTokenConverter/
I am planning to put my requestId in the metaData of the traceContext but I
can't find the docs on how to modify the logback.xml for rules other than
traceToken
class RequestHandler() extends Actor with ActorLogging {
def receive: Receive = {
case req: TypeA =
val context = Kamon.tracer.newContext(req.requestId)
context.addMetada(requestId, req.requestId)
context.addMetada(otherKeyId, req.otherKeyId)
Tracer.withNewContext(context){
log.debug(RECEIVE req typeA)
val thirdPartyA = context.ActorOf(thirdPartyA.props)
thirdPartyA ! req
}
}
}
logback.xml
configuration
conversionRule conversionWord=requestId converterClass=
kamon.trace.logging.LogbackTraceTokenConverter/
conversionRule conversionWord=otherKeyId converterClass=
kamon.trace.logging.LogbackTraceTokenConverter/
conversionRule conversionWord=name converterClass=
kamon.trace.logging.LogbackTraceTokenConverter/
appender name=STDOUT class=ch.qos.logback.core.ConsoleAppender
filter class=ch.qos.logback.classic.filter.ThresholdFilter
levelDEBUG/level
/filter
encoder
pattern%date{ISO8601} [%-5level] [%requestId] [%
otherKeyId] [%name] %logger{36} %X{sourceThread} - %msg%n/pattern
/encoder
/appender
...
/configuration
[%requestId] [%otherKeyId] [%name] still output the data for traceToken
instead of the value I assigned for the name and metadata of the context
Also, have you encountered this while using Kamon during startup?
[error] objc[5646]: Class JavaLaunchHelper is implemented in both
/Library/Java/JavaVirtualMachines/jdk1.8.0_25.jdk/Contents/Home/jre/bin/java
and
/Library/Java/JavaVirtualMachines/jdk1.8.0_25.jdk/Contents/Home/jre/lib/libinstrument.dylib.
One of the two will be used. Which one is undefined.
On Tuesday, May 12, 2015 at 2:30:39 PM UTC+8, Yann Simon wrote:
another alternative is to use http://kamon.io/
Use a trace context instead of MDC, and the trace context is propagated:
http://kamon.io/integrations/akka/automatic-trace-context-propagation/
Then, in your log configuration, use converter to access the data you put
in the trace context:
http://kamon.io/integrations/logback/trace-token-converter/
Le mar. 12 mai 2015 à 08:18, byse...@gmail.com javascript: a écrit :
Thanks Nils, I am planning to use this approach now, but how do you keep
context between actors if you are using third party lib actors? I can't
modify them to include the context in their messages.
class RequestHandler() extends Actor with akka.actor.
DiagnosticActorLogging{
override def mdc(currentMessage: Any): MDC = {
currentMessage match {
case req: TraitWithRequestId = Map(requestId - req.id)
case _ = Map()
}
}
def receive: Receive = {
case req: TypeA =//TypeA extends
TraitWithRequestId
log.debug(RECEIVE req typeA) //logged with
correct [requestId - someRandom]
val thirdPartyA = context.ActorOf(thirdPartyA.props)
thirdPartyA ! req
case thirdPartyResponse = //cant modify 3rd
party to extend TraitWithRequestId
log.debug(RECEIVE third party response)//no value [requestId
- ]
val actorA = context.ActorOf(ActorA.props)
val messageToActorA = (thirPartyResponse.param1, requestId)
actorA ! messageToActorA
}
}
On Friday, May 8, 2015 at 2:31:03 PM UTC+8, nil...@gmail.com wrote:
I have struggled a lot with the same challenge. The MDC feature of the
logging frameworks need a little more manual intervention when operating
in an asynchronous runtime like Akka. MDC is tightly coupled to a thread,
but communication with and between Actors happen in different threads.
Hence, the MDC is not propagated automatically when sending messages
between your actors. Basically, you need to pass the context you wish to
log along with the messages in your system. So if you want to trace a
requestId in a conversation between your actors, you need to pass the
requestId along in the message, and then put it back in the MDC in the
receiving actor.
Regards,
Nils-Helge Garli Hegvik
On Thursday, May 7, 2015 at 10:27:59 AM UTC+2, byse...@gmail.com wrote:
Hi √,
I want to have MDC logging so I can organize my logs, for example
according to requestId.
I am tried out the example in
http://doc.akka.io/docs/akka/2.3.10/scala/logging.html#MDC_values_defined_by_the_application
.
It works
[akka-user] Re: Akka 2.3.11 Released!
update to new version now.thanks -- Read the docs: http://akka.io/docs/ Check the FAQ: http://doc.akka.io/docs/akka/current/additional/faq.html Search the archives: https://groups.google.com/group/akka-user --- You received this message because you are subscribed to the Google Groups Akka User List group. To unsubscribe from this group and stop receiving emails from it, send an email to akka-user+unsubscr...@googlegroups.com. To post to this group, send email to akka-user@googlegroups.com. Visit this group at http://groups.google.com/group/akka-user. For more options, visit https://groups.google.com/d/optout.
[akka-user] PersistentActor creation.
What is the best way to create a persistent actor once per session. Create it the first time, but look it up if it is already created. Thanks, TS -- Read the docs: http://akka.io/docs/ Check the FAQ: http://doc.akka.io/docs/akka/current/additional/faq.html Search the archives: https://groups.google.com/group/akka-user --- You received this message because you are subscribed to the Google Groups Akka User List group. To unsubscribe from this group and stop receiving emails from it, send an email to akka-user+unsubscr...@googlegroups.com. To post to this group, send email to akka-user@googlegroups.com. Visit this group at http://groups.google.com/group/akka-user. For more options, visit https://groups.google.com/d/optout.
Re: [akka-user] Akka with org.apache.log4j.MDC
Hello guys!
As Yann said, the only Kamon thing that officially can be put in your log
patterns is the trace token via the provided converter, but, Kamon has
something called TraceLocal Storage which is basically a map where you
can put info and retrieve later on wherever you have access to the same
TraceContext, including support for providing key/value pairs that should
be available to MDC. We did not include any documentation on that feature
because it's API is a bit ugly and certainly not Java-friendly and we will
work on improving that soon [1], but if you want to give a try to the
current implementation then take a look at the hidden docs on that [2].
Let us know if you need any further assistance, regards!
[1] https://github.com/kamon-io/Kamon/issues/196
[2]
http://master.kamon.io/integrations/logback/mdc-in-an-asyncronous-environment/
On Tue, May 12, 2015 at 1:07 PM Yann Simon yann.simon...@gmail.com wrote:
Le mar. 12 mai 2015 à 12:31, bysen...@gmail.com a écrit :
Thanks a lot Yann! This is super cool :D. I'm still browsing the
documents, would it be possible to use other conversionRule aside from
*traceToken*
conversionRule conversionWord=traceToken
converterClass=kamon.trace.logging.LogbackTraceTokenConverter/
Yes, I think so but I have not checked it myself.
But it seems quite easy: just write your own converter.
I am planning to put my requestId in the metaData of the traceContext but
I can't find the docs on how to modify the logback.xml for rules other than
traceToken
class RequestHandler() extends Actor with ActorLogging {
def receive: Receive = {
case req: TypeA =
val context = Kamon.tracer.newContext(req.requestId)
context.addMetada(requestId, req.requestId)
context.addMetada(otherKeyId, req.otherKeyId)
Tracer.withNewContext(context){
log.debug(RECEIVE req typeA)
val thirdPartyA = context.ActorOf(thirdPartyA.props)
thirdPartyA ! req
}
}
}
logback.xml
configuration
conversionRule conversionWord=requestId converterClass=
kamon.trace.logging.LogbackTraceTokenConverter/
conversionRule conversionWord=otherKeyId converterClass=
kamon.trace.logging.LogbackTraceTokenConverter/
conversionRule conversionWord=name converterClass=
kamon.trace.logging.LogbackTraceTokenConverter/
appender name=STDOUT class=ch.qos.logback.core.ConsoleAppender
filter class=ch.qos.logback.classic.filter.ThresholdFilter
levelDEBUG/level
/filter
encoder
pattern%date{ISO8601} [%-5level] [%messageId] [%
iccid] [%name] %logger{36} %X{sourceThread} - %msg%n/pattern
/encoder
/appender
...
/configuration
[%messageId] [%iccid] [%name] still output the data for traceToken
instead of the value I assigned for the name and metadata of the context
I personally put the request ID in the context token, as the existing
converter is implemented only for the context token.
If we want to access different data, you need a different converter class
for each of your conversionWord.
Also, have you encountered this while using Kamon during startup?
[error] objc[5646]: Class JavaLaunchHelper is implemented in both
/Library/Java/JavaVirtualMachines/jdk1.8.0_25.jdk/Contents/Home/jre/bin/java
and
/Library/Java/JavaVirtualMachines/jdk1.8.0_25.jdk/Contents/Home/jre/lib/libinstrument.dylib.
One of the two will be used. Which one is undefined.
Yes, I see that. It has to do with Aspectj.
I can recommend you to post your questions on the kamon users mailing
list, they are very friendly and reactive.
On Tuesday, May 12, 2015 at 2:30:39 PM UTC+8, Yann Simon wrote:
another alternative is to use http://kamon.io/
Use a trace context instead of MDC, and the trace context is propagated:
http://kamon.io/integrations/akka/automatic-trace-context-propagation/
Then, in your log configuration, use converter to access the data you
put in the trace context:
http://kamon.io/integrations/logback/trace-token-converter/
Le mar. 12 mai 2015 à 08:18, byse...@gmail.com a écrit :
Thanks Nils, I am planning to use this approach now, but how do you
keep context between actors if you are using third party lib actors? I
can't modify them to include the context in their messages.
class RequestHandler() extends Actor with akka.actor.
DiagnosticActorLogging{
override def mdc(currentMessage: Any): MDC = {
currentMessage match {
case req: TraitWithRequestId = Map(requestId - req.id)
case _ = Map()
}
}
def receive: Receive = {
case req: TypeA =//TypeA extends
TraitWithRequestId
log.debug(RECEIVE req typeA) //logged with
correct [requestId - someRandom]
val thirdPartyA = context.ActorOf(thirdPartyA.props)
thirdPartyA ! req
case thirdPartyResponse =
Re: [akka-user] mapConcat
scala.collection.immutable.Iterable seems like a good choice over Seq On Tue, May 12, 2015 at 1:38 PM, Endre Varga endre.va...@typesafe.com wrote: Hi Peter, On Tue, May 12, 2015 at 1:30 PM, Peter Schmitz petrischm...@gmail.com wrote: First of all: Impressive work, guys! Though I have some questions: Why does FlowOps.mapConcat expects a Seq and not a Traversable? (Say I want to pass a SortedSet.) Good question. I think it could be an Iterable (I would avoid Traversable though). I added a ticket. And concerning the Seq: Why restricted to scala.collection.immutable.Seq and not scala.collection.Seq? We always prefer immutable collections in our APIs In this case this is probably overkill, but at least it allows safe closing over of an existing collection in mapConcat from an external scope (since it is immutable). I don't think we will change it. -Endre -- Read the docs: http://akka.io/docs/ Check the FAQ: http://doc.akka.io/docs/akka/current/additional/faq.html Search the archives: https://groups.google.com/group/akka-user --- You received this message because you are subscribed to the Google Groups Akka User List group. To unsubscribe from this group and stop receiving emails from it, send an email to akka-user+unsubscr...@googlegroups.com. To post to this group, send email to akka-user@googlegroups.com. Visit this group at http://groups.google.com/group/akka-user. For more options, visit https://groups.google.com/d/optout. -- Read the docs: http://akka.io/docs/ Check the FAQ: http://doc.akka.io/docs/akka/current/additional/faq.html Search the archives: https://groups.google.com/group/akka-user --- You received this message because you are subscribed to the Google Groups Akka User List group. To unsubscribe from this group and stop receiving emails from it, send an email to akka-user+unsubscr...@googlegroups.com. To post to this group, send email to akka-user@googlegroups.com. Visit this group at http://groups.google.com/group/akka-user. For more options, visit https://groups.google.com/d/optout. -- Cheers, √ -- Read the docs: http://akka.io/docs/ Check the FAQ: http://doc.akka.io/docs/akka/current/additional/faq.html Search the archives: https://groups.google.com/group/akka-user --- You received this message because you are subscribed to the Google Groups Akka User List group. To unsubscribe from this group and stop receiving emails from it, send an email to akka-user+unsubscr...@googlegroups.com. To post to this group, send email to akka-user@googlegroups.com. Visit this group at http://groups.google.com/group/akka-user. For more options, visit https://groups.google.com/d/optout.
Re: [akka-user] using Akka with Kamon...
Hello TS!
May I ask what operating system are you using? Please remember that if you
are running on Windows or OSX then the Docker image is not really started
in your localhost but rather on a Virtualbox VM, you will need to find the
IP address of that machine and poing tha kamon-statsd module to that IP..
regards!
On Mon, May 11, 2015 at 10:50 PM TS test.tester1...@gmail.com wrote:
Diego, Thanks,
I have installed the docker container for grafana/graphite/statsd. However
netstat does not show port 8125 to be open. Tried without host and port for
statsd.
However, I do see these messages while starting
2015-05-11 20:49:50,357 INFO supervisord started with pid 1 2015-05-11
20:49:51,360 INFO spawned: 'statsd' with pid 8 2015-05-11 20:49:51,362
INFO spawned: 'graphite-webapp' with pid 9 2015-05-11 20:49:51,365 INFO
spawned: 'nginx' with pid 10 2015-05-11 20:49:51,367 INFO spawned:
'carbon-cache' with pid 11 2015-05-11 20:49:51,369 INFO spawned:
'elasticsearch' with pid 13 2015-05-11 20:49:51,373 INFO spawned:
'dashboard_loader' with pid 14 2015-05-11 20:49:52,428 INFO success:
statsd entered RUNNING state, process has stayed up for than 1 seconds
(startsecs) 2015-05-11 20:49:52,428 INFO success: graphite-webapp entered
RUNNING state, process has stayed up for than 1 seconds (startsecs)
2015-05-11
20:49:52,428 INFO success: nginx entered RUNNING state, process has stayed
up for than 1 seconds (startsecs) 2015-05-11 20:49:52,428 INFO success:
carbon-cache entered RUNNING state, process has stayed up for than 1
seconds (startsecs) 2015-05-11 20:49:52,428 INFO success: elasticsearch
entered RUNNING state, process has stayed up for than 1 seconds
(startsecs) 2015-05-11 20:49:52,428 INFO success: dashboard_loader
entered RUNNING state, process has stayed up for than 1 seconds
(startsecs)
I can see the dashboard, However no metrics are shown. It says no data
points. Any help is appreciated.
I have this in my configuration
kamon {
#log-reporter {
#need this as a placeholder
#}
metrics {
filters = [
{
actor {
includes = [ user/* ]
excludes = [ system/* ]
}
},
{
trace {
includes = [ * ]
excludes = []
}
}
]
tick-interval = 1 second
}
# ~~
statsd {
hostname = 127.0.0.1
port = 8125
flush-interval = 1 second
max-packet-size = 1024 bytes
includes {
actor = [ * ]
trace = [ * ]
dispatcher = [ * ]
}
report-system-metrics = true
}
On Saturday, May 9, 2015 at 1:58:00 AM UTC-7, Diego Parra wrote:
Hi,
you can try with:
kamon {
...
statsd {
...
report-system-metrics = true
...
}}
Cheers,
Diego.
On Fri, May 8, 2015 at 10:27 PM, TS test.te...@gmail.com wrote:
Never mind. I was missing some configuration.
I do see
kamon.logreporter.LogReporterSubscriber : No user metrics reported
I need to get the kamon configuration for actorCount etc.
On Friday, May 8, 2015 at 6:16:44 PM UTC-7, TS wrote:
OK.
Good news: Using 2.3.10, no errors.
However, I am using kamon log reporter. I do not see any actor metrics
on my logs. Should I enable something on application.conf?
On Friday, May 8, 2015 at 4:40:14 PM UTC-7, Ivan Topolnjak wrote:
Oh, that can be a problem! We have not tested Kamon with 2.4 yet and
probably the issue you are facing is due to Kamon's bytecode being liked
to
certain Akka internals that changed between 2.3 and 2.4. Is it possible
for
you to use Akka 2.3? I will let you know when we get ready to support Akka
2.4, regards!
On Sat, May 9, 2015 at 1:20 AM TS test.te...@gmail.com wrote:
BTW, I am using akka 2.4-SNAPSHOT
On Friday, May 8, 2015 at 3:54:41 PM UTC-7, TS wrote:
This is what I have in the pom
dependency
groupIdio.kamon/groupId
artifactIdkamon-core_2.11/artifactId
version0.3.5/version
/dependency
dependency
groupIdio.kamon/groupId
artifactIdkamon-log-reporter_2.11/artifactId
version0.3.5/version
/dependency
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-surefire-plugin/artifactId
version2.18.1/version
configuration
argLine-javaagent:path to aspectjweaver
-1.7.4.jar/argLine
/configuration
/plugin
and in my application.conf
extensions = [kamon.metric.Metrics]
a test like will cause the error to happen.
@Test
public void testForFoo() {
final TestActorRefFooActor ref = TestActorRef.create(
system, Props.create(FooActor.class), testFoo);
Object obj = ref
.underlyingActor().testFoo(ByteString.fromArray(abc.getBytes()));
}
On Friday, May 8, 2015 at 4:47:36 AM UTC-7, Ivan Topolnjak wrote:
Hello TS,
I have been
Re: [akka-user] mapConcat
Ah yes, and I forgot to paste the link to the ticket: https://github.com/akka/akka/issues/17464 On Tue, May 12, 2015 at 1:49 PM, Viktor Klang viktor.kl...@gmail.com wrote: scala.collection.immutable.Iterable seems like a good choice over Seq On Tue, May 12, 2015 at 1:38 PM, Endre Varga endre.va...@typesafe.com wrote: Hi Peter, On Tue, May 12, 2015 at 1:30 PM, Peter Schmitz petrischm...@gmail.com wrote: First of all: Impressive work, guys! Though I have some questions: Why does FlowOps.mapConcat expects a Seq and not a Traversable? (Say I want to pass a SortedSet.) Good question. I think it could be an Iterable (I would avoid Traversable though). I added a ticket. And concerning the Seq: Why restricted to scala.collection.immutable.Seq and not scala.collection.Seq? We always prefer immutable collections in our APIs In this case this is probably overkill, but at least it allows safe closing over of an existing collection in mapConcat from an external scope (since it is immutable). I don't think we will change it. -Endre -- Read the docs: http://akka.io/docs/ Check the FAQ: http://doc.akka.io/docs/akka/current/additional/faq.html Search the archives: https://groups.google.com/group/akka-user --- You received this message because you are subscribed to the Google Groups Akka User List group. To unsubscribe from this group and stop receiving emails from it, send an email to akka-user+unsubscr...@googlegroups.com. To post to this group, send email to akka-user@googlegroups.com. Visit this group at http://groups.google.com/group/akka-user. For more options, visit https://groups.google.com/d/optout. -- Read the docs: http://akka.io/docs/ Check the FAQ: http://doc.akka.io/docs/akka/current/additional/faq.html Search the archives: https://groups.google.com/group/akka-user --- You received this message because you are subscribed to the Google Groups Akka User List group. To unsubscribe from this group and stop receiving emails from it, send an email to akka-user+unsubscr...@googlegroups.com. To post to this group, send email to akka-user@googlegroups.com. Visit this group at http://groups.google.com/group/akka-user. For more options, visit https://groups.google.com/d/optout. -- Cheers, √ -- Read the docs: http://akka.io/docs/ Check the FAQ: http://doc.akka.io/docs/akka/current/additional/faq.html Search the archives: https://groups.google.com/group/akka-user --- You received this message because you are subscribed to the Google Groups Akka User List group. To unsubscribe from this group and stop receiving emails from it, send an email to akka-user+unsubscr...@googlegroups.com. To post to this group, send email to akka-user@googlegroups.com. Visit this group at http://groups.google.com/group/akka-user. For more options, visit https://groups.google.com/d/optout. -- Read the docs: http://akka.io/docs/ Check the FAQ: http://doc.akka.io/docs/akka/current/additional/faq.html Search the archives: https://groups.google.com/group/akka-user --- You received this message because you are subscribed to the Google Groups Akka User List group. To unsubscribe from this group and stop receiving emails from it, send an email to akka-user+unsubscr...@googlegroups.com. To post to this group, send email to akka-user@googlegroups.com. Visit this group at http://groups.google.com/group/akka-user. For more options, visit https://groups.google.com/d/optout.
Re: [akka-user] Akka with org.apache.log4j.MDC
Le mar. 12 mai 2015 à 12:31, bysen...@gmail.com a écrit :
Thanks a lot Yann! This is super cool :D. I'm still browsing the
documents, would it be possible to use other conversionRule aside from
*traceToken*
conversionRule conversionWord=traceToken
converterClass=kamon.trace.logging.LogbackTraceTokenConverter/
Yes, I think so but I have not checked it myself.
But it seems quite easy: just write your own converter.
I am planning to put my requestId in the metaData of the traceContext but
I can't find the docs on how to modify the logback.xml for rules other than
traceToken
class RequestHandler() extends Actor with ActorLogging {
def receive: Receive = {
case req: TypeA =
val context = Kamon.tracer.newContext(req.requestId)
context.addMetada(requestId, req.requestId)
context.addMetada(otherKeyId, req.otherKeyId)
Tracer.withNewContext(context){
log.debug(RECEIVE req typeA)
val thirdPartyA = context.ActorOf(thirdPartyA.props)
thirdPartyA ! req
}
}
}
logback.xml
configuration
conversionRule conversionWord=requestId converterClass=
kamon.trace.logging.LogbackTraceTokenConverter/
conversionRule conversionWord=otherKeyId converterClass=
kamon.trace.logging.LogbackTraceTokenConverter/
conversionRule conversionWord=name converterClass=
kamon.trace.logging.LogbackTraceTokenConverter/
appender name=STDOUT class=ch.qos.logback.core.ConsoleAppender
filter class=ch.qos.logback.classic.filter.ThresholdFilter
levelDEBUG/level
/filter
encoder
pattern%date{ISO8601} [%-5level] [%messageId] [%
iccid] [%name] %logger{36} %X{sourceThread} - %msg%n/pattern
/encoder
/appender
...
/configuration
[%messageId] [%iccid] [%name] still output the data for traceToken
instead of the value I assigned for the name and metadata of the context
I personally put the request ID in the context token, as the existing
converter is implemented only for the context token.
If we want to access different data, you need a different converter class
for each of your conversionWord.
Also, have you encountered this while using Kamon during startup?
[error] objc[5646]: Class JavaLaunchHelper is implemented in both
/Library/Java/JavaVirtualMachines/jdk1.8.0_25.jdk/Contents/Home/jre/bin/java
and
/Library/Java/JavaVirtualMachines/jdk1.8.0_25.jdk/Contents/Home/jre/lib/libinstrument.dylib.
One of the two will be used. Which one is undefined.
Yes, I see that. It has to do with Aspectj.
I can recommend you to post your questions on the kamon users mailing list,
they are very friendly and reactive.
On Tuesday, May 12, 2015 at 2:30:39 PM UTC+8, Yann Simon wrote:
another alternative is to use http://kamon.io/
Use a trace context instead of MDC, and the trace context is propagated:
http://kamon.io/integrations/akka/automatic-trace-context-propagation/
Then, in your log configuration, use converter to access the data you put
in the trace context:
http://kamon.io/integrations/logback/trace-token-converter/
Le mar. 12 mai 2015 à 08:18, byse...@gmail.com a écrit :
Thanks Nils, I am planning to use this approach now, but how do you keep
context between actors if you are using third party lib actors? I can't
modify them to include the context in their messages.
class RequestHandler() extends Actor with akka.actor.
DiagnosticActorLogging{
override def mdc(currentMessage: Any): MDC = {
currentMessage match {
case req: TraitWithRequestId = Map(requestId - req.id)
case _ = Map()
}
}
def receive: Receive = {
case req: TypeA =//TypeA extends
TraitWithRequestId
log.debug(RECEIVE req typeA) //logged with
correct [requestId - someRandom]
val thirdPartyA = context.ActorOf(thirdPartyA.props)
thirdPartyA ! req
case thirdPartyResponse = //cant modify 3rd
party to extend TraitWithRequestId
log.debug(RECEIVE third party response)//no value [requestId
- ]
val actorA = context.ActorOf(ActorA.props)
val messageToActorA = (thirPartyResponse.param1, requestId)
actorA ! messageToActorA
}
}
On Friday, May 8, 2015 at 2:31:03 PM UTC+8, nil...@gmail.com wrote:
I have struggled a lot with the same challenge. The MDC feature of the
logging frameworks need a little more manual intervention when operating
in an asynchronous runtime like Akka. MDC is tightly coupled to a thread,
but communication with and between Actors happen in different threads.
Hence, the MDC is not propagated automatically when sending messages
between your actors. Basically, you need to pass the context you wish to
log along with the messages in your system. So if you want to trace a
requestId in a conversation between your actors, you need
[akka-user] TestKit and how to avoid a failing (or sucesful) test affecting the other tests
Hi, I am having this issue where I sometimes tell different actors multiple messages and I want to test a single message, so I might have 1 expectMsg. But then, this affects the rest of the tests ,i.e. if the receiver is the testActor. is there a way to reset TestKit for each test? Thanks (Note: i've asked a more detailed question similar to this but it is probably too complex and didn't get any answers yet) -- Read the docs: http://akka.io/docs/ Check the FAQ: http://doc.akka.io/docs/akka/current/additional/faq.html Search the archives: https://groups.google.com/group/akka-user --- You received this message because you are subscribed to the Google Groups Akka User List group. To unsubscribe from this group and stop receiving emails from it, send an email to akka-user+unsubscr...@googlegroups.com. To post to this group, send email to akka-user@googlegroups.com. Visit this group at http://groups.google.com/group/akka-user. For more options, visit https://groups.google.com/d/optout.
[akka-user] Isn't the Singleton unnecessary in theakka-sample-cluster-java Activator sample?
I am trying to understand the stats2.conf example in the akka-sample-cluster-java Activator module; Why do I need the singleton (ClusterSingletonManager) here? Souldn't it be enough to just use StatsService Actor without the Singleton pattern on its own cluster node? There would be only one StatsService Actor and its router would ensure that the payload-messages gets send to all the available Workers on all cluster nodes. Many Greetings John -- Read the docs: http://akka.io/docs/ Check the FAQ: http://doc.akka.io/docs/akka/current/additional/faq.html Search the archives: https://groups.google.com/group/akka-user --- You received this message because you are subscribed to the Google Groups Akka User List group. To unsubscribe from this group and stop receiving emails from it, send an email to akka-user+unsubscr...@googlegroups.com. To post to this group, send email to akka-user@googlegroups.com. Visit this group at http://groups.google.com/group/akka-user. For more options, visit https://groups.google.com/d/optout.
