date:20150512

[akka-user] akka-http/spray FileAndResourceDirectives.getFromResource with sub directories

2015-05-12 Thread Martin Jöhren

Hi,

I'm using getFromResource to deliver html,pics and javascript from a 
directory which has multiple sub directories. That works fine except the 
case, that when using a url which maps on a sub directory the file listing 
of the directory will be shown. As far as I can see the code is trying to 
avoid that when the url ends with a '/' but without the slash it just 
returns a list of all the files.
I don't want to reject every path directly so I was wondering whether it 
makes sense to check inside the method whether it's a directory and if so, 
just reject the request. I could provide a PR for that when that does not 
break anything else?

Best

Martin

-- 
>>  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] Waiting for actor to "become" x in test cases

2015-05-12 Thread Kostas kougios

Hi,

Currently my actor becomes ready when it receives a msg :

class MyActor {
private val mediator = 
DistributedPubSubExtension(context.system).mediator
mediator ! Subscribe(Subscriptions.Index, self)

...
override def receive = {
case SubscribeAck(Subscribe(Subscriptions.Index, None, self)) =>
context become ready
}

def ready =
createPart.receive orElse
retrievePart.receive

}

This creates problems in test cases, when I send a msg to my actor:

myActor ! Create(...) // this is received before SubscribeAck and hence it 
is ignored

My temp solution is to sleep a bit after creating an actor so that I give 
an opportunity to the mediator to send the SubscribeAck:

val indexActor = system.actorOf(Props(IndexActor.empty(IntKey, 
StringValue, cluster.ref)))
// TODO: replace this with something better. This is required so 
that the actor becomes ready
Thread.sleep(5)


Is there a better solution?

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.

Re: [akka-user] system.scheduler.scheduleOnce consumes Heap over time

2015-05-12 Thread Roland Kuhn

Hi Jeff,

Since you don't mention it, are you talking about pure heap size or about 
unreclaimable objects? It is completely normal that the JVM’s memory usage only 
grows and never shrinks and this alone is not indicative of a memory leak—the 
growth is bounded by your JVM configuration settings and a real leak would 
eventually lead to an OutOfMemoryError. Please use a profiler to determine if 
the retained set actually grows and if GC fails to bring it back down.

Regards,

Roland 

Sent from my iPhone

> On 12 May 2015, at 07:38, Jeff Steinmetz  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] PersistentActor creation.

2015-05-12 Thread TS

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] Announcement: Opinionated RabbitMQ library using Akka / Reactive Streams

2015-05-12 Thread Tim Harper

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  > 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 .
>> 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.
>>
>
>

-- 
>>  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 unsu

Re: [akka-user] using Akka with Kamon...

2015-05-12 Thread TS

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 > 
> 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  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  wrote:
>>
>>> BTW, I am using akka 2.4-SNAPSHOT
>

[akka-user] TestKit and how to avoid a failing (or sucesful) test affecting the other tests

2015-05-12 Thread Kostas kougios

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?

2015-05-12 Thread john . vieten

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.

Re: [akka-user] using Akka with Kamon...

2015-05-12 Thread Ivan Topolnjak

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  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  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  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
>>>
>>> 
>>>
>>>   io.kamon
>>>
>>>   kamon-core_2.11
>>>
>>>   0.3.5
>>>
>>> 
>>>
>>> 
>>>
>>>   io.kamon
>>>
>>>   kamon-log-reporter_2.11
>>>
>>>   0.3.5
>>>
>>> 
>>>
>>> 
>>>
>>> org.apache.maven.plugins
>>>
>>> maven-surefire-plugin
>>>
>>> 2.18.1
>>>
>>> 
>>>
>>>   -javaagent:>> -1.7.4.jar>
>>>
>>> 
>>>
>>>   
>>>
>>>
>>> and in my application.conf
>>>
>>>
>>> extensions = ["kamon.metric.Metrics"]
>>>
>>>
>>> a test like will cause the error to happen.
>>>
>>>  @Test
>>>
>>> pub

Re: [akka-user] mapConcat

2015-05-12 Thread Endre Varga

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 
wrote:

> scala.collection.immutable.Iterable seems like a good choice over Seq
>
> On Tue, May 12, 2015 at 1:38 PM, Endre Varga 
> wrote:
>
>> Hi Peter,
>>
>>
>> On Tue, May 12, 2015 at 1:30 PM, Peter Schmitz 
>> 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

2015-05-12 Thread Ivan Topolnjak

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  wrote:

> Le mar. 12 mai 2015 à 12:31,  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*
>>
>>
>> > 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
>>
>> 
>> > "kamon.trace.logging.LogbackTraceTokenConverter"/>
>> > "kamon.trace.logging.LogbackTraceTokenConverter"/>
>> > "kamon.trace.logging.LogbackTraceTokenConverter"/>
>>
>>  
>> > >
>>  DEBUG
>>
>>   
>>   %date{ISO8601} [%-5level] [%messageId] [%
>> iccid] [%name] %logger{36} %X{sourceThread} - %msg%n
>>
>>   
>>
>> ...
>> 
>>
>>
>>
>> [%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,  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

Re: [akka-user] mapConcat

2015-05-12 Thread Viktor Klang

scala.collection.immutable.Iterable seems like a good choice over Seq

On Tue, May 12, 2015 at 1:38 PM, Endre Varga 
wrote:

> Hi Peter,
>
>
> On Tue, May 12, 2015 at 1:30 PM, Peter Schmitz 
> 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] mapConcat

2015-05-12 Thread Endre Varga

Hi Peter,


On Tue, May 12, 2015 at 1:30 PM, Peter Schmitz 
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.

[akka-user] mapConcat

2015-05-12 Thread Peter Schmitz

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] Akka with org.apache.log4j.MDC

2015-05-12 Thread Yann Simon

Le mar. 12 mai 2015 à 12:31,  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*
>
>
>  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
>
> 
>  "kamon.trace.logging.LogbackTraceTokenConverter"/>
>  "kamon.trace.logging.LogbackTraceTokenConverter"/>
>  "kamon.trace.logging.LogbackTraceTokenConverter"/>
>
>  
> 
>  DEBUG
>
>   
>   %date{ISO8601} [%-5level] [%messageId] [%
> iccid] [%name] %logger{36} %X{sourceThread} - %msg%n
>
>   
>
> ...
> 
>
>
>
> [%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,  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

Re: [akka-user] Akka with org.apache.log4j.MDC

2015-05-12 Thread bysen128

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*





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






 

 DEBUG
   
  
  %date{ISO8601} [%-5level] [%requestId] [%
otherKeyId] [%name] %logger{36} %X{sourceThread} - %msg%n
   
  

...


 

[%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, > 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()
>  }
>

Re: [akka-user] Akka with org.apache.log4j.MDC

2015-05-12 Thread bysen128

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*





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






 

 DEBUG
   
  
  %date{ISO8601} [%-5level] [%messageId] [%
iccid] [%name] %logger{36} %X{sourceThread} - %msg%n
   
  

...


 

[%messageId] [%iccid] [%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, > 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()
>  }
>}

[akka-user] Re: Akka 2.3.11 Released!

2015-05-12 Thread 何品

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.

Re: [akka-user] system.scheduler.scheduleOnce consumes Heap over time

2015-05-12 Thread Endre Varga

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  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.

Re: [akka-user] Akka 2.3.11 Released!

2015-05-12 Thread Filippo De Luca

Cool thanks

On 12 May 2015 at 09:01, Giovanni  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
>>; 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 )
>>- a revert of a performance optimization in 2.3.9 that caused actor
>>starvation when multiple dispatchers were involved (#17341
>>; critical)
>>
>> This release also adds an additional configuration parameter
>>  for ForkJoinPool as well as a
>> fix for a wrong setting path  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
>> 
>> .
>> 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
>> .
>> 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  – Reactive
>>  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


-- 
>>  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 Go

Re: [akka-user] Akka 2.3.11 Released!

2015-05-12 Thread Giovanni

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
>; 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 )
>- a revert of a performance optimization in 2.3.9 that caused actor
>starvation when multiple dispatchers were involved (#17341
>; critical)
>
> This release also adds an additional configuration parameter
>  for ForkJoinPool as well as a
> fix for a wrong setting path  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
> 
> .
> 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
> .
> 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  – Reactive
>  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.

[akka-user] Akka 2.3.11 Released!

2015-05-12 Thread Martynas Mickevičius

*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
   ; 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 )
   - a revert of a performance optimization in 2.3.9 that caused actor
   starvation when multiple dispatchers were involved (#17341
   ; critical)

This release also adds an additional configuration parameter
 for ForkJoinPool as well as a
fix for a wrong setting path  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

.
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 .
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  – Reactive
 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.

[akka-user] akka-http/spray FileAndResourceDirectives.getFromResource with sub directories

[akka-user] Waiting for actor to "become" x in test cases

Re: [akka-user] system.scheduler.scheduleOnce consumes Heap over time

[akka-user] PersistentActor creation.

Re: [akka-user] Announcement: Opinionated RabbitMQ library using Akka / Reactive Streams

Re: [akka-user] using Akka with Kamon...

[akka-user] TestKit and how to avoid a failing (or sucesful) test affecting the other tests

[akka-user] Isn't the Singleton unnecessary in theakka-sample-cluster-java Activator sample?

Re: [akka-user] using Akka with Kamon...

Re: [akka-user] mapConcat

Re: [akka-user] Akka with org.apache.log4j.MDC

Re: [akka-user] mapConcat

Re: [akka-user] mapConcat

[akka-user] mapConcat

Re: [akka-user] Akka with org.apache.log4j.MDC

Re: [akka-user] Akka with org.apache.log4j.MDC

Re: [akka-user] Akka with org.apache.log4j.MDC

[akka-user] Re: Akka 2.3.11 Released!

Re: [akka-user] system.scheduler.scheduleOnce consumes Heap over time

Re: [akka-user] Akka 2.3.11 Released!

Re: [akka-user] Akka 2.3.11 Released!

[akka-user] Akka 2.3.11 Released!

22 matches

Site Navigation

Mail list logo

Footer information